Let me list out some of the problems found in EJB especially Entity Beans (both BMP and CMP) which are not present in JDO. And the nice thing is, you can also use JDO to provide a persistence layer for EJBs.
Here goes ...
Issues with using Entity Beans for Persistence
The following points deal with problems associated with Entity Beans in general.
1. Entity Beans are best suited for coarse-grained business components; they should not be used to represent fine-grained objects. Unfortunately, Entity Beans are only suited for coarse-grained persistent objects and not for fine-grained persistent objects. According to Sun, "Entity beans are not intended to represent every persistent object in the object model. Entity beans are better suited for coarse-grained persistent business objects." (Source: http://developer.java.sun.com/developer/restricted/patterns/AggregateEntity.html
2. Avoid mapping your object model directly to the Entity Bean model.
3. Avoid mapping your relational model directly to the Entity Bean model.
4. Entity Bean to Entity Bean relationships introduces severe performance penalties. This often results when you directly map your object model or relational model into an Entity Bean model.
5. Do not store an object graph of Entity Beans
6. The semantic differences between local (pass by reference) and remote (pass by value) invocation introduces a lot of issues even if some of the flaws have been addressed in the EJB 2.0 specification.
7. The lack of any meaningful support for inheritance is also a cause for concern.
8. Persistence and query functions have to be usually hand-coded (in SQL with JDBC) or described by hand (in Enterprise JavaBeans Query Language -EJBQL- which stems from SQL).
9. There are concurrency issues endemic to the EJB Threading Model.
10. Gross inefficiencies are possible when manipulating large datasets.
11. Inheritance Issues: True inheritance has never been possible with Entity Beans. This is because EJBs were always intended to be self-contained components as opposed to domain objects. Even though code sharing can be accomplished by inheriting from entity bean classes or by inheriting from remote interfaces, true inheritance with the overall component is absolutely not possible. By that I also mean true Java inheritance a client cannot down-cast or up-cast and entity beans EJBObject stub to a parent or subclass, etc.
12. Managing Object Identity issues: Each Entity Bean has to implement a Primary Key class. If JDO were used, the implementer can have a choice of using either Application Managed Identity like Entity Beans, or Data-store Identity. JDO can also manage Object Identity on its own using the Data-store Identity approach.
Issues with using BMP Entity Beans for Persistence
The following points deal with problems associated with Entity Beans that use Bean Managed Persistence.
1. Data Store Connection Issues: The Bean implementer has to implement code in the Entity Bean that connects to the data store and loads and retrieves data (all the different ejbXXX methods). This happens transparently if a JDO implementation were used.
2. Portability Issues: Entity Beans with BMP are assumed to be portable if developers embedded their SQL statements into external resources, and used java.sql.DataSource objects provided by the container to access these external SQL statements. However, this overlooks some scenarios where this approach may not be as portable as we were led to assume. One of them is the case where the implementer may want to switch the Bean implementation to use, say, scrollable Prepared Statements to speed-up their implementation. The whole persistence mechanism has to be re-coded. Another scenario is that it doesnt help very much if the implementer wanted to move from using a Relational Database to an Object-Oriented Database that may not understand JDBC. In such a case too portability is lost as the persistence part has to be rewritten once again from scratch. This is not a problem with JDO because persistence is transparent in JDO, and JDO was intended to persist Java objects in a transactional data store (be they RDBMS, or ODBMS, or flat-files) without the need to explicitly manage the storage and retrieval of individual fields.
3. No Lazy Data Loading: By virtue of coding an ejbLoad method, we ensure that the whole object is loaded into memory completely when the EJB container invokes this method. However, a JDO implementation would use Lazy Data Loading and would only load those persistent fields defined in the Default Fetch Group (DFG). Other fields get loaded as they are referenced.
4. Relationship Implementation Issues: Relationships between classes have to be manually implemented. Its not possible to access other related EJB objects directly. We have to implement code that goes through the Home Interface of the related object to invoke them. This is not a problem with JDO implementations as JDO provides automatic navigation between persistent domain objects in the model. With JDO, there is no extra code that needs to be added by the implementer.
5. No Caching support: Unlike Container Managed Persistence, there is no guarantee that all database calls go through a singleton layer below. This makes it difficult to implement an efficient caching scheme. This is not a problem when using a JDO implementation as JDO specifies the presence of an object cache associated with each Persistence Manager.
Issues with using CMP Entity Beans for Persistence
Even though EJB 2.0 Container-Managed Persistence is touted as the ultimate in Persistence support, it is lacking in many respects when compared to the level of services offered by JDO. The following points deal with problems associated with Entity Beans that use Container Managed Persistence that are not present in JDO.
1. All the EJB-QL problems pointed out in Richard Monson-Heifel's article.
2. EJBQL definition in Server-side Descriptors: As all EJBQL queries are defined in deployment descriptors on the Application Server, it is impossible for a client to use client-side query functionality. For example, a method like findObject(Query query) does not exist.
3. No Lazy Data Loading: With the current specification, it is not possible to configure lazy loading of large result sets from the client. There is no point in using a findAll() method which may return a large result set of beans if you just need to access a couple of them. It is also possible that one may reference a huge collection of other beans from one and access only a few beans from the referenced collection. This will have a very telling affect on performance.
4. No support for Fetch Groups: It is not possible to tell the EJB Container to selectively load relationships rather than loading everything when a bean is accessed. The only exception to this is BEA WebLogics CMP container.
5. No Raw ResultSets: The resulting Result Set as the result of running an EJBQL query will have to contain EJBs. This is really important as reports will need to access an intersection of bean types, and then select a property from there.
6. No Access to Statement Generation: ANSI SQL has to be used for statement generation (for INSERT, SELECT, UPDATE, or DELETE operations). The only exception is stored procedures. It is not possible to use other SQL enhancements provided by your data store provider to enhance performance.
7. Database mapping is too simple: The default CMP implementation mapping of One Bean type to One Table and One Bean Instance to One row is too simplistic. CMP Entity Beans provides no way to customize mapping strategies.
That does not mean JDO has no problems, but they are not that significant. Here are a couple of them.
1. Query Language Issues: JDO Query Language (JDOQL) is totally different from EJBQL. Additionally, during query execution, additional parsing processes are required making it more resource intensive than existing object oriented query languages.
2. Byte-code Enhancement vs. Source-code Enhancement: A lot of people have expressed severe objections to byte code enhancement. They don't like things being done to their code which they can't see in the source. However, the JDO specification itself does not prescribe how the modifications are to be made; only the contract that is to be supported. JDO implementations like hywys PE:J (http://www.hywy.com
/) that provide Source-Code Enhancement however, address these concerns effectively.
As for why major App Server vendors have not supported JDO, that's for a whole different reason which I don't want to get into unless I have to.
Don't get me wrong. I am not against EJB. It's a great technology, and I've been a strong supporter since EJB first came out in '98. I was one of the first to write about EJB (along with others like Tom Valesky, Richard Monson-Heifel, Ed Roman and others), and one of the early evangelists of the technology in JUG meetings and my site has been providing EJB articles to readers for a long time.
I love both EJB and JDO technologies. There is always a place for each of these technologies. There is no point in condemning a technology outright as has become the trend these past few days.
1. Professional JMS (Wrox Press)
2. Enterprise Java Computing : Applications and Architecture (Cambridge University Press)
3. The Awesome Power of JavaBeans (Manning Publications)
Copyright (c) 2002, Gopalan Suresh Raj. All Rights Reserved.
Visit me at Web Cornucopia at http://my.execpc.com/~gopalan/
Web Cornucopia - The Ultimate Resource for developing Distributed, multi-tier, Enterprise Solutions using Java/J2EE, CCM/CORBA 3.0, COM+/Windows DNA, The Microsoft .NET Framework, and all their related technologies.