First, you may want to examine the JDO or CMP? excerpt from our book that summarizes this. Craig should be able to give you a more complete answer on this. JDO persists plain, ordinary Java objects and allows direct navigation of references in your object model. Entity beans are primarily distributed object components that come with all the plumbing, complexity, and overhead of supporting distributed object communication. JDO is, in general, regarded as much simpler to use and faster. Craig did a CMP container implementation using JDO in the Sun ONE application server, so he will have a lot to say about this topic.
JDO makes sense in an EJB container. Specifically, use JDO to access persistent data from session beans, message-driven beans, and JSP/servlet including Struts, JSF, and other such frameworks. Basically, JDO offers more modeling features than CMP beans and is a whole lot less work than writing your own BMP beans.
Originally posted by Panagiotis Varlagas: Does JDO make sense in an EJB solution? And if it does, in what way is it better than using entity beans? Thanks, Panagiotis.
Joined: Nov 27, 2000
Thanks for your answers! I'll definitely read the article, hopefully the book too as time permits. It is now clearer to me. JDO is a persistence framework that handles the "infamous" object-relational mapping issue. It is a (better in your opinion and experience) alternative to CMP and BMP with respect to persistence services. So, JDO provides an OO abstaction of your underlying DB (typically a relational one, as abstracted - at a lower level - by JDBC). Now the question is why JDO is better than any other of the host of OO-relational mapping solution that (may) exist outthere (Toplink, WebSphere Studio Data Access Beans, etc.)... And returning to the EJB issue, session beans and message-driven beans are orthogonal to JDO, since the provide pretty much transactional and messaging services that are outside JDO's scope. Do the above make sense? Thanks, Panagiotis.
Joined: Jun 14, 2003
JDO is a Java standard now, having gone through the Java Community Process. JDO is an API supported by 15 different vendors. The other products you mention are all proprietary, non-standard products supported by a single company.
Originally posted by Panagiotis Varlagas: Now the question is why JDO is better than any other of the host of OO-relational mapping solution that (may) exist outthere (Toplink, WebSphere Studio Data Access Beans, etc.)...
JDO is better because it's a standard. Toplink might be better when the feature matrices are put side by side but these days the "standard" stamp gives a lot value over some niche features found only in top notch proprietary products.
Originally posted by Panagiotis Varlagas: And returning to the EJB issue, session beans and message-driven beans are orthogonal to JDO, since the provide pretty much transactional and messaging services that are outside JDO's scope.
SessionBeans/MDBs should be used as they are being used already -- for business logic. The only thing JDO changes is that the business logic calls a different API for making certain information persistent (i.e. JDO instead of CMP/BMP).
Correct Lasse! One point to make though. JDO is a standard, TopLink is a product. There are still features and capabilities that are provided in a product that are not found in an interface standard like JDO. So a fairer comparison would be to compare TopLink with one of the leading JDO relational products. TopLink has been around longer than these JDO products, so it is natural for TopLink to have more features. But I believe the feature gap between TopLink and the leading JDO relational products will diminish as the JDO products compete with one another based on these additional capabilities. Still, the application software itself will remain portable across the JDO implementations. This happens all the time in technology as new standards come out. When relational databases first came out, people were claiming that the Codasyl databases had many more features than the relational databases. But over time, the new technology catches up. Having a common interface standard provides a pluggable architecture that allows vendors to innovate and compete while the users of the technology have stability and portability to migrate to the best of breed technology.