Originally published in DeveloperIQ magazine
What is CMP and BMP in EJB?
So, why is it that Entity beans alone were found wanting and the specification keeps on changing? Entity beans are of two types. CMP & BMP. CMP stands for Container-Managed Persistence and BMP stands for Bean-managed persistence. Theoretically, the EJB specification does not say anything about the method to be adopted in persisting objects for permanent storage and retrieval. It could be simple object serialization. The database may be object-database or Object-relational database or XML.In practice , however, a database has always meant a Relational Database and its SQL.
In a very complex Enterprise application, we begin with Modelling. Instead of dealing with tables and their complex inter-relations, it is more intuitive to deal with classes and objects. Thus we design our system , ‘thinking in objects’ and not in tables. So long, as we are dealing with objects in memory or with objects persisted in hard-disk simply as objects, there is no problem, except that object-serialization , especially of complex objects is a slow process. On the other-hand, Relational Database technology is fast, time-tested, well-known and famous. So, the problem is to work with objects in memory but persist the objects in hard disk as relational database.
This is what is known as ORM ( Object-Relational Mapping).If we opt to deal directly with tables only and either read data or manipulate data by session beans, we skip the entire ORM problem. But how practical is it for really complex projects? That is the rationale for the development of Entity Beans in EJB.
In CMP, the coder deals with objects, only in memory. He creates new objects, modifies them, deletes them and views them , all in memory. The task of saving these objects in memory ,to the relational database table is done by the container, automatically. The coder does not write any sql-related code for this.
In BMP, the coder has to write the sql to persist the object in memory to the relational database.
CMP in EJB1.1 was suitable for simple tables, without complex relationships to other tables. CMP avoids all references to the underlying database. So, it is more portable. There is no vendor-lock-in. CMP can persist data to Object- databases also, besides Relational databases.
But, CMP is not always suitable. If the database is some legacy type, which cannot be used with SQL, the database company gives a proprietary code for persistence and such code has to be used in our program to persist data. The facilities given in CMP originally were found to be too elementary and there were complaints.
But, what matters is that CMP makes use of ORM concepts, though the implementation left much to be desired. It did not expose how the EJB vendor implements it. Weblogic, Oracle, IBM WebSphere, SUN , JBoss , each may implement CMP in any way that they deem fit. Except in special circumstances, it will be better to use CMP, not merely because, it makes the code more portable & is easy to write. Much more important reason is that the EJB container can optimize the performance dramatically, if we adopt CMP. So the developer community wanted to adopt CMP but found it unsuitable for really complex jobs.
And a sizable section of developers found the XML Deployment Descriptors for CMP ,especially for complex jobs, a bit troublesome and tedious.It can be said that any design which makes us dependent on wizards, is a bad design. Unlike the Deployment Descriptors for Session beans, which can be hand-coded in a jiffy, by just find/replace method in a text editor, the DD for CMP required three XML files, two of them very special to the container used.
In order to improve things, EJB 2.0 proposed a few changes, mainly in the matter of writing CMP. It provided for Relationships. It proposed a simple query language known as ‘EJB-QL’. Since, calling an Entity bean through a session bean (Facade pattern) is more efficient , from the viewpoint of minimizing network traffic, the very concept of remote interface for entity beans was questioned and so local interface also was provided for Entity beans.( In a total reversal, there is no local interface in EJB-3! and instead of EJB-QL , Hybernate Query Langauge is taking over in EJB-3).
Even with all these improvements, CMP was found to be less than the ultimate solution. There was no possibility for Inheritance.
Though the container services provided by the EJB container are indispensable in a truly large enterprise application, the J2EE camp is almost vertically split into WebTier & EJB-Tier votaries. The WebTier supporters claim that EJB with its steep learning curve and error prone development environment for developers is not really necessary for most applications. And they would like to have an ORM tool , built into the J2EE specification. For after all, ORM task is not specific to EJB alone. Even Servlets and JSP could use them. In fact , they have been using them, though the J2EE specification was silent about it. ORM tools like OJB, JDO and Hibernate can be used not only in EJB containers but in webcontainer and even in standalone containers. Gavin King makes it a special point in favour of Hibernate. Making such a tool , a J2EE standard, would make development tasks far easier ,to develop either web-tier application or ejb-tier application, saving us from the medley of classpath to required jars.
In a scathing attack on the complexity and questionable performance of EJB Entity beans (though, unjustifiably on EJB itself), Rod Johnson,prophesies , that in a few years’ time, J2EE will cease to include EJB. Whether , we agree or not, it is worth looking into the criticisms against EJB Entity beans ,raised by him.( ‘J2EE Development without EJB’-Wrox/Wiley/DreamTech-2004).For, he is proposing the Spring Framework as an alternative to EJB container and the idea is gaining ground.J2EE developers and students may have to re-orient themselves rather abruptly, to remain relevant to industry.