JDO vs. TopLink

[Pradeep bhatt]

HI,
Can someone compare JDO with Oracle TopLink product.
Thanks
[ December 11, 2003: Message edited by: Bear Bibeault ]

[David Jordan]

First, JDO is an interface that has been standardized and is now supported by ~15 relational JDO vendors and also by object database vendors. The applications are insulated completely from the underlying database architecture. These implementations work with a wide variety of application server products.
TopLink is a product with a proprietary interface that is only provided by a single vendor and is also bundled with Oracle's application server. It was once viewed as a way to have an object view of the information stored in a relational database and have some degree of portability across relational databases. But once Oracle bought the product, many that used TopLink with other relational databases are concerned that the continued support and enhancement of TopLink for non-Oracle databases will diminish.
I suspect you were wanting a comparison of the APIs. I have never used TopLink. But folks that have used it extensively have told me that JDO is much easier to use. I have asked one of these people to provide me with a short summary of the fundamental differences among the APIs. Once I get this, I'll post it here.

[Pradeep bhatt]

David,
Thanks for the reply.
I am waiting for the API comparison between the two. When can I expect that?
I have some more queries.
1. is the JDo spec finalized by SUN?
2. Are there some stable implementations of the same. Lemme know the free and commericial implementations that are available.

[David Jordan]

JDO 1.0 was released as a standard in March 2002. JDO 1.0.1 should be released any day now, it is mainly clearing up areas of ambiguity and fixing a few spec bugs. This is testament to the stability of the standard. So JDO has been out for a year and has already seen its first iteration of spec work.
There are many commercial products that support JDO 1.0. Go to JDOCentral and you will see a large and growing JDO community. I have a commentary titled "JDO's One Year Anniversary" written in March that is on this main page. It contains a list of all the JDO vendors to date, but I know of others planning to release implementations soon. From JDOcentral, there are a number of commercial products that you can download for a free evaluation. When this week ends and Craig and I are not part of this special JavaRanch book promotion, you can always go to JDOcentral to get any of your JDO questions answered, there are now over 7000 members participating in the JDO community! Under the Community link you will find discussion forums very similar to JavaRanch where many JDO developers are involved in discussions and answering questions, etc. It is the best place to go to learn about JDO.

[leo donahue]

Originally posted by Pradeep Bhat:
David,
Thanks for the reply.
I am waiting for the API comparison between the two. When can I expect that?
I have some more queries.
1. is the JDo spec finalized by SUN?
2. Are there some stable implementations of the same. Lemme know the free and commericial implementations that are available.

I downloaded the spec from
here

[David Jordan]

Leo,
That link takes you to the unofficial JDO web site that the expert group had used before JDO was released. The official JDO page is here.

[leo donahue]

Originally posted by David Jordan:
Leo,
That link takes you to the unofficial JDO web site that the expert group had used before JDO was released. The official JDO page is here.

Many thanks, enlightenment occurring....

[Pradeep bhatt]

Is JDO part of J2EE ? If no is there are a possibility of it included in future J2EE version.
How will JDO sit in J2EE with EJB around.

[Craig Russell]

JDO is being considered as part of the to-be-defined J2EE 1.5. It's not a required part of J2EE 1.4, although JDO vendors provide integrations with J2EE servers at the 1.3 (currently shipping) and 1.4 (beta-future) levels.
The integration possibilities are considerable. Our book goes into detail on how to integrate JDO with EJB and servlet containers.

Originally posted by Pradeep Bhat:
Is JDO part of J2EE ? If no is there are a possibility of it included in future J2EE version.
How will JDO sit in J2EE with EJB around.

[Pradeep bhatt]

Why is the JDO spec moving slowly? Why is the industry not higlighting it? Do they think JDO to be a threat to their existing containers?

[David Jordan]

In my opinion, YES.
The big app server vendors have committed a HUGE amount of resources to EJB, and they continue to invest a lot in EJB. They are also driven by the major relational database vendors that simply want the whole world locked in to their SQL dialect. So the major players have a lot to lose if JDO becomes successful. That's why companies like Oracle are out attacking JDO both publicly and privately behind closed doors. They view it as a threat to their control of the market. Yet many developers that have learned about JDO love it and momentum is mounting behind JDO at a user level despite the fact that the big guys have either ignored it or are openly attacking it. Now even the EJB community and TopLink organization in Oracle are trying to add capabilities JDO has that they do not have, to try and prevent it from overcoming them.

[Lasse Koskela]

Originally posted by Pradeep Bhat:
Why is the JDO spec moving slowly? Why is the industry not higlighting it? Do they think JDO to be a threat to their existing containers?

Take a moment to think about the biggest players in J2EE world. IBM and Oracle get truckloads of money out of their DB2/Oracle licenses every quartal. Naturally they are afraid of losing that income. On the other hand, the rest of the (smaller) players in J2EE have bet their profits on application servers of which primary attraction is the EJB container.
Ah. I see David had answered this one while I was t-y-p-i-n-g...
[ June 20, 2003: Message edited by: Lasse Koskela ]

[Pradeep bhatt]

I am a bit surprised by your comments. Is JDO a threat to EJB vendors or to database vendors. I feel it is the EJB.
I guess that JDO can be used to persist data into database. So no problems to db vendors.
please comment.

Originally posted by Lasse Koskela:

