Some light on JDO vs entity beans

Discussions

EJB programming & troubleshooting: Some light on JDO vs entity beans

  1. Some light on JDO vs entity beans (3 messages)

    * With local interfaces entity beans now have pass-by-reference and no remote access overhead.
    * Both JDO and CMP entity beans have deployment descriptors to define the O/R mapping when using a RDMS
    * Tools such as xdoclet reduce the development overhead of writing home and business interfaces.
    * CMP avoids the N+1 calls problem when loading collection of entities.
    * Both JDO and entity beans have JTA integration. So how does JDO have less transactional overhead then entity beans (as describe in the EJB Design Patterns book)??

    Therefore the only things that I can see against entity beans when compared with JDO classes is the security overhead. IMO JDO classes are not POJO (plain old java objects) since they require either source code or byte-code modification. The complexity of building CMP entity beans has been allievated greatly with tools such as middlegen. JDO classes also do not require a EJB container, however the JDO still requires an environment (a library at least).

    JDO does not come out of the box with EJB containers and therefore requires extra deployment effort. I also do not think highly of the query facility. Check out the QBE interface in apache's OJB. Another problem with JDO is the lack of products.

    On the other hand, JDO supports inheritance and can be used as DTOs. JDO also allows dynamic query functionality to be built.

    Can everybody please post some pros and cons of JDO and entity beans?

    And can someone please tell me why entity beans (CMP 2.0) are heavyweight components compared to JDO classes, since JDO classes attach persistence through either source code or byte-code modifications and support JTA?

    Threaded Messages (3)

  2. Some light on JDO vs entity beans[ Go to top ]

    I agree with you. Entity beans are necessarily evil, and JDO is not necessarily a one-size fits all solution. However, recent sentiment has been against entity beans and in favor of JDO. The recently published/reviewed advanced J2EE books (e.g., Rod Johnson and Bruce Tate) are almost unanimously critical of entity beans, and speak favorably about JDO.

    IMHO, if you know how to use code generation tools, and want to take data caching and read only features of EJB containers, CMP entity beans may not be a bad choice. The bottom line is to do performance test on your app and make sure it meets your requirements. We can make theoretical arguments about technologies all day, but whatever is more productive and also meets the performance requirements, I think we should not be afraid of using it, even though that technology has some imperfections.
  3. 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 bean’s 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 doesn’t 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. It’s 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 WebLogic’s 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 hywy’s 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.

    Cheers
    Gopalan.

    Co-Author of:
    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.
  4. Firstly, thank you for your reply. I know that this topic has been discussed in the past, but I raise it again because of the new specification and a lot of complaints about entity beans stem from version 1.1

    Gopalan: Entity Beans are best suited for coarse-grained business components

    Since version 2.0 this is no longer true. See the "Data Transfer Object Factory" pattern in "EJB Design Patterns" for example, that entity beans should now be fine-grained.

    Gopalan: Avoid mapping your object model directly to the Entity Bean model. Avoid mapping your relational model directly to the Entity Bean model.

    Could you explain what you mean here?

    Gopalan: Do not store an object graph of Entity Beans

    Could you also explain this?

    Gopalan: 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.

    Remote interfaces are required for session beans for remote calls from thick clients. I don't see how this is a flaw with EJBs. Entity beans should now use local interfaces and the Session Facade pattern used.

    Gopalan: The lack of any meaningful support for inheritance is also a cause for concern.

    This is a problem. JBoss 4.0 may have inheritance support
    http://www.jboss.org/developers/projects/jboss/projects.jsp

    Gopalan: 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).

    This is simply not true. Tools can generate SQL and be specified in the deployment descriptor. Likewise for EJBQL.

    Gopalan: There are concurrency issues endemic to the EJB Threading Model.

    If you are referring to concurrency for use cases that span over multiple transactions, then I agree. However, how does JDO solve this problem.

    Gopalan: Gross inefficiencies are possible when manipulating large datasets.

    Good CMP implementations should solve this. How do JDO O/R mapping tools solve these problems? I suspect that it faces the same problems.

    Gopalan: Inheritance Issues ...

    You already mentioned this one.

    Gopalan: Managing Object Identity issues...

    Well, firstly you don't have to implement a primary key class for entity beans. But JDO is nicer in this regard.

    Before I continue, I would like to point out that BMP should not be compared with JDO.

    Gopalan: Data Store Connection Issues...

    Well, BMP is not transparent.

    Gopalan: Portability Issues...

    Again BMP is not transparent. Externalising the SQL just minimises the work required to port to another RDMS.

    Gopalan: No Lazy Data Loading...

    Well you could, but that envoles another database hit. So you are correct. How does JDO implement lazy loading when using a RDMS?

    Gopalan: Relationship Implementation Issues...

    Yes, but BMP is not transparent.

    Gopalan: No Caching support

    Simply not true. How difficult the caching is to implement is of concern of the EJB container provider.

    Gopalan: All the EJB-QL problems pointed out in Richard Monson-Heifel's article.

    Weblogic and JBoss extend EJB-QL. You can even do dynamic (runtime) queries.

    Gopalan: EJBQL definition in Server-side Descriptors

    Again, the spec does not allow this but some implementations eg JBoss and Weblogic have dynamic queries.

    Gopalan: No Lazy Data Loading

    Many J2EE servers allow this. BTW, this does not affect portability since it is defined in the app server specific deployment descriptor.

    Gopalan: No support for Fetch Groups

    JBoss also support this. I don't know about other web servers, but good CMP implements should support this.

    Gopalan: No Raw ResultSets

    Well, I think that is a good thing. The RDMS should be abstracted from the other layers. What if you are using an OODMBS? Correct me if I am wrong, doesn't JDO do the same thing here.

    Gopalan: No Access to Statement Generation...

    ??? CMP could support stored procedures. How does JDO handle this issue?

    Gopalan: Database mapping is too simple

    Weblogic allows mapping an entity bean to multiple tables, etc. JBoss 4 will also support this.

    --------------------------------------------------------

    Entity beans do have problems. I don't intend to make out they don't. But as I stated at the start, many complaints that I have seen don't seem to hold any more. Inheritance is a problem. I know JBoss is working on this one. Dynamic queries is also a problem, but many CMP implements (JBoss and Weblogic) support this, although it is not mandated by the specs. As for the mapping issues you raised, JDO faces the same problems when using a RDMS. These problems are O/R mapping issues not entity beans.

    JDO definitely is good. But there is a lack of products, especially from bigger names like Oracle and IBM. I personally dislike byte-code modification as for the reasons you stated. As you pointed out, JDO does not prescribe how the modifications are to be made. But this is what the majority of JDO implementations do.

    Using POJOs is much better then entity beans. But at what costs? When using XDoclet, CMP 2.0 entity beans are similar to a POJO. So what does JDO give us? You can use JDO outside of an EJB container, but JBoss is going to do the same with there CMP engine. They are also working towards supporting POJO (plain old java object).

    This leads back to why I started this thread. Why use session beans + JDO instead of CMP 2.0 entity beans with local interfaces? So far, it seems that they both have there problems. And since CMP comes out of the box, it seems easier to me to use CMP. I have just started out on J2EE path, and I am trying to work out if learning and investing in the CMP option is not a waste of time and money. Could you provide me with some advice about this in particular????

    Kind regards,
    Cameron Zemek