aspose file tools*
The moose likes JDBC and the fly likes JDO & EJBs Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC
Bookmark "JDO & EJBs" Watch "JDO & EJBs" New topic
Author

JDO & EJBs

Panagiotis Varlagas
Ranch Hand

Joined: Nov 27, 2000
Posts: 233
Does JDO make sense in an EJB solution?
And if it does, in what way is it better than using entity beans?
Thanks,
Panagiotis.
David Jordan
Author
Ranch Hand

Joined: Jun 14, 2003
Posts: 66
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.
Craig Russell
Author
Greenhorn

Joined: Jun 16, 2003
Posts: 28
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.
Panagiotis Varlagas
Ranch Hand

Joined: Nov 27, 2000
Posts: 233
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.
David Jordan
Author
Ranch Hand

Joined: Jun 14, 2003
Posts: 66
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.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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).


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
David Jordan
Author
Ranch Hand

Joined: Jun 14, 2003
Posts: 66
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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JDO & EJBs
 
Similar Threads
Enterprise support
JDO vs. Castor
Using JDO with an existing DB schema
JPA and JDO
JDO