Take a moment to think about the biggest players in J2EE world. IBM and Oracle get truckloads of money out of their DB2/Oracle licenses every quartal. Naturally they are afraid of losing that income. On the other hand, the rest of the (smaller) players in J2EE have bet their profits on application servers of which primary attraction is the EJB container.
Ah. I see David had answered this one while I was t-y-p-i-n-g...
[ June 20, 2003: Message edited by: Lasse Koskela ]

[Craig Russell]

To be honest, I think that there is no threat posed by JDO to either relational databases or application servers.
Users will always need their relational databases, and once they make their choice, they are committed to it.
To implement web services, users need at least a web container, and will use EJB containers when they need more services than offered by web containers (JNDI, coordinated transactions, etc).
So I think the reaction From Oracle that David mentions is just a bit silly. But even silly elephants can kill.

Originally posted by Pradeep Bhat:
I am a bit surprised by your comments. Is JDO a threat to EJB vendors or to database vendors. I feel it is the EJB.
I guess that JDO can be used to persist data into database. So no problems to db vendors.
please comment.

[David Jordan]

I should have qualified my statement that it is a "perceived threat" versus an "actual threat". The other dynamic going on is that the two biggest relational database vendors, Oracle and IBM, are also EJB application server vendors. And in the case of Oracle, they have the TopLink product which competes with JDO. So there are three different major organizations in Oracle that are perceiving JDO as a threat.
But people will continue to use relational databases, there is no question in that.
Oracle spent lots of money preaching that object databases were immature and inferior for many years and was largely successful in scaring people away from the technology. Now JDO comes along, offering an object layer on top of virtually any kind of database, including object and relational databases, and what does Oracle do? They have been proclaiming that JDO is patterned after object databases and is immature, etc. They are singing their old anti-OODB song again. Except this time they look really stupid doing it because, at the same time they are trying to criticize JDO, literally in the same presentation, they are trying to promote use of TopLink, which is an alternative proprietary means of doing the same thing as JDO. They will have a slide that claims TopLink supports JDO, even though it doesn't, and when you make a statement that TopLink is very similar in functionality to JDO, they react by saying JDO is nothing like JDO, that JDO is inferior. This was all stated in an Oracle presentation at JavaOne and they are also preaching the same message in presentations they are giving publicly and privately.
They say JDO is not a standard and you should not use it. Then they push TopLink, which is not a standard. When people point out that TopLink is not a standard, they have responded that standards are not important in this area. But standards in this area are extremely important because we are talking about the object models that are used throughout the application. The standards are VERY important.
Oracle is coming across as being completely schizophrenic on this whole issue.
If they were smart, they would allow the TopLink developers to take their half-baked JDO layer on top of TopLink and finish it. They should use their underlying capabilities like persistent rowids, collections and clustering and provide a JDO implementation faster than any object or relational database on the market. But right now, they are being very stupid on this issue.

[Lasse Koskela]

This was actually discussed briefly in another thread... Here are some points:
Why JDO is a threat?
- JDO enables OODBMS vendors to gain market share as the application doesn't need to resort to proprietary APIs
- JDO enables smaller RDBMS vendors to gain market share as the application doesn't need to be touched when migrating
- JDO provides an object-oriented persistence framework for web containers, which might persuade an architect not to use a full J2EE appserver
Why JDO is not a threat?
- Existing installations of Oracle/DB2/etc will not be replaced
- Oracle/IBM can provide their own JDO implementations as front-ends to their database products

[Pradeep bhatt]

Thanks craig and David.
Has app server vendor started implementing JDO spec ? Are these app server vendor part of spec team.
I am waiting for the API comparison between toplink and JDO.
Thanks again.

[David Jordan]

Why does an application server vendor need to implement JDO? They don't need to. There are 15 relational JDO implementations already, and they support all the major application servers. Some may end up buying one of these companies, kind of like Oracle buying TopLink. But there is no fundamental need/reason for an application server vendor to own the JDO implementation. Also, the JDO implementation works outside of an application server. If I were using a JDO implementation and it got bought by an app server vendor, I would be concerned that support of that implementation outside of the app server would be dropped. This has already happened with TopLink, which now is bundled with their application server. To use TopLink, you need to buy and use Oracle's application server too. You seem especially interested in TopLink. You can try it, but I think that is a big mistake at this point in time. JDO will rule, not the proprietary products.
My colleague that really knows both TopLink and JDO says he is too busy to put together the comparison, so this is not forthcoming. Sorry.

[Pradeep bhatt]

Thanks!

[Patrick Nolan]

We have Oracle 9ias and I am trying to figure out what the best option is for data access. Can anyone comment? The dilemma is 9ias didn't come with a JDO implementation, only TopLink. I am concerned that TopLink is proprietary and will fade away as JDO implementations gain ground and take over. I am considering something other than CMP entity beans because they are just too damn slow (even with local interfaces and DTOs). And.. BMP is a pain to code.
My requirements are this: Data access/updates must to be FAST. The web apps using JDO or TopLink will support hundreds of transactions per second. Also, at some point, will have to distribute them among among a cluster. Our data model is well-designed, but very complex. The objects should make traversing data relationships easy and fast.
Until I can make an informed decision, I will just rely on an absraction layer over the domain layer and continue to use CMP and JDBC where each is appropriate.