Until the publication of the Enterprise JavaBeans 3.0 specification and the Java Persistence API, the only persistence technology officially part of the Java Enterprise Edition platform (Java EE is Sun's new name for J2EE) was container-managed persistence (CMP) using EJB entity beans. Ever since they were first required to be supported in EJB 1.1, entity beans have been criticized as being both too complex and lacking in features to handle the persistence requirements of real-world applications. But standards matter in the enterprise, so despite the availability of proven object-relational mapping solutions, both commercial and open source, companies have always found a way to work around the entity bean shortcomings and get the job done. As a result, there is a large installed base of applications based on CMP entity beans, and bringing them forward into the next generation of Java EE standards may be a task worth pursuing.
The complexity of entity beans lies not in the concept but in the implementation. Like session beans, entity beans are true EJB components, with separate classes for the bean implementation, home interface, and business interfaces. Entity beans also require a verbose XML deployment descriptor that describes the persistent properties of the bean, container-managed relationships between entities, and the EJB QL (query language) queries used to access the entities. Finally, many of the entity bean details require vendor-specific configuration to deploy and run. In response to these issues, the Java Persistence API offers a programming model that is easier to use, while offering a larger feature set with less vendor-specific configuration.
Although the Java Persistence API is the standard persistence model moving forward, the good news for companies that have made an investment in CMP entity beans is that the EJB 3.0 specification still fully supports container-managed persistence. Existing applications will work out of the box without changes and can expect to do so for years to come. The EJB 3.0 specification is only now deprecating version 1.1 of the entity bean model. All Java EE 5-compliant application servers must support EJB 2.0 and 2.1 CMP entity beans.
That's good news for applications that aren't likely to require much development going forward, but what about applications that are planning revisions? Is it feasible to move away from CMP and take advantage of the Java Persistence API? In many cases it will depend upon the design of your application. Only you can decide the most appropriate plan of action for your application. The following sections will lay out the issues and discuss potential strategies for migrating CMP applications to help you make your own decision.
Note: This article assumes that you are familiar with EJB 2.1 container-managed entity bean implementation and configuration.
Scoping the challenge
The challenge in moving from entity beans to entities is not the entity beans themselves. However complex they are to implement, they are relatively straightforward to use. The problem with entity beans is that the public API they expose is tightly coupled to the component model on which they are based. The principal issue facing any migration is the extent and manner in which application code interacts with entity bean interfaces. The more code that uses entity beans, the harder it is to migrate.
