JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle

Discussions

News: JDO 2 Ballot Results: Concerns from IBM, BEA, and Oracle

  1. There has been an interesting twist to the JDO story. IBM, BEA, and Oracle all voted against the new JSR, while Sun and Macromedia supported it in their comments. The battle-ground seems to be that JDO overlaps with "other JSRs". Namely EJB 3.

    The comments tell the story:

    Sun: Yes
    This is in response to some of the comments on JSR 243 "JDO 2.0".

    If JDO did not exist, it might be a worthy topic for debate as to whether the Java community should invest in this area. I can see pros and cons on both sides. But JDO does exist, and it has a loyal user community who want to see it continued and extended. Sun, as specification lead for JDO, is responding to what we perceive as legitimate community demand for evolving JDO.

    Sun believes that there is space for both JDO and EJB. I hope the expert groups can cooperate to minimize any unnecessary differences in areas where they overlap. Whether or not JDO should be included in J2EE is an issue for a future J2EE expert group to debate.

    Given that JDO exists and has attracted significant interest from the Java community, I think it is appropriate to allow it to continue to evolve, based on the feedback and requirements from its users.
    Macromedia: Yes
    While undesirable overlap does appear to exist between JDO and other JSRs, the feedback we have long heard on this particular subject is that Java application developers prefer to adjudicate the overlap themselves rather than have the decision enforced for them by platform vendors. The community appears to desire a choice between persistence technologies even at the expense of the additional platform complexity and fragmentation that the overlaps between those technologies can cause. We consider our vote in favor of this JSR to reflect not an architectural platform aesthetic, but instead to reflect the more practical majority sentiment long and loudly expressed by customers and others in the community.
    BEA: No
    JDO is one of many different persistence solutions in server-side Java today. With J2EE 1.5 emphasis on simplification and ease of use, we don't see how having another release of JDO, whose market acceptance is essentially constrained to use with object databases, can be explained in conjunction to similar enhancements being made in the EJB3 expert group. We are also concerned about taking JDO into new areas such as disconnected data set support until we better understand how ball of these solutions fit together. Unless the submitters can explain how all of this fits together, we believe the Java community would be better served with fewer apparently competing alternatives.
    IBM: No
    This JSR proposes to develop extensions to JDO that apparently overlap with existing Java technologies and with other JSRs that are already in-progress. In a context where the Java community is working to simplify J2EE, it is undesirable to produce multiple overlapping ways of programming the same function.
    Oracle: No
    JDO 2.0 overlaps with the work being done by the EJB 3.0 expert group to provide a lightweight persistence model. Having 2 specifications address the same problem space with different APIs, persistence and transaction semantics, mapping definitions and query mechanisms does not contribute to the effort of simplifying J2EE and making it easier to use. The direction of lightweight persistence being taken by the EJB 3.0 group will have tremendous appeal to mainstream enterprise Java developers, even those who are critical of the current Entity Bean model. Given the evolution of EJB 3.0 persistence, another independent standard for persistence is unnecessary and will add confusion to those looking to adopt J2EE technology.
    What are your thoughts? Do you want JDO to die? Or is there a place for a spec on a persistence model, not tied to the enterprise?

    View the ballot results for: JSR #243 Java Data Objects 2.0

    Threaded Messages (172)

  2. Hi All

    Its hardly surprising that 3 EJB vendors do not like JDO, especially since two of them are also database vendors. A database and runtime environment independent standard for Java persistence is the last thing they want.

    "JDO, whose market acceptance is essentially constrained to use with object databases"

    This is plain FUD. There are many JDO implementations available with many customers and nearly all of them are aimed at relational databases.

    Cheers
    David
    www.jdogenie.com - High performance JDO for relational databases
  3. Yeah, this just in: the Pope is Catholic. But seriously, why can't these guys talk about synergy? In any other context they'd be tripping over themselves to pontificate about the big changes ahead.

    Now when there's a chance to actually deliver something to developers that they want, other interests come first. That's okay. The market will take their actions into account in the long run.

    It's obvious now why JDO it took forever to get a basic JDO spec out the door in the first place: from what it sounds like these guys have been against it from day 1.

    Steve
  4. too late, Hibernate already crushing these EJB conspiracy!

    Michael
  5. I believe the EJB 2.0 / J2EE 1.5 specification leads have an obligation to listen to the community. The current specifications result in J2EE application servers having an exceptionally high cost of development, resulting in a pretty closed shop. The spec leads have a duty of care to make their specifications more widely implementable, and the best route is to make Entity Beans OPTIONAL in the EJB 3.0 spec. The application server market could be opened up to organizations who might like to build a compliant server but see no point in implementing Entity Beans or CMR.

    Then the light-weight containers so popular on TSS might engineer themselves to become J2EE-compliant, and people will use them with JDO or Hibernate.
  6. too late, Hibernate already crushing these EJB conspiracy!Michael
    There is no such thing as EJB conspiracy but not so smart implementers who mistaken Entity Beans ( especially CMP ) for general ORM. Guys: CMP is a joke - agreed and should not be used, bThere is no such thing as EJB conspiracy but not so smart implementers who mistaken Entity Beans ( especially CMP ) for general ORM. Guys: CMP is a joke - agreed and should not be used, but when it comes to distributed persistence then a well defined Entity Bean life cycle is what we need. Hibernate backed BMP is a way to go in 1-3 % cases.

    As for JDO: there is no need for it to be among core APIs. It is time to start cleaning core Java/EJB and make them smaller and better.
    ut when it comes to distributed persistence then a well defined assun
  7. I think it is about time we called it at day with Entity Beans and let JDO become the spec for defining how to persist your model in J2EE. Entity Beans (Distributed Persistence Components) were never design for what people want and are using them for.

    It also sounds like EJB 3.0 is going to be the second attempt to turn them into something they where never meant to be and fit that square peg into a round hole again.
  8. I think it is about time we called it at day with Entity Beans and let JDO become the spec for defining how to persist your model in J2EE.
    +1. Deprecate entity beans in EJB 3.0 and move all types of persistence to JDO 2.0.
  9. +1. (predictably!)

    Doing this would MASSIVELY increase the credibility of EJB and, by association, that of J2EE also.

    Vendors using Entity Beans for the one thing they were reasonably good at (access to legacy non-relational data) would have to engineer a PersistenceManager-based solution before the deprecated beans were no longer supported, but that in itself is not a showstopper as JDO was defined with this in mind (it is, after all, datastore agnostic).

    Two questions arise:
    1. Do the JSR-220 folks agree?
    2. Are they bold enough?
  10. I hope that at the time EJB 3.0 is released, JDO 2.0 spec is a old one.
  11. ...JDO was defined with this in mind (it is, after all, datastore agnostic).
    This is one of the best things about the JDO spec, IMHO.
    1. Do the JSR-220 folks agree?
    2. Are they bold enough?
    I'm not holding my breath! Still, you never know...
  12. Two questions arise:
    1. Do the JSR-220 folks agree?
    2. Are they bold enough?
    I hope the expert group members see the writing on the wall and show some courage on this. But IMHO it will probably not matter whether they deprecate entity beans or not, because nobody will use entity beans for future development and people are leaving entity beans in droves. So instead of keeping a bloated EJB spec, I hope they spec team find it easier to take the unwanted part out of the spec completely.

    Now BEAS, IBM, and ORCL all have invested a lot of money on entity beans technology, and they need to find a way to recover some of the investment before they throw their support behind JDO 2.0. Fine. For ORCL, it is easy - make TopLink JDO compliant. For IBM, also easy - buy a JDO/ORM vendor. For BEA, eh - try to get the best deal when it is bought by ORCL.
  13. Appreciation to Robin Roos[ Go to top ]

    +1. (predictably!)Doing this would MASSIVELY increase the credibility of EJB and, by association, that of J2EE also. Vendors using Entity Beans for the one thing they were reasonably good at (access to legacy non-relational data) would have to engineer a PersistenceManager-based solution before the deprecated beans were no longer supported, but that in itself is not a showstopper as JDO was defined with this in mind (it is, after all, datastore agnostic). Two questions arise: 1. Do the JSR-220 folks agree?2. Are they bold enough?
    I'd like to say thank to Robin Roos, for good posts!

    It’s clear, that EJB concept has problems. Such reaction from community is absolutely predictable and I do not understand why smart people from IBM, BEA and ORACLE still decided to declare there positions. Whatever the money spent for EJB, it is very risky decision to invest more resources into such compromised idea. Big Bosses and shareholders of IBM, BEA and ORACLE probably need to think again.

    Best,
    Igor.
  14. Appreciation to Robin Roos[ Go to top ]

    I'd like to say thank to Robin Roos, for good posts!
    Thanks, Igor.

    I try to focus on Technology and not get too carried away with Religion - I hope that comes across and is helpful.
  15. What to do with EJB 3.0[ Go to top ]

    I think it is about time we called it at day with Entity Beans and let JDO become the spec for defining how to persist your model in J2EE.
    +1. Deprecate entity beans in EJB 3.0 and move all types of persistence to JDO 2.0.
    And make Hibernate JDO 2.0 compatible.

    Best,
    Igor.
  16. What to do with EJB 3.0[ Go to top ]

    Hear! Hear!
  17. What to do with EJB 3.0[ Go to top ]

    And make Hibernate JDO 2.0 compatible.
    The JDO 2.0 standard lifts barriers to entry such that Hibernate could become JDO-compliant. Instead of using our bytecode enhancement they could use their own! However, there have been few statements regarding JDO 2.0 coming out of the JBoss camp recently, either pro or anti. It is possible that they are focussing more on EJB 3.0 concept proving right now.
  18. What to do with EJB 3.0[ Go to top ]

    I think it is about time we called it at day with Entity Beans and let JDO become the spec for defining how to persist your model in J2EE.
    +1. Deprecate entity beans in EJB 3.0 and move all types of persistence to JDO 2.0.
    And make Hibernate JDO 2.0 compatible.Best,Igor.
    The changes introduced in the JDO 2.0 spec include a relaxation of the binary compatibility requirement (the implementation of the javax.jdo.spi.PersistenceCapable interface), so Hibernate (and Toplink) could fairly quickly become JDO 2.0 compliant.

    --matthew
  19. I think it is about time we called it at day with Entity Beans and let JDO become the spec for defining how to persist your model in J2EE.
    +1. Deprecate entity beans in EJB 3.0 and move all types of persistence to JDO 2.0.
    +1

    I think you have found the best way to solve this problem, just drop EJB and it will be no conflicts and fragmentations.
  20. blockquote>+1 I think you have found the best way to solve this problem, just drop EJB and it will be no conflicts and fragmentations.We need to be careful about terminology here. Dropping EJB is not something I would support. Many JDO users will want to exploit the services of Session and MessageDriven Beans for large server-side applications (although others are content with just Web components).

    It is the Entity Bean component of EJB that has been superceded.
  21. I see no problems to drop EJB, CMP/BMP are the best candidate to drop. Probably statefull beans can be usefull in some cases, but I think any real programmer can implement this kind of framework (wrapper for RMI and JMS) at home (2 - 3 days to work) and can do it better than EJB.
  22. Agreed. EJB definitely need a good an object-oriented persistence service, and JDO is a good object-oriented persistence framework. Simplifying J2EE is certainly not about building EJB as an all-needs API, but rather make J2EE federate all specialized Java API (JTA/JTS transactions, RMI distributions, JAAS security and JDO persistence) instead of re-inventing them. Everybody can see that CMP 2 and 3 are going more and more closely toward JDO principles. JDO surely can fit well as a CMP service (like JTS underlies JTA for instance) given some minor adaptations in one specification or another. Furthermore, it would make CMP even more transparent, simple, efficient and usable. Once again, keep in mind that EJB is a component framework. It needs a persistence service, but is not a persistence framework (more about this on http://www.theserverside.com/discussions/thread.tss?thread_id=18546).
  23. Anything new here ?[ Go to top ]

    So it really is refreshing for such well respected bodies as IBM, BEA, and Oracle to provide a full analysis of the drawbacks of JDO 2.0. Have they actually listened to their users requirements, or just to their accountants maybe ?

    Who gets voting rights for these things ? Perhaps since these bodies are clearly not reflecting the needs of their users they should be removed.
  24. Another performance question[ Go to top ]

    Since everyone’s here, I want to repeat my JDO performance question. Many say they like JDO and it’s easy to use. I have yet to see claims that in production JDO performance is as good or nearly as good as Hibernate, TopLink, or plain JDBC. I left out entity beans deliberately. And how do JDO generated database schema’s stack up?

    Gary
  25. Since everyone’s here, I want to repeat my JDO performance question. Many say they like JDO and it’s easy to use. I have yet to see claims that in production JDO performance is as good or nearly as good as Hibernate, TopLink, or plain JDBC. I left out entity beans deliberately. And how do JDO generated database schema’s stack up?Gary
    When you talking about JDO - you need to point to specific implementation, JDO is just a spec.

    I'm using JDO in every my project at least for last year (several projects total) and I never have problems with performance. In fact I’d like to see any "home-grown plain JDBC" implementation with full support of transparent persistence, full implementation of transaction isolation and multi-level distributed cache. And than we will see how it performs :-)

    Best,
    Igor.
  26. Another performance question[ Go to top ]

    Since everyone’s here, I want to repeat my JDO performance question. Many say they like JDO and it’s easy to use. I have yet to see claims that in production JDO performance is as good or nearly as good as Hibernate, TopLink, or plain JDBC. I left out entity beans deliberately. And how do JDO generated database schema’s stack up?Gary
    JDO provides as good if not better performance (due to more sophisticated field tracking) as O/R software (and certainly without the EJB overhead). Performance is dependent on the implementation (though since JDO is standardized, comparing is quite feasible). And while there certainly are simple cases where JDBC can beat all, the more complex the situation the better these persistence layers will perform in comparison.

    Most if not all JDO implementations allow you to customize the schema generated, most likely matching what is already there from DBA or legacy.
  27. So it is perceived legitimate to argue against JDO on the grounds that attempts to simplify a component-based model for persistent data (Entity Beans) in JSR-220, which might hit the streats in a year or more, somehow obviates the need for furthering an EXISTING standard for transparent persistence of POJOs?

    I'm rather amused, but the fact that BEA, IBM and Oracle forgot to put smiley faces after their comments makes me wonder if they're actually serious after all!?

    I'd like to thank those members of the Executive Committee who voted in favour of JDO 2.0 (including Macromedia).

    Kind regards, Robin.
  28. What BEA, Oracle and IBM fail to understand is that we don't want no stinkin' entity beans, even if they chop off a heel and a toe to make it less of a pain than it is now. Or perhaps it is just not in their best interests to support the adoption of lightweight solutions that don't tie us down to application server and/or tools vendors.
  29. But why should persistence be tied to the EJB specification? What about web applications running in web containers? What about standalone apps?

    I see a real value for JDO, not only in the context of J2EE applications using EJB, but in a wider range of contexts.

    Regards,
    Rod
  30. What about standalone apps?
    Exactly. How is EJB 3.0 supposed to help with a two-tiered desktop app?
    I see a real value for JDO, not only in the context of J2EE applications using EJB, but in a wider range of contexts.
    JSR 243 also includes this:

    A subset of functionality would be appropriate for J2ME but this will require a separate JSR.

    Kris
  31. The JSR-220 submission talks about simplification of the EJB programming model. Unlike JDO 2.0 which was conducted in public until our JSR-243 was approved yesterday, JSR-220 is taking place behind closed doors until such time as a draft specification is available. This makes it hard for outsiders (my application to join JSR-220 was declined) to know what form their work is taking.

    Based on the JSR submission document, a heavy emphasis is being placed on JSR-175 Metadata extensions to reduce the size and complexity of deployment descriptors, and to remove the need for the developer to provide home and remote interfaces as all required information could be marked up in the bean class itself. This would be welcome progress, although these techniques have been used for years by X-Doclet adopters and are not exactly new.

    What we cannot tell is how JSR-220 will address specific limitations of the Entity Bean model in particular - just being able more simply to write the same deficient entity beans does not necessarily help. What about polymorphism? What about dynamic queries? What about testability? What about in-and-out of container operation? What about, dare I say it, transparency? And without the ability to encapsulate data, can entity beans ever be more than mere data structures? In its current incarnation the concept of a "behaviourally complete" object model built with entity beans is utterly laughable.

    So where is the Entity Bean value-add?

    Entity Beans have method-level permissions which JDO does not have. The JDO folks generally feel it inappropriate to restrict access to persistent objects at the method level as it's really a business process thing and belongs in the application itself at the point of transaction demarcation. Entity Beans have container-managed relationships, because entity beans are merely data structures and cannot undertake their own relationship management effectively. The JDO folks believe Java developers can manage associations through the object model in various ways, and that a "persistence" service should not alter the way that the object model behaves. Everything else that Entity Beans can do is more easily, more appropriately and more flexibly done by JDO (e.g. transparency, polymorphism, testability, dynamic queries, O/R mapping) independent of the presence of a Web/J2EE container.

    If the JSR-220 folks simplify the programming model for EJBs then the community will be happy. But imagine the accolades they would receive were they to adopt JDO, make it accessible directly by the developer, and additionally provide a "method-level permissions service" (for those who want one) to augment POJOs!

    Kind regards, Robin.
  32. What we cannot tell is how JSR-220 will address specific limitations of the Entity Bean model in particular
    Indeed. Voting to prevent evolution of JDO is dangerous when JDO 2.0 has already taken shape and will be very powerful, while EJB 3.0 is just talk--even if it's sounding like promising talk. Important new JDO 2.0 features such as attach/detach are already available in robust implementations. EJB 3.0 is still in the inception phase and has a long way to go to be a workable reality.

    But as seveal people have pointed out, JDO 2.0 is going to happen anyway, so there's limited point in dwelling on the dissenting minority voices.
  33. Exactly. Look at the popularity of the lightweight transparent persistence model. People like it because it's easy, it facilitates rapid development, it's portable, and it's got a low ongoing cost. I don't think you could level these claims at EJB, and I'm not sure how much EJB 3.0 is going to change this at all.
  34. The JSR-220 submission talks about simplification of the EJB programming model. Unlike JDO 2.0 which was conducted in public until our JSR-243 was approved yesterday, JSR-220 is taking place behind closed doors until such time as a draft specification is available.
    Robin, you are right that such has been the case so far but it's going to change soon. There are two EJB 3.0 events at TheServerSymposium this coming week:

    - A presentation by Linda de Michiel
    - A BOF to discuss with the community and get feedback.

    More information:

    http://wiki.theserverside.com/symposium/display/MEETINGS/Home
    http://www.theserverside.com/symposium/schedule.html

    --
    Cedric
  35. <quote>
    - A presentation by Linda de Michiel
    - A BOF to discuss with the community and get feedback.
    </quote>

    Shouldn't the community have been involved before now?
  36. Shouldn't the community have been involved before now?
    There have been many, many community inputs into the EJB 3.0 JSR. A few examples:

       http://servlet.java.sun.com/javaone/sf2003/conf/bofs/display-2264.en.jsp
       http://www.xpdeveloper.com/xpdwiki/Wiki.jsp?page=Xtc20031014
       http://www.theserverside.com/news/thread.tss?thread_id=23670
       http://www.ot2004.org/cgi-bin/wiki.pl/?TowardsEjbThree

    And there's always jsr-220-comments at jcp dot org for anyone with views and access to e-mail.
  37. OK, but where can we get a clear idea of where the overlap actually is? Is there anywhere we can get an overview of how the JDO transparent/declarative persistence interferes or overlaps with the proposed EJB implementations, and in what manner?
  38. In my opinion (not my Company's) either the simplified EJB as part of 3.0 or JDO 3.0 should be part of J2EE 1.5. As is J2EE is too complex and is NOT ALL attractive for new developers and many new additions will distract new developers. Looks like the primary goal for J2EE 1.5 to simplify development and having two persistence model will again confuse the developers .. EJBs have been in use by several enterprise and J2EE being for Enterprise EJB is the right choice. As several guys in the community pointed that JDO has several other usage other than the persistence model for J2EE applications let Sun keep this as a separate JSR and separate standard. Many and many JSRs is making J2EE complex and .NET is gaining ground. As JCP has been sponsoring the TSS Symposium they must be fan of this community and the JCP expert committee must be reading all these threads and listening the complaints about EJB. What we hear about the new EJB 3.0 model it looks like these guys have heard all our complaints and trying to address these.

    Looks like JBoss/Hibernate is also fully engaged with EJB 3.0 as evident from http://www.infoworld.com/article/04/04/30/HNfleury_1.html and they must be loving the fact EJB 3.0 is being modelled after Hibernate. would be interested to know their take on the controversy for JDO 2.0 vs 3.0 as Gavin is part of both the committees
  39. The technology used to persist objects should be *pluggable*. I should be able to use Hibernate or JDO or anything I want to. The more you try to design a spec to be able to do this, the more you see that the EJB *contract* is the right one.
  40. The technology used to persist objects should be *pluggable*. I should be able to use Hibernate or JDO or anything I want to. The more you try to design a spec to be able to do this, the more you see that the EJB *contract* is the right one.

    I think you missed the point. JDO is pluggable (you can use different JDO implementation if you like). JDO API is somewhat like JDBC or JMS. That is the point, make the object persistence a service, a resource, not a container feature.
  41. The technology used to persist objects should be *pluggable*. I should be able to use Hibernate or JDO or anything I want to. The more you try to design a spec to be able to do this, the more you see that the EJB *contract* is the right one.
    J2SE already has a POJO-persistence technology that works in a plain JVM, in a Web container and in a J2EE container.

    Why should J2EE simultaneously engineer a POJO-like persistence technology that ONLY works inside an EJB container?

    Yes, the object model should be independent of the persistence technology (JDO achieves this).

    Yes, the application should be independent of the datastore (JDO achieves this).

    If you want the application additionally to be independent of the persistence technology then you must facade the persistence technology, either by detached operation or by some DAO-like concept. But beware that DAO implementations tend to be very invasive, often resulting in lowest-common denominator functionality. They can also perform badly for that reason. For example, how would you represent persistence-by-reachability in a DAO interface?

    I argue that PersistenceManager already IS the DAO interface for all object persistence across all datastores.
  42. J2SE already has a POJO-persistence technology that works in a plain JVM, in a Web container and in a J2EE container.
    Can you be more specific?

    J2SE only has JDBC and RowSets, none of which are POJO-based.

    --
    Cedric
  43. JDO is a standard extension - javax.jdo. In this form it is an official part of J2SE. It is not part of the JDK download which is a different story. Did you think otherwise?
  44. JDO is a standard extension - javax.jdo. In this form it is an official part of J2SE. It is not part of the JDK download which is a different story. Did you think otherwise?
    I guess I have a more simplistic view of what an "official part of J2SE" is...

    If I can't do "javap javax.jdo.PersistenceManager" on a standard JDK, then it's not part of J2SE to me...

    --
    Cedric
  45. If I can't do "javap javax.jdo.PersistenceManager" on a standard JDK, then it's not part of J2SE to me...
    I'll speak to Joshua Bloch about this, but as far as I know we've gone as far with JDO as is possible within the JCP concerning J2SE. The JCP certainly regards JDO as a J2SE technology of equal standing with the others you mention....
  46. Political?[ Go to top ]

    I just want to ask EJB vendors these questions:
    - do have any technical reasons for voting against JDO? Specially considering the mess EJB is and EJB3 will be because of the inherent flaws in EJB/CMP architecture.
    - I think the -1 votes were just political. So what's the real political reason for voting againt JDO? You just don't want to let JDO kiddies in your club? You don't want to let Hibernate/JBoss be influential in forming the spec? You want to lock people to the container and squeeze them? :-) What?
    - Do you actually care what the community demands??
    - Will I get any answers to these questions? Of course not :-)

    Ara.
  47. The technology used to persist objects should be *pluggable*. I should be able to use Hibernate or JDO or anything I want to. The more you try to design a spec to be able to do this, the more you see that the EJB *contract* is the right one.
    Surely this is why we have the Data Access Object (DAO) design pattern is part of Sun's J2EE Blueprints. By using a well-understood DAO tier you get abstraction from the persistence technology (JDBC, Entity Beans, JDO, Hibernate, and so on) and you can use the DAO classes in J2EE applications *and* from J2SE applications.

    There are even a bunch of products (commercial and open source) out there to generate DAO code for you.

    FireStorm/DAO is one example that already supports JDBC, Entity Beans, and JDO behind a common DAO interface. Hibernate support will be available in the next release.

    Cheers,

    Andy Grove
    Code Futures, Ltd
  48. Hi Andy
    By using a well-understood DAO tier you get abstraction from the persistence technology (JDBC, Entity Beans, JDO, Hibernate, and so on) and you can use the DAO classes in J2EE applications *and* from J2SE applications.
    The problem comes with the variance in granularity and applicable abstraction layers of different persistence technologies.

    The "traditional" DAO pattern requires that you get a DAO object from a factory that has been configured for your particular target datastore; that you use the DAO manage (create/save/delete) persistent objects. The DAOs for different underlying persistence mechanisms all implement the same interface, giving you portability over (and abstraction from) the various supported datastores. So far so good.

    But in practice this often breaks down. With the transparent persistence implementations you obtain a persistent object, alter it within a transaction (perhaps adding transient instances into the graph) and finally commit your transaction. There is no save() invocation. On commit, the persistence layer knows (e.g. JDO) or determines (e.g. Hibernate) which objects have changed and synchronises these changes to the datastore, usually by emitting minimalist SQL and not writing back unaltered fields. Additionally the persistence-by-reachability algorithm (JDO) or equivalent (Hibernate) kicks in, identifies all reachable transient instances of classes capable of persistence, inserts these into the datastore and configures the relationships accordingly. All just on commit().

    It is not possible to create a DAO interface which retains the development productivity of the transparent persistence approach whilst maintaining support for traditional stores. The temptation is to require an explicit save() or create() invocation for all instances of the graph which is not acceptable to the "transparent persistence" community.

    Of course, what you could do is write a DAO which facilitates usage of JDO or Hibernate. I suggest that in this case the DAO interface should be javax.jdo.PersistenceManager, which is exactly how Hibernate is expected to achieve their compliance.

    Another thing you can do is implement a PersistenceManager whose back-end datastore is EJB Entity Beans. This would feel a little weird, but JDO is deliberately datastore agnostic so it should be feasible. Now it becomes that particular PersistenceManager implementation's responsibility to navigate the committed object graph and issue individual invocations on an underlying graph of Entity Beans, in a similar way to the emission of SQL to an underlying relational database by the present tranche of JDO implementations.

    That said, I have not had time to look at your company's product. Feel free to point out the shortcomings of my posting. Until then PersistenceManager is the DAO interface.

    Kind regards, Robin.
  49. The following quote from the FireStorm/DAO website neatly illustrates the problem:
    A typical DAO interface is shown below.

    public interface CustomerDAO
    {
      public void insert(Customer customer)
       throws CustomerDAOException;

      public void update(CustomerPK pk, Customer customer)
       throws CustomerDAOException;

      public void delete(CustomerPK pk)
       throws CustomerDAOException;

      public Customer[] findAll()
       throws CustomerDAOException;

      public Customer findByPrimaryKey(String email)
       throws CustomerDAOException;

      public Customer[] findByCompany(int companyId)
       throws CustomerDAOException;
    }
    To benefit from the portability promised by this approach I must religiously invoke the services of the DAO, programmatically insert()-ing and update()-ing records even though I know that JDO/Hibernate would do this for me transparently. Simplistic DAO-based approaches cannot realize the productivity gains of the transparent persistence movement.

    PersistenceManager is the DAO interface (Am I in danger of getting religious?)
  50. Of course, what you could do is write a DAO which facilitates usage of JDO or Hibernate. I suggest that in this case the DAO interface should be javax.jdo.PersistenceManager, which is exactly how Hibernate is expected to achieve their compliance.
    Perfectly valid approach but the whole point of using the DAO interface is to abstract from the underlying persistence technology. Your suggestion is to tie it into the JDO API.
    PersistenceManager is the DAO interface (Am I in danger of getting religious?)
    Yes, but that's fine. There are many perfectly valid approaches to persistence and there is no "correct" solution (although arguably there are a few "wrong" ones!)

    If JDO fills your needs and you never want to move away from that API that's fine. If you want abstraction with the ability to plug-and-play with the persistence technology then DAO is ideal. One size doesn't necessarily have to fit all.
  51. One size doesn't necessarily have to fit all.
    Great, so we can "live and let live"!
  52. DAO design pattern isn't[ Go to top ]

    I've been through all these things a long time ago.

    First we used Versant OODBMS. Easy to use, even for unexperienced programmers,
    but locks you in.

    Then I designed a little sub-project using the DAO design pattern to make
    it independent from the persistence technology. WHAT A WASTE OF TIME!
    You are writing class after class just plumbing things together, after that
    your business code looks like a one big mess.

    In annother project we used CMP. Holy moses, why do I have to seperate my business logic/application logic when the only logical place is in the damn CMP beans?
    All this nonsense about putting your logic in statless session beans, opening up
    your persistent beans with numerous public setters/getters is breaking
    all rules about a clean, encapsulated and simply OO design!
    Every public method you have is one your developers will screw around with.

    Then I tried JDO and the world was fine again! I could reduce the number of
    public methods significantly, putting all user-editable data in more or less
    generic DTO-objects, leaving the business logic right in the classes I would
    use for persistence, reducing the lines of code significantly.
    Now our sessions beans rarely do more than getting a persistent object by
    Id and calling a business method right inside there and it is working
    wonderfully.
    Changes to the system are wonderfully localized (no traveling through n tiers
    just to add an attribute to a class) and performance is good.
  53. Holy moses, why do I have to seperate my business logic/application logic >>when the only logical place is in the damn CMP beans?

    It's for entity bean re-use accross applications or use-cases.
  54. The technology used to persist objects should be *pluggable*. I should be able to use Hibernate or JDO or anything I want to. The more you try to design a spec to be able to do this, the more you see that the EJB *contract* is the right one.
    Completely agree. Hibernate, JDO, JDBC, CMP EJB, whatever DAO is the best fit.
    The more you try to design a spec to be able to do this, the more you see that the EJB *contract* is the right one.
    See above... EJB is just one option - sometimes the best.
  55. Hi Cedric. Thanks for letting us know. I participated actively in an EJB 3.0 BOF at OT2004 last month. This event was led by Scott Crawford and was thoroughly enjoyable.

    The 3-hour workshop ended with a balloon debate: we all took "issues" about EJB and voted the less important ones off the balloon until only three remained. My issue, that the Entity Bean architecture "fails to support the design of behaviourally rich domain models", was eventually voted off. The three issues which remained in the balloon and were deemed "most important" included:

    - Testability
    - Support for Transparent Persistence
    - Unchecked Exceptions

    You can read more about this particular workshop at OT2004. I'd like to thank Scott for a most exhilarating and (I hope) constructive event.
  56. Thanks Robin. I'm glad you enjoyed the event at OT2004. The URL you provided is one of the four I cited just above.

    Best
    Scott
  57. At some level isnt it comparing Apples vs. Oranges? JDO is very good for standalone applications. And for applications that have OO well enmeshed into the persistence layers. But in an EJB context, for biz apps, there is very little value that JDO offers.

    The often cited Polymorphism and Testability- are they of much use? In a biz app, how often would one want to inherit a "DB class"? Informix had this amazingly well conceived OR-DBMS. Which provided for all these capabilities- at the DB table level! Didnt do a swat in the market! The usage of table (by extension the persisted classes) level inheritance is a very niche segment. Most biz apps wont need this capability. Testability may be of some value- again here in a class that wraps DB tables, only thing that may need to be tested is the queries. A standalone EQL execution tool may help. But this is not of much value.

    About the metadata, if one is anyway dealing with the EJB XMLs such as ejb-jar XML and vendor XMLs, is the incremental cost of using CMP is lower than that of using JDOs? Which have its own XMLs to deal with. One sure shortcoming in CMP is the lack of dynamic queries.

    But otherwise, there is very little value (and probably more painful) to use JDOs in an EJB app (in JSP/Servlets- the arguments may not be the same). ( More on my blog).

    Cheers,
    Ramesh
  58. Hi Ramesh. I read your blog - you write very well.

    There is still some wild use of the acronym EJB. There are complaints in this thread regarding the unsuitability of Entity EJBs, but there have been no complaints about the other EJB types.

    Entity Beans were defined to represent data that could benefit from the EJB container&#8217;s services of remoteness, declarative transactions and method-level permissions. They also exploit the server's bean pooling policies, but 1.4.2 JDKs largely remove the need through faster object instantiation, and JDO implementations are free to pool instances if they choose.

    Since then, it has been realised in the field that data usually should not be remote, and that method-level permissions and declarative transactions belong in the business process and not in the persistent data underpinning that process.

    Polymorphism in JDO includes the ability to persist a reference to an instance of a subclass or interface implementing instance, and get back that same object on iterating a query. And yes, although inheritance should not be used inadvisably, there are good rules governing its applicability. Here are two examples of inheritance in a real financial persistent domain model.

    Position : holding of an instrument in an account
    CompoundPosition extends Position : composite position made up of sub-positions

    Instrument : a financial instrument
    InstrumentWithCoupon extends Instrument : instruments which pay dividends
    Currency extends Instrument : instruments recognized on the money markets

    So those are real inheritance hierarchies which satisfy the "is-a" rule (and Peter Coad's other rules for inheritance). In JDO, if you query for Instruments you might get some Currencies, at which time your reference actually points to a Currency object (not just its Instrument representation).

    JDO is indeed excellent for stand-alone applications. But it is also excellent for Web/J2EE container-based apps. And you can use it against the same datastore from all these different architectures at the same time!!! It provides a degree of future proofing that your stand-alone application can scale to the enterpise. Entity beans lock you into a J2EE container from the start of your application design. This should no longer be acceptable to the community (evidence the concerns expressed about Entity Beans) and with JSR-220 underway perhaps now is the time to get something done about the situation.

    Kind regards, Robin.
  59. Hi Ramesh
    in an EJB context, for biz apps, there is very little value that JDO offers. The often cited Polymorphism and Testability- are they of much use? In a biz app, how often would one want to inherit a "DB class"?
    Well thats probably because domain models built for entity beans have to be simple. You cannot use the full range of OO design techniques that are available with JDO. Limited, EJB style models work for PetStore type apps. Real world business apps benefit from JDO.

    Cheers
    David
    www.jdogenie.com
  60. Hi Ramesh
    in an EJB context, for biz apps, there is very little value that JDO offers. The often cited Polymorphism and Testability- are they of much use? In a biz app, how often would one want to inherit a "DB class"?
    Well thats probably because domain models built for entity beans have to be simple. You cannot use the full range of OO design techniques that are available with JDO. Limited, EJB style models work for PetStore type apps. Real world business apps benefit from JDO.CheersDavidwww.jdogenie.com
    Surely there is a class where OO can be applied even for DB classes. My point was that in biz apps is it such a pressing need? As I mentioned, Object Dtabases never gained mainstream acceptance. Probably due to unproven reliability. But even the reliable mainstream DBMS vendors (IBM & Informix) when they extended the DBMS onto ORDBMS , the OR part never got accepted in the market.

    Again, one could argue that unless the whole applciation design is OO, the OO aspect of DB cannot be used. But even in pre Java days, C++, PowerBuilder & Delphi were quite rampantly used for Biz apps. where again, not much traction for ORDBMS.

    Even in this thread, if you look at the USPs cited for JDO, lot of them apply for non EJB environments. IN EJB, dont believe JDO offers much value when compared to CMP. Even the oft repeated 'complexity' in CMP is weak, as the dev mechanics are not too different between CMP and JDO. By no means a no-brainer decision that CMP is bad and JDO is good.

    [ps: even as a J2EE vendor, we support JDO. JDO does offer a good portable platform for non EJB environments. But we also believe that there cannot be an identical persistence framework for both non EJB and EJB environments. EJB environments can benifit from some EJb specific semantics such as declarative Security and Transaction model- that CMP does leverage]

    Cheers,
    Ramesh
    http://www.pramati.com
  61. For the avoidance of doubt, JDO does leverage Container Managed Transactions (CMT) and this is not "optional".

    The niche uptake of ODBMS can be attributed to the lack of meaningful standards in the area, overly complex and incompletely implemented standards (ODMG), and the widespread adoption of SQL. Coincidentally, now that JDO exists it is "safe" to experiment with ODBMS technology since all your application investment is preserved should you go back to the relational world.

    But my position is not to back ODBMS. I want to see Java developers supported (by the J2EE stakeholders) in their adoption of transparent object persistence, regardless of the back-end datastore to which their manipulations and persistence objects are mapped.
  62. Polymorphism and EJBs[ Go to top ]

    Just a small comment to Ramesh -- EJBs not providing polymorphism and this being perhaps unnecessary in the real world... ?

    One example I like is Accounts Receivable. Transactions can often be subtyped as to Invoice, Payment, and then special adjustment/ journal types; as differing information is used and recorded for the differing types. Yet, the transactions are also reported, summed, analyzed overall.

    And, as applications go, this is about as close to the heart of any existent business as you can get. (Businesses which do not treat receivables as important tend not to remain existent).

    So this is a pretty solid example.

    JDOs versus EJBs, from within an EJB app? I think this could be a very effective solution, involving rather less pain than more. Ugliness - gone. Overhead - gone. Semi-manual management - gone. Flexibility of navigation and querying - better. Testability - convenient in or out of container.

    Just to imagine development and testing without the grinding complexity, deployment overhead and impenetrable opacity of debugging in container. Get rid of these from your code/ test cycle, and you could double the speed at which you code and implement changes.

    Then, once the code is complete, you can load it into the container and have your Session beans still provide security, transactionality and all the heavy-weight management.

    Just a few thoughts anyway,

    Regards,
    Thomas
  63. Both have merits[ Go to top ]

    What about polymorphism? What about dynamic queries? What about testability? What about in-and-out of container operation? What about, dare I say it, transparency? And without the ability to encapsulate data, can entity beans ever be more than mere data structures? In its current incarnation the concept of a "behaviourally complete" object model built with entity beans is utterly laughable.So where is the Entity Bean value-add?
    How many years have developers been griping about distributed transactions/objects. If only management types and CTO's didn't jump on buzz words and did what makes sense; I don't think EJB's and entity beans would have such a bad rap. Most applications simply don't need it. But when you really need distributed objects, because your application handles numerous concurrent sessions with shared data, a JDO model won't cut it. Of course, the easy solution is to not provide those types of features in your application and use a reasonable poll mechanism. Sure there's a greater lag, but if the lag is acceptable, a simpler JDO based approach is better. I don't know about others, but managing distributed objects with polymorphism is harder than one would think. How would a server determine which database table to save to? If object C extends B, which extends A. How is the EJB suppose to manage persistence. It's hard enough managing distributed objects in a persistent manner that adding polymorphism would be asking for trouble. I don't think there will ever be a clear answer for extending EJB to support polymorphism. But I'm not expert and most likely wrong. I agree completely that EJB spec could be simpler and easier to use, but my take is each one is driven by different requirements.
  64. Both have merits[ Go to top ]

    Hi Peter
    But when you really need distributed objects, because your application handles numerous concurrent sessions with shared data, a JDO model won't cut it.
    I will take issue with the above statement shortly (in an entirely friendly way). First of all I wanted to clarify your meaning when you refer to "distributed objects".

    (a) I have data as objects on one machine which I want to access remotely in the RMI sense
    (b) I have two different JVMs (logical tiers) which simultaneously require access to the same persistent data as objects
    (c) Both of the above
    (d) Something different

    Thanks, Robin.
  65. me being unclear, duh![ Go to top ]

    Hi Peter
    But when you really need distributed objects, because your application handles numerous concurrent sessions with shared data, a JDO model won't cut it.
    I will take issue with the above statement shortly (in an entirely friendly way). First of all I wanted to clarify your meaning when you refer to "distributed objects".(a) I have data as objects on one machine which I want to access remotely in the RMI sense(b) I have two different JVMs (logical tiers) which simultaneously require access to the same persistent data as objects(c) Both of the above(d) Something differentThanks, Robin.
    The type of application I'm thinking of is this. I worked on a wireless platform back in 2K. The primary audience was Vertical (ie, business market). One of the things we wanted to do was perform WAP alerts in real-time, or as close to real-time as possible. The scenario was this. Say a sales rep has a meeting at 3 pm and he is on the road in the morning until noon. While he is on the road, he also wants to know if certain pieces of information instantly because a big customer wants to know ASAP. The system has registered the sales rep and the customer for an alert. We were given the requirement of, anyone can change both pieces of data and everyone with an active session or alert subscription must be notified. Being a wireless platform, most of the time global data like meetings/calendars were in multiple HttpSessions. this meant we had to use JMS to notify all beans of changes, since we didn't have time to break the EJB's down into managable chunks. I could be wrong, but in a pure JDO model where each webserver uses something like hibernate, coordinating the events would be more troublesome and would still require either JMS or an EJB to make sure all current copies of the data are updated.
    Another variation of this scenario is the sales rep is traveling for a big meeting. His meeting goes over and he won't make his flight. With WAP we could poll the phone for it's GPS long/lat. The feature requested was this. If sales rep John Doe can't make his flight because the flight is in 20 minutes and we know it's 45min from the airport, send him an alert if the flight is on time. But the system was also suppose to send him potential actions, like reschedule for a later flight, book a hotel room, rent a car, find a place to eat, alert people he won't make it. In this case, we were getting regular data feeds for flight data and every piece of data that could be geocode had long/lat stored in the db. Obviously, these are very ambitious goals to strive for. Using HttpSessions worked in many cases, but our QA exposed the weakness of that approach by sending updates on one system, while simultaneously viewing in multiple clients. We eventually analyzed the use case and broke the data into managable chunks and put them in an EJB, so that when a client views the data they are getting accurate information.
    my apologies for the delay in response, got caught up in work. you know how that goes. So to answer your question, the use case called for "c" and "d". because in some cases a transaction on a remote system needs to propogate those changes through the entire system.
  66. me being unclear, duh![ Go to top ]

    Being a wireless platform, most of the time global data like meetings/calendars were in multiple HttpSessions. this meant we had to use JMS to notify all beans of changes, since we didn't have time to break the EJB's down into managable chunks. I could be wrong, but in a pure JDO model where each webserver uses something like hibernate, coordinating the events would be more troublesome and would still require either JMS or an EJB to make sure all current copies of the data are updated.
    Hi Peter,

    I don't see how it would be more troublesome in the JDO case - you would use JMS to coordinate the changes (as in your example), and then persist them as normal? It seems an almost identical situation - Or am I missing something here?
  67. Mostly[ Go to top ]

    Being a wireless platform, most of the time global data like meetings/calendars were in multiple HttpSessions. this meant we had to use JMS to notify all beans of changes, since we didn't have time to break the EJB's down into managable chunks. I could be wrong, but in a pure JDO model where each webserver uses something like hibernate, coordinating the events would be more troublesome and would still require either JMS or an EJB to make sure all current copies of the data are updated.
    Hi Peter,I don't see how it would be more troublesome in the JDO case - you would use JMS to coordinate the changes (as in your example), and then persist them as normal? It seems an almost identical situation - Or am I missing something here?
    Like I said, we ended up using JMS to update all the beans in HttpSession, but it didn't provide the level of "real-time" that was requested. In some cases, it might be minutes. The issue is the combination of several factors. We did consider a plain "ORM" approach and not require transactional integrity for the majority of the "update events." Let's say the sales rep won't make his 5pm flight, but the flight is delayed an hour. Taking the easiest route, the user may get two alerts. Flight delays typically are known earlier, unless the delay is the result of boarding or technical problems. If the user's GPS event is known before the flight delay, he'll obviously get two alerts. This case isn't that big of a deal. It's the action side of things that gets tricky. Say the rep can't make his flight and one of the options is "book a later flight, otherwise get a hotel and book morning flight." In this case, the data needed to execute the user's action really depends on distributed transactions. If a query to the airline returns an open flight, you still have to make sure the transaction goes through before sending all the notifications. If the flight is booked, and the user has stay overnight, you may still have a problem. Given the sales rep is already late, chances are he won't be able to call up a travel agent and rebook his travel plans. In the end, we had to really understand the business requirements and apply EJB carefully. There are cases requiring real-time data + distributed transactions, and in those cases my biased feeling is EJB is more appropriate. Not that it can't be done with JMS or some other approach, but it gets more complicated. Doing it in a JMS approach the system might end up requiring rollbacks and end up double charging the customer. I'm all for simplicity and using JDO or hibernate. Convincing business types that certain requirements un-necessarily complicates the architecture is often the hardest part. There are plenty of other distributed transaction applications, which JDO wouldn't be appropriate, but I won't get into that.
  68. Mostly[ Go to top ]

    There are plenty of other distributed transaction applications, which JDO wouldn't be appropriate, but I won't get into that.
    JDO integrates perfectly well into the distributed transactions of your appserver of choice. I think most of the arguments here are saying that JDO can replace entity beans as the persistence solution for an application, not that it replaces all the other services an application server provides.

    The fact that JDO can integrate with distributed transactions and has settings that allow you to control when object state is transparently re-fetched from the DB should be enough to ensure that you maintain transactional integrity and always read the latest state (at your choosing; you can also allow some expired data to be read for greater performance), even in distributed apps. Also, most commercial JDO implementations have distributed L2 caches that you can turn on to boost performance.
  69. I would agree in limited cases[ Go to top ]

    There are plenty of other distributed transaction applications, which JDO wouldn't be appropriate, but I won't get into that.
    JDO integrates perfectly well into the distributed transactions of your appserver of choice. I think most of the arguments here are saying that JDO can replace entity beans as the persistence solution for an application, not that it replaces all the other services an application server provides.The fact that JDO can integrate with distributed transactions and has settings that allow you to control when object state is transparently re-fetched from the DB should be enough to ensure that you maintain transactional integrity and always read the latest state (at your choosing; you can also allow some expired data to be read for greater performance), even in distributed apps. Also, most commercial JDO implementations have distributed L2 caches that you can turn on to boost performance.
    Simple transactions which do not have complex commit dependencies I can see it working better than entity beans within an EJB. JBoss uses hibernate now right, so absolutely JDO compliments EJB. I personally what all the fuss is about EJB. The benefit that I see in EJB is there's a central entry point for data which is invoked remotely, has some transactional requirements defined by business requirements and has real-time needs. If you remove one of those, my opinion (flawed it may be) is you could probably get away with just JDO and JMS. the EJB expert group do deserve credit for the good things in the spec.
  70. I would agree in limited cases[ Go to top ]

    The EJB expert group do deserve credit for the good things in the spec.
    I agree. Furthermore, I don't think any weight of criticism from this thread has been targetted anywhere other than the EJB 2.0 definition of persistence, and the arrogance of the big vendors in believing that the community will let them have a third attempt to define enterprise persistence in the light of existing transparent persistence solutions.

    EJB 1.0 Entity Beans were broken.

    EJB 2.0 Entity Beans deviated so substantially from 1.0 as to eliminate backward compatibility.

    EJB 3.0 ? If it really is transparent persistence then bang goes backward compatibility again. If it's just a means to simplify the developers drudgery in creating the same Entity components, then it doesn't matter because Entity Bean adoption will continue to fall as the transparent persistence solutions gain further traction in the enterprise.

    Kind regards, Robin.
  71. Politics vs common sense[ Go to top ]

    The EJB expert group do deserve credit for the good things in the spec.
    I agree. Furthermore, I don't think any weight of criticism from this thread has been targetted anywhere other than the EJB 2.0 definition of persistence, and the arrogance of the big vendors in believing that the community will let them have a third attempt to define enterprise persistence in the light of existing transparent persistence solutions.EJB 1.0 Entity Beans were broken. EJB 2.0 Entity Beans deviated so substantially from 1.0 as to eliminate backward compatibility.EJB 3.0 ? If it really is transparent persistence then bang goes backward compatibility again. If it's just a means to simplify the developers drudgery in creating the same Entity components, then it doesn't matter because Entity Bean adoption will continue to fall as the transparent persistence solutions gain further traction in the enterprise.Kind regards, Robin.
    Now if only big business used common sense more and politics less. We can all get on with development. Plus, I see no reason using proprietary software unless it really is better. In many cases, hibernate and other open JDO implementations meet the needs of the typical application needing a clean persistence layer. JDO 2.0 can easily work with EJB and compliment it really nicely. It can provide the best of both worlds in one application server. It sure would make development easier and let EJB do the work it's designed to do and reduce the amount of load on the application server.
  72. EJB 3.0 at TSS Symposium, Las Vegas[ Go to top ]

    I've been monitoring the sites throughout the evening from here in the UK and the first blogs from Linda DeMichiel's session on EJB 3.0 are now appearing.

    Although there are several sources, Jason Carreira seems to have produced a particularly comprehensive blog on the topic.

    It would appear from his and from other's comments that the EJB 3.0 group disapprove of JDO's persistence-by-reachability and now-optional bytecode enhancement. For this reason much of the proposed EJBQL they are illustrating apparently looks remarkably like HQL. Indeed, there are comments that the examples themselves are either out of the Hibernate documentation, or are heavily influenced thereby.

    Other interesting comments include assurances that EJB 3.0 will not deprecate any of the facilities from EJB 2.0 / 2.1, which is good or bad depending on your perspective....
  73. Two more things:

    1. CMR will no longer be provided. This quietly validates JDO's approach in this area - relationships managed by the domain object model with assistance only for efficient cascading deletes.

    2. An EJB 3.0-compliant container must backwardly support EJB 2.0 and 2.1. This effectively closes the application server marketplace to new entrants.

    The side-stepping of JDO (a healthy market of persistence technology vendors competing to implement a standard spec) and the effective closure of the application server marketplace to the "lightweight container" players actually strikes me as anti-competitive. But perhaps it's merely that it is late and I am tired....
  74. EJB 3.0 at TSS Symposium, Las Vegas[ Go to top ]

    I also read all the blogs on TSS EJB 3.0 talk. Frankly, I sense EJB 3.0 may now have stolen some thunder back from JDO 2.0 whuch has built up in the last several days. Now EJB 3.0 seems to be completely sold on Hibernate, and Gavin King of JBoss is exerting all kinds of influence on the direction of EJB 3.0, the question is will he participate in JDO 2.0? My guess is not very likely, as he has to make a decision between the 2 specs, and for now it seems EJB 3.0 is his favorite. IMHO without incorporating Hibernate, JDO 2.0 work is a losing battle. An ODBMS centric spec will generate any interest. ORM is what people really need.
  75. EJB 3.0 at TSS Symposium, Las Vegas[ Go to top ]

    An ODBMS centric spec will [not] generate any interest. ORM is what people really need.
    Thanks for the post Eric, but can you or anyone else tell me where JDO got this reputation for being ODBMS-centric? JDO is datastore agnostic, certainly, but ODBMS-centric immplies unsuited to ORM.
  76. EJB 3.0 at TSS Symposium, Las Vegas[ Go to top ]

    Suffices it to say that JDO 1.0.x did not adequately address the need of ORM. My understanding is that JDO 2.0 will mitigate this, which is a very good thing. I think Robin's idea is the best way for the Java community - let EJB address remoting/distributed component issues, while JDO focuses on persistence. However, the world is not that simple. For political reasons the heavy weights decided to favor persistence in the EJB spec to preserve their investments, and that's quite understandable. My personal opinion is that JBoss is THE SINGLE factor that tips the delicate balance! Both EJB 3.0 and JDO 2.0 sorely needed Hibernate; however as JBoss now owns Hibernate and Marc Fleury likes EJB, I guess there is not much a choice for Gavin King to make with respect to EJB vs. JDO. Frankly I am worried a lot for JDO 2.0 now we know what EJB 3.0 is up to. Well, maybe the only chance for JDO 2.0 to make it big is the fact that EJB 3.0 still insists on EJB 1.x/2.x support, and developers will choose light-weight containers with JDO-type persistence rather than EJB.
  77. EJB 3.0 at TSS Symposium, Las Vegas[ Go to top ]

    Hi Eric
    Well, maybe the only chance for JDO 2.0 to make it big is the fact that EJB 3.0 still insists on EJB 1.x/2.x support, and developers will choose light-weight containers with JDO-type persistence rather than EJB.
    The JDO 2.0 spec will be out long before EJB 3.0 is out. JDO 2.0 is an incremental improvement over JDO 1.0. JDO 1.0 vendors do not have to reimplement their tried and tested products to support JDO 2.0.

    So robust JDO 2.0 implementations will be available long before the first buggy implementations of EJB 3 appear.

    Cheers
    David
  78. EJB 3.0 at TSS Symposium, Las Vegas[ Go to top ]

    The JDO 2.0 spec will be out long before EJB 3.0 is out.
    That's fine. JDO 1.0 also came a few months earlier than EJB 2.0, if my memory serves me right and it did not do JDO 1.0 any good, did it? I agree EJB 3.0 is still vaporware and is a much bigger undertaking than JDO 2.0. However, with JBoss/Marc Fleury/Gavin King seemingly driving the EJB 3.0 spec, we make see a faster pace of progress than earlier EJB JSR's.

    Also as long as we have this EJB/JDO split/uncertainty in JCP, developers like myself will continue to use Hibernate and shun EJB and JDO until Hibernate-style ORM ends up in one of the specs.
  79. EJB 3.0 at TSS Symposium, Las Vegas[ Go to top ]

    Also as long as we have this EJB/JDO split/uncertainty in JCP, developers like myself will continue to use Hibernate and shun EJB and JDO until Hibernate-style ORM ends up in one of the specs.
    Can you define this "Hibernate-style ORM" for which you yearn?
  80. EJB 3.0 at TSS Symposium, Las Vegas[ Go to top ]

    Can you define this "Hibernate-style ORM" for which you yearn?
    I saw you and others already have a lively discussion with Christian Bauer of the Hibernate team going in another thread. Don't want to repeat what have been said. Flame bites aside, I agree with his viewpoint that the most significant data store today is RDBMS, and any object persistence solution needs to address all key ORM issues, like what Hibernate does today. Any extra stuff JDO 2.0 adds then is icing on the cake.
  81. EJB 3.0 at TSS Symposium, Las Vegas[ Go to top ]

    Hi Eric
    .. any object persistence solution needs to address all key ORM issues, like what Hibernate does today. Any extra stuff JDO 2.0 adds then is icing on the cake.
    Today JDO implementations address all key ORM issues not covered by the JDO 1.0 spec with vendor extensions. JDO 2 will bring all of these things into the standard.

    Cheers
    David
  82. EJB 3.0 at TSS Symposium, Las Vegas[ Go to top ]

    Today JDO implementations address all key ORM issues not covered by the JDO 1.0 spec with vendor extensions.
    Well, that's my problem, and I need to go with a 800 lb gorilla type of a vendor if I decide to use proprietary extensions. I know JDO 2.0 is going to include all the missing stuff, but now it has a competitor in EJB 3.0 ...
  83. EJB 3.0 at TSS Symposium, Las Vegas[ Go to top ]

    JDO 1.0-based applications are in production inside J2EE containers. JDO 2.0 is an incremental change, so take up will be rapid, certainly by existing JDO users. By the time EJB 3.0's new persistence capabilities are available, JDO applications will have been running in-container for two years or more. I think JDO will compete pretty favourably.
  84. EJB 3.0 at TSS Symposium, Las Vegas[ Go to top ]

    I also read all the blogs on TSS EJB 3.0 talk. Frankly, I sense EJB 3.0 may now have stolen some thunder back from JDO 2.0 whuch has built up in the last several days.
    It is EJB in name only, excepting for the legacy EJB 1.0 and 2.0 parts that no-one starting new applications will use. It does not represent a triumph of what Entity EJB was, it represents a collapse of what Entity EJB was.
    IMHO without incorporating Hibernate, JDO 2.0 work is a losing battle.
    What are suggesting that there is to incorporate? It was Entity EJB that did not support transparent persistence and hence needed to "incorporate" it. "Incorporate" for EJB 3.0 means replacing EJB 2.0 without deprecating EJB 2.0 .

    And really, where did you get this stuff about JDO being an ODBMS oriented thing?
  85. But when you really need distributed objects

    You do not need distributed objects in the form of distributed entities. This is at least 1000 times shown to be bad design as remote method call is at least 1000 times slower then local in-process call.

    When designing distributed systems you need distributed components or services (call it as you want) that are more coarse grained then entities.

    You design interfaces of these components/services not to be object-oriented but service-oriented (because of performance). Internaly, these components/services should be object-oriented and could even have dual interface (SO and OO) for using them localy.

    Mileta
  86. Totally agree with Rod on this one. A lot of people need J2SE persistence mechanisms and people want alternatives to proprietary ORM mapping tools like toplink or cocobase. JDO provides just that. Besides that many J2EE developers dont want to fiddle around with Entity Beans and we all like alternatives. Thats the way the java community works, having alternatives. The market will decide what technology will win.

    A really poor decission that the application server vendors voted with "no". But we can all do our work and say to the said companies and their representatives that we dont appreciate that.
  87. Of cource the dinosaurs don't want this? It would make their bulky, hard to use, unflexible object modeling systems irrelevant. What I don't like is the fact that not only do they not support jdo2 but they want to impede it.

    Be happy, use Hibernate.

     -Peace
  88. I'm just curious: What other standardized Java object/relational persistence specifications are available for J2SE? I don't see how JDO overlaps anything in that arena.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  89. And what is TopLink ?[ Go to top ]

    "Having 2 specifications address the same problem space with different APIs, persistence and transaction semantics, mapping definitions and query mechanisms does not contribute to the effort of simplifying J2EE and making it easier to use." ... "another independent standard for persistence is unnecessary and will add confusion to those looking to adopt J2EE technology." (Oracle)

    If they only want *one* technology for persistance, why did Oracle buy Toplink for ? Toplink is "another independent standard for persistence".

    Hibernate, not a standard, just the only good choice ;).

      Adrien
  90. Ditto About IBM[ Go to top ]

    "This JSR proposes to develop extensions to JDO that apparently overlap with existing Java technologies and with other JSRs that are already in-progress. In a context where the Java community is working to simplify J2EE, it is undesirable to produce multiple overlapping ways of programming the same function."

    What about SDO and SWT?

    -- John
  91. Ditto About IBM[ Go to top ]

    What about SDO and SWT?
    Exactly! IBM and BEA came up with already redundant quick spec Service Data Objects that has disconnected data sets

    Shouldn't they first check existing JSRs to see if there is already something available (JDO2)?

    Looks really clumsy how these folks (IBM & BEA) are trying to "camouflage" their “control technology” agenda.
  92. Ditto About IBM[ Go to top ]

    Shouldn't they first check existing JSRs to see if there is already something available (JDO2)?
    For the record, although work on JDO 2.0 began with our much publicised meeting in DC in August 2003, the review ballot to approve JSR-243 for further development only completed on 03 May 2004. It is the comments accompanying that vote which gave rise to this thread.

    JSR-220 (EJB 3.0) was approved for further development on 09 June 2003.

    At DC we drafted our JSR proposal, but huge delays inside Sun prevented the JSR from being submitted until very recently. Although I have no specific information, one can speculate as to the extent to which politics amongst the major J2EE players played its part in this delay. We took advantage of the delay by being more public about our proposals and progress than is possible now that the JSR has been approved.
  93. Ditto About IBM[ Go to top ]

    At DC we drafted our JSR proposal, but huge delays inside Sun prevented the JSR from being submitted until very recently. Although I have no specific information, one can speculate as to the extent to which politics amongst the major J2EE players played its part in this delay. We took advantage of the delay by being more public about our proposals and progress than is possible now that the JSR has been approved.
    I think this will be the key to the success of failure of JDO - its visibility and transparency amongst the community at large. In essence, it will probably need to follow the lead of Hibernate on this score.
  94. Ditto About IBM[ Go to top ]

    I think this will be the key to the success of failure of JDO - its visibility and transparency amongst the community at large. In essence, it will probably need to follow the lead of Hibernate on this score.
    And Hibernate sets a good example for JDO to follow: widespread adoption and brand recognition necessarily precede ubiquity.
  95. SDO, not redundant[ Go to top ]

    It might help if you read the SDO docs before writing they are redundant...

    Disconnected data sets are useful in various contexts, not only in the JDO context. Bea and IBM engineers were smart enough to realize this and came up with a simple yet powerful abstraction. And I see no special reason JDO disconnected datasets could not conform to this SDO spec.

    SDO (and a client side version of it: JavaScript SDO, for client side data models) is already being used in IBM products right now. Of course both companies are trying to control technology, but I would rather have them doing it this way (coming up with something that actually _works_) than through the normal (read: much too slow) proces.

    Cheers, Luc.
  96. SDO, not redundant[ Go to top ]

    Right, SDO goes beyond OR/Mapping. SDO may very well be the mechanism to hide all these persistent layers from the presentation. SDO is more an implementation of the Active Record Pattern while JDO, Entity Beans, Hibernate follow more of a Domain Model. SDO can be used as Value Objects to an from these layers, they can be used as a data delegate, and they can be used to front legacy data, XML, etc...

    SDO may have some function overlap but its goal are totally different.
  97. This is not a huge surprise. Maybe the EJB vendors are freaked by the success of lightweight persistence mechanisms. Anyways, it doesn't change the facts - EJBs are now widely regarded as old hat, and almost everywhere I go, I find people who have tried EJB implementations and discarded them in favour of lightweight alternatives, as well as architects who won't even consider EJBs for new implementations. I think this is a hiccup, and not a fatal setback.
  98. Definitely not a surprise but ridiculous IBM, BEA, Oracle's customers refused EJB 1.0, are refusing EJB 2.0.
    As we say in France "never 2 without 3" so EJB 3.0 will come and will continue to disapoint people.
  99. There seem to have been a few posts assuming that this stops JDO 2 from proceeding. It should be pointed out that the result of the ballot was "yes" overall: 12 votes for, 3 against, with only Borland not having voted. So JDO 2 will continue to move forward in spite of the objections from companies with, as has been pointed out, vested interests elsewhere.
  100. Pulp fiction....[ Go to top ]

    ...result of vote for NSR-672 (#ibernate - Ligth persistance for C# objects).
    Yes = 13 : No = 4. Among 4 No votes 3 were representatives of
    NET.DO vendors and Rolf Tolerud. Rolf commented his vote as revenge
    for killing his baby - NSR-531 (C#pring).
  101. Yes, let's not forget that the ballot did approve JSR-243 for further development. The public discussions which the expert group members have been having must now go behind closed doors until the draft specification is ready for publication.

    There are only a few JDO experts actually resident in France, but if you go to Cannes at the time of the JAOO conference you might bump into quite a few of us as we work towards a pre-JavOne publication milestone.
  102. As many others have pointed out apparently IBM, BEA, and Oracle have forgotten about the non-J2EE world. Of course there is going to be some overlap, but what is wrong with that? As much as I would have liked to use J2EE for our environment it just wasn't the right fit. Having a good persistence mechanism is very important to our project and so far we have been pleased at the ease of programming with JDO. We tried Toplink but it had too many bugs and was too hard to get working correctly so we switched to Solarmetric's Kodo and have had good results. If there were no JDO, we'd probably just go back to straight JDBC.
  103. What do you expect?[ Go to top ]

    This is totally what I would expect from companies that have staked their technical reputations on EJB. EJB has dragged developers through the mud for practically half a decade. Not because EJB sucks, but because big companies have mutilated EJB into a persistence tool which it was never intended to be.

    It doesn't matter to me one iota that app-server vendors don't support JDO. JDO is a developer-friendly tool that you can use without an expensive application server. How could THE BIG GUYS support JDO? Hell, they'd lose half their consulting revenues because JDO just works!

    Anyway, it doesn't matter. Developers have already realized they'd be screwed if they kept using EJB for persistence. That is why open source POJO persistence tools like Hibernate and JDO have become popular.

    -geoff
  104. What do you expect?[ Go to top ]

    Last week I spoke with some very savvy developers from a financial software company. They are making a big Java investment right now, and prototyped their implementation using EJBs. 7 months later they ditched EJBs entirely, and moved to a more lightweight model. Their results, cost, and speed of development speak for themselves. This is a typical and common user story. I'm reluctant to slag off the EJB 3.0 spec until I see it in more detail, however. Someone earlier said
    [Hibernate-backed BMP]is a way to go in 1-3 % cases
    and
    well defined Entity Bean life cycle
    for the rest. I disagree. Looking at the current generation of EJBs, I would say that EJBs as they stand, are suited to about 3% of users needs. The rest can be fulfilled quite nicely by a lightweight framework.
  105. Irony - JDO 1 vs EJB 3[ Go to top ]

    Developers have already realized they'd be screwed if they kept using EJB for persistence. That is why open source POJO persistence tools like Hibernate and JDO have become popular.-geoff
    There is irony in the fact that JDO 1.0.1 actually achieves most of what a developer needs for persistence from witin an EJB container. JDO 1.0.1 has been around for ages. Developers do indeed find it a pleasure to use.

    And yet IBM, BEA and Oracle choose to argue against JSR-243 (JDO 2.0) on the grounds of its overlap with EJB 3.0. Whatever elements are eventually seen to commprise the overlap, it is probably the EJB 3.0 elements that are actually overlapping with JDO 1!

    JDO 2.0 adds some neat stuff, but JDO 1 was never shown to be broken. That's why we were confident to watch JDO adoption and speak to users for some time before starting work on JDO 2.0 back in June 2003.

    Kind regards, Robin.
  106. Irony - JDO 1 vs EJB 3[ Go to top ]

    There is irony in the fact that JDO 1.0.1 actually achieves most of what a developer needs for persistence from witin an EJB container. JDO 1.0.1 has been around for ages. Developers do indeed find it a pleasure to use.And yet IBM, BEA and Oracle choose to argue against JSR-243 (JDO 2.0) on the grounds of its overlap with EJB 3.0. <snip/> JDO 2.0 adds some neat stuff, but JDO 1 was never shown to be broken.
    While JDO 1.0 wasn't explicitly broken, the omission of specifying the O-R Mapping mechanism is a critical shortcoming. Without it, portability across JDO implementations is just a pipe dream. Simply adding O-R mapping to JDO could be asserted as an overlap with Entity Bean CMP. JDO 2.0 needs to happen as the JSR states before it's ready for widespread adoption, otherwise each JDO implementation is, practically speaking, non-standard. And if it's non-standard, why limit yourself to JDO?
  107. Irony - JDO 1 vs EJB 3[ Go to top ]

    Simply adding O-R mapping to JDO could be asserted as an overlap with Entity Bean CMP. JDO 2.0 needs to happen as the JSR states before it's ready for widespread adoption, otherwise each JDO implementation is, practically speaking, non-standard. And if it's non-standard, why limit yourself to JDO?
    I take your point, Rob, and the O/R Mapping aspect of JDO 2.0 is one of its most important features. But what you're talking about is essentially the portavility of JDO metadata being constrained, and then only if you use pretty esoteric mappings.

    Many companies choose Oracle (or another named database) as a strategic deployment platform. They are happy to code an application to that end. JDO 1 standardizes their object persistence through the JDO APIs. To move from one vendor to anohther they would have to have undertaking an exercise to port the JDO metadata, leaving standard application and code and domain object model designs unaltered. This is still an extremely viable strategy.

    Anyway, we have JSR-243 now. Soon we should be able to publish a draft of the spec for public review, and quickly move JDO 2.0 into reality.

    Kind regards, Robin.
  108. is that a double irony?[ Go to top ]

    There is irony in the fact that JDO 1.0.1 actually achieves most of what a developer needs for persistence from witin an EJB container. JDO 1.0.1 has been around for ages. Developers do indeed find it a pleasure to use.And yet IBM, BEA and Oracle choose to argue against JSR-243 (JDO 2.0) on the grounds of its overlap with EJB 3.0. <snip/> JDO 2.0 adds some neat stuff, but JDO 1 was never shown to be broken.
    While JDO 1.0 wasn't explicitly broken, the omission of specifying the O-R Mapping mechanism is a critical shortcoming. Without it, portability across JDO implementations is just a pipe dream. Simply adding O-R mapping to JDO could be asserted as an overlap with Entity Bean CMP. JDO 2.0 needs to happen as the JSR states before it's ready for widespread adoption, otherwise each JDO implementation is, practically speaking, non-standard. And if it's non-standard, why limit yourself to JDO?
    Lack of a standard O/R mapping in JDO 1 cannot possibly be a realistic argument against JDO 1 when the most popular alternative (Hybernate) has a totally non-standard O/R mapping, because in fact, there is no "standard". Lack of standard O/R mapping can't be seen as a shortcoming of any tool today.

    The fact is that with the participation of Hybernate folks, and others, there is going to be a standard O/R mapping format. JDO will be the only technology that lets you truly achieve standards based plug-and-play persistence without the bloat of a EJB container;

    JDO IS the technology that is driving standardization of O/R mapping (via JDO 2.0). Once the JDO 2.0 standard O/R mappings are in place, THEN we can talk about the shortcomings of other technologies that don't implement standard POJO persistence with standard O/R mapping.

    Entity Beans are dead. Actually they are more like Zombies from Night of The Living Dead, being kept alive long after they should be dead and buried.
  109. is that a double irony?[ Go to top ]

    Geoff: "Entity Beans are dead. Actually they are more like Zombies from Night of The Living Dead, being kept alive long after they should be dead and buried."

    OSCAR WILDE: I wish I had said that.
    WHISTLER: Ah, you will, Oscar, you will.

    I hope you don't mind if I borrow your statement? :)

    Regards
    Rolf Tollerud
  110. Hibernate will take over[ Go to top ]

    JDO is already lagging behind Hibernate and with these votes it looks like JDO may die. I've done two projects with JDO and I feel like I'm the only one. All my coworkers and associates have used Hibernate but none of them have used JDO. I must say, on my next project I will choose Hibernate.

    Michael Mattox
  111. Hibernate won't take over[ Go to top ]

    Hi Micahel

    I remember our early discussions about JDO and acknowledge your sentiment.

    However, J2EE needs a good standard for persistence. History will record that Gavin King did not lead a JSR to extract the essence of transparent persistence from Hibernate into an open standard to foster competition and adoption. Instead it was Craig Russell who led JSR-12 to do the same but from an ODMG and Forte Transparent Persistence background. The JCP standard in this area is therefore JDO and not Hibernate.

    There is a healthy community of approx 20 JDO implementations. But if you look through the replies to date on this thread you will see a marked absence of vendor-push from the likes of Solarmetric, LIBeLIS, Versant etc. And even David Tinker's original comment was more about dispelling FUD than promoting JDOGenie. Instead the support *for* JDO in this thread has come largely from the community.
  112. Who said Hibernate won't take over?[ Go to top ]

    The JCP standard in this area is therefore JDO and not Hibernate. Instead the support *for* JDO in this thread has come largely from the community.
    I think it is worthwhile to point out that the decidedly pro-JDO sentiment shown in this thread owes largely to the fact that the JDO expert group seems to be more open-minded than the EJB expert group. I hate to say that prior to JDO accepting Gavin King to the expert group, JDO was in a sorrier state than entity beans today in terms of developer adoption and critical vendor support. Now people rally behind JDO 2.0 because it makes more sense then EJB 3.0 after the stated intention of ORM support in JDO 2.0. Please never loose sight of that.
  113. What Rally?[ Go to top ]

    Now people rally behind JDO 2.0 because it makes more sense then EJB 3.0 after the stated intention of ORM support in JDO 2.0. Please never loose sight of that.
    What rally? JDO 2.0 is taking so long it's losing momentum. Gavin King joining the group was a huge boost but now we see JDO going backwards. Meanwhile Hibernate is going forwards. JDO is losing marketshare as we speak. Are the hibernate users going to switch to a non-free JDO implementation when JDO 2.0 comes out? I think it will be too late.

    Michael Mattox
  114. What rally? JDO 2.0 is taking so long it's losing momentum
    I don't agree with this one, not from what I can see of the process, anyways.
    Hibernate is going forwards. JDO is losing marketshare as we speak. Are the hibernate users going to switch to a non-free JDO implementation when JDO 2.0 comes out? I think it will be too late
    Actually, I think the ideal situation (and one echoed by Gavin King and Bill Burke a while back) is that Hibernate will evolve a JDO 2.0 compliant interface. So you can still use Hibernate. This would be a good thing - Hibernate has a lot going for it.

    I am curious about a few things, that I would like to ask Robin directly:

    How do Dennis Leung and Mike Keith fit into the JDO 2.0 dpec panel now? What does the -1s by their employers signify for their involvement in the process going forward?
  115. Question for Robin[ Go to top ]

    Hi Rory
    How do Dennis Leung and Mike Keith fit into the JDO 2.0 dpec panel now? What does the -1s by their employers signify for their involvement in the process going forward?
    The JCP governs the Java platforms in an open and reasonably democratic manner. It is the prerogative of each executive committee member to vote for or against any JSR. This makes Java so very different from .Net.

    The expert group for JSR-243 (JDO 2.0) has yet to be formed officially, although I'm sure that process is well in hand. Oracle is presently listed as a member and I strongly doubt they would withdraw - there's certainly no need for them to do so. The JDO 2.0 JSR was approved despite their objections and I trust that they will continue to work with us as closely as possible, so that the final specification is one which they will see fit to promote.

    Dennis Leung has been on the JDO 2.0 email alias since late August 2003, with the specific intention of keeping Oracle informed at a senior level about the evolution of JDO away from strict binary compatibility (a spec-mandated implementation strategy) to a position where JDO no longer mandates the implementation strategy, but instead accommodates alternative implementation architectures. This position is now well entrenched in JDO 2.0 and I would be wary of any movement back towards the spec mandating PersistenceCapable as the implementation strategy, even though I believe it remains the "best" approach in the absence of native persistence hooks in the JVM itself. I don't think Dennis will be Oracle's technical representative for JSR-243, but he will certainly have access/input to our discussions through that representative.

    Michael Keith, Oracle's technical representative throughout the public evolution of JDO 2.0 in its pre-JSR phase, is a pleasure to work with. With his great insight and congenial manner he quickly won my respect and that of many if not all of the others in the group. He and I argue for different sides of some discussions, but I trust that the agreements the group has reached to date satisfy Oracle's requirements as well as those of the wider Java community.

    I expect that Oracle will continue to have membership of our JSR and hope that they will continue to engage in our deliberations, and I encourage IBM and BEA to become more involved as well.

    Kind regards, Robin.
  116. Question for Robin[ Go to top ]

    The JDO 2.0 JSR was approved despite their objections
    OK - do you think that there will be a list of specific concerns forthcoming from any of the three vendors (or their representatives) any time soon?
  117. Question for Robin[ Go to top ]

    Do you think that there will be a list of specific concerns forthcoming from any of the three vendors (or their representatives) any time soon?
    No, it would strike me as unlikely.

    What follows in this next paragraph is speculation on my part, and I am alerting you to this for fear that I am accused of spreading FUD in response to the FUD that has historically targeted JDO...

    <FUD?>It is possible that these three "no" votes are a last-ditch attempt by the big players to reassert the "need" for EJB-based persistence in the face of the combined threat from the "transparent persistence" camp (JDO & Hibernate) and the "lightweight container" camp (Spring & Pico & other AOP environments).</FUD?>

    In my view the correct approach from the EJB people would be to embrace these threats. I'd love to hear Rod Johnson's opinion, but if EJB 3.0 made Entity Beans optional might Spring evolve to be EJB spec compliant? The current JSR-220 plans - to simplify EJB with extensive use of JSR-175 metadata - would certainly help EJB to compete in the "lightweight" game. Meanwhile, continued advocation of Entity Bean persistence as the solution for the enterprise flies in the face of the community. Persistence that requires the application to be designed specifically for, and locked into, a particular container type (J2EE) is not helpful in a world which demands more and more flexibility from its IT solutions. The object pooling motivations have been largely swept aside by JDK 1.4.2's improvements in object instantiation, and many of the other pro-Entity Bean arguments have long since been refuted by the community.

    IBM, Oracle and BEA have sent a message to the community, the essence of which is that we should not be using or pursuing JDO. Their statements do not directly mention Hibernate. I think the community should send back a very clear message that transparent persistence which interoperates with but does not require Web/EJB containers is what we want.

    One thing I do know for certain: I cannot win this battle on my own.

    Thanks, Robin.
  118. JSR 220[ Go to top ]

    I don't see anything in JSR 220 that amounts to transparent persistence. Has this talk of transparent persistence for EJB 3 arisen since its JSR was filed?


    <quote>
    One thing I do know for certain: I cannot win this battle on my own.
    </quote>

    This is a fine rallying call. We will be naming you Robin Braveheart Roos.
  119. I don't see anything in JSR 220 that amounts to transparent persistence. Has this talk of transparent persistence for EJB 3 arisen since its JSR was filed
    Need for (or the current lack of) Transparent Persistence in EJB has been repeated several times on this thread. This is kind of wierd. Why does EJB need any more Transparent Persistence? Entity Beans offer just that. Even if it comes with additional functionality of distributed objects- which also can be avoided by using local interfaces.

    Cheers,
    Ramesh
  120. Transparent Persistence[ Go to top ]

    Why does EJB need any more Transparent Persistence? Entity Beans offer just that.
    If you clearly state what you think transparent persistence is we can help you sort out your misunderstanding.
  121. Transparent Persistence[ Go to top ]

    Why does EJB need any more Transparent Persistence? Entity Beans offer just that.
    If you clearly state what you think transparent persistence is we can help you sort out your misunderstanding.
    One definition I have come across often (and intuitive also)- "Transparent persistence is the storage and retrieval of persistent data with little or no work from the developer."
    Dont believe there is any misunderstanding. CMP beans does offer transparent persistence. Much like JDO or Hibernate (even if it may differ in its details):
    - There is a basic java class that offers the object abstraction
    - The persistence is declaratively specified in XMLs
    - APIs are available to create new instances or load existing instances
    - Persistence is transparently managed by the runtime (Persistence
      framework or the Container)

    Talk about simplifying the abstractions and usage, probably makes sense (even if not a whole lot, when talkingabout an EJB application). But surely not correct to state that there is Transparent Persistence in CMP.

    Cheers,
    Ramesh
  122. But surely not correct to state that there is Transparent Persistence in CMP.
    Oops. I meant to say "But surely not correct to state that there is *NO* Transparent Persistence in CMP."
  123. Transparent Persistence[ Go to top ]

    Why does EJB need any more Transparent Persistence? Entity Beans offer just that.
    If you clearly state what you think transparent persistence is we can help you sort out your misunderstanding.
    Dont believe there is any misunderstanding. CMP beans does offer transparent persistence. Much like JDO or Hibernate (even if it may differ in its details)
    So you are actually taking the position that EJB 2.1 CMP Entity Beans are transparently persistent? For openers, can you see that the methods that the container requires at EJB 2.1 for entity beans are entirely contrary to transparent persistence? Can you identify a similar non-transparency in JDO or Hibernate?
  124. Transparent Persistence[ Go to top ]

    So you are actually taking the position that EJB 2.1 CMP Entity Beans are transparently persistent? For openers, can you see that the methods that the container requires at EJB 2.1 for entity beans are entirely contrary to transparent persistence?
    Not at all. Calls to this method are completly transparent and managed by the server. In client programs you don't even have to know that those methods exists and you are not controling when calls will be made.
    Can you identify a similar non-transparency in JDO or Hibernate?
    Nope. First of all there is no such things like "non-transparency" of EJBs.
    Secondly EJB are giving you a chance to do perform special operation when intance of your bean is passivated/removed/activated etc. POJOs are in the most of the cases implementing something which is called Anemic Object Model.
    (http://www.martinfowler.com/bliki/AnemicDomainModel.html) and such things are not needed in such implementation. But if you put more business logic into your POJOs you would often find that callback methods are sometimes badly needed.

    Michal
  125. I don't see anything in JSR 220 that amounts to transparent persistence. Has this talk of transparent persistence for EJB 3 arisen since its JSR was filed
    Need for (or the current lack of) Transparent Persistence in EJB has been repeated several times on this thread. This is kind of wierd. Why does EJB need any more Transparent Persistence? Entity Beans offer just that. Even if it comes with additional functionality of distributed objects- which also can be avoided by using local interfaces. Cheers,Ramesh
    Ramesh, I don't know if you've ever used a framework that offers true transparent persistence, but if you did, you would realise the vast difference between that kind of persistence and the EJB-based approach. Transparent persistence doesn't make sense until you actually make use of it, and then you "get it". Once you reach that point, you never want to go back. I wasn't that excited about JDO 1.0, and Hibernate has been my framework of choice for a long time. However, if you look at the plans for JDO 2.0, the EG has put in place the foundations for an amazing framework. To have Hibernate-style functionality in place as part of the J2SE, and (if Hibernate evolves a JDO 2.0 interface) to be able to continue to use Hibernate under the covers is IMHO, one of the most exciting proposals in a long time. Of course, we will still need to see what JSR 220 will bring, but I for one, can't see where they greatly overlap. JSR 220, despite the proposed addition of metadata-driven persistence, still seems to be "container-oriented". Still, we will see.
  126. Ramesh, I don't know if you've ever used a framework that offers true transparent persistence, but if you did, you would realise the vast difference between that kind of persistence and the EJB-based approach.

    Transparent persistence means in simple words: you create an instance of bean/object, you change its properties and those changes are transparently propagated to the database (or to some other storage). In fact transparent persistence in EJBs( I am not a fan of them) is taken to higher level then it takes places in JDO or/and in frameworks like OJB or Hibernate. And this is paradoxically probably one of the major problems of EJBs.
    As they went so far with "transparency" and are not even supporting dynamic queries as implementation of finders is provided by container. You can very easily as well build fully transparent persistence on top of JDO implementations with AOP. EJBs attempt in fact to the same thing but it only gives you this "transparent" way of dealing with databases. With EJB you cannot easly decent one level down and have a choice if you want "transparency" or not ( please forget about BMP 1.x as they were one big mistake).

    So Ramesh is 100% right.
    To have Hibernate-style functionality in place as part of the J2SE, and (if Hibernate evolves a JDO 2.0 interface) to be able to continue to use Hibernate under the covers is IMHO, one of the most exciting proposals in a long time. Of course, we will still need to see what JSR 220 will bring, but I for one, can't see where they greatly overlap. JSR 220, despite the proposed addition of metadata-driven persistence, still seems to be "container-oriented". Still, we will see.
    Well the overlapping is a plain to see (at least accordingly to Mr. Fleury):

    http://jboss.org/jbossBlog/blog/mfleury/?permalink=Transparent+middleware%2C+EJB3.0%2C+Las+Vegas+TSS.html

    "But until that day, the day where you all walk through walls, let's make sure you don't bang your head on the walls for simple stuff. EJB3.0, of which JBoss is a contributing expert member, greatly simplifies the programming model. To lay rumors, yes both Gavin King and myself are on the committee. We are working on lightweight persistence (POJO persistence) and simplified programming models. EJB3.0 will be big, it will be surrounded by buzz by the javaone timeframe and it will be good."
     


    Michal
  127. Upss! sorry!!
    the first paragraph in my previous post was a citation:Ramesh, I don't know if you've ever used a framework that offers true transparent persistence, but if you did, you would realise the vast difference between that kind of persistence and the EJB-based approach.Michal
  128. ... Mr. Fleury:http://jboss.org/jbossBlog/blog/mfleury/?permalink=Transparent+middleware%2C+EJB3.0%2C+Las+Vegas+TSS.html"... EJB3.0 will be big, it will be surrounded by buzz by the javaone timeframe and it will be good."
    Back in the day Sun filled a void with J2EE and cleverly bought themselves industry buzz by letting it create a lucrative market for expensive application servers and consulting services. However, the times have changed when buzz was enough to hawk J2EE snake oil to crowds of CTOs with tons of dollars to burn. Customers now want value for their money, not just words. Many have realized that they don't need the full J2EE stack for the same web applications that are a dime-a-dozen in the scripting world. Last but not least, .NET is emerging as an alternative for enterprise level software, and J2EE better be more lean, more productive and more cost effective to compete.
  129. Last but not least, .NET is emerging as an alternative for enterprise level software, and J2EE better be more lean, more productive and more cost effective to compete.
    True. If the EJB people are mindful of this, it doesn't show in their actions. Their hope must be that if they can turn Entity EJB into something quite different but still refer to it by the name "EJB" then their face is saved. They have had enough shots at fixing it. The world has been amply forgiving and patient. If they mean to incorporate Hibernate this time, the existing Entity EJB facilities will be relegated by default and should be deprecated at a minimum. These facilities won't be deprecated of course, because that would mean facing the enormity of past errors in designing the Entity part of the EJB standard.
  130. You can very easily as well build fully transparent persistence on top of JDO implementations with AOP.
    If AOP is your solution, why would you use Entity EJBs at all?
  131. You can very easily as well build fully transparent persistence on top of JDO implementations with AOP.
    If AOP is your solution, why would you use Entity EJBs at all?
    I won't. I rather hate them then love them.
    But is does not change the fact that we have transparent persistence in ejbs and some of the concepts applied in ejbs are cool.

    Michal
  132. Michal, the fact that you HAVE to change your class code in order to made it persistent (take a previously existing POJO for example and make it persistent under Entity Bean spec), makes Entity EJB non-transparent. This is the very definition of transparency here: you wouldn't have to add or change any method in your class code in order for it to be made persistent. Callbacks should not be mandatory as Entity EJB states, rather optional, like in real transparent persistence frameworks. So no, Entity EJB is not considered transparent.

    Regards,
    Henrique Steckelberg
  133. Michal, the fact that you HAVE to change your class code in order to made it persistent (take a previously existing POJO for example and make it persistent under Entity Bean spec), makes Entity EJB non-transparent. This is the very definition of transparency here: you wouldn't have to add or change any method in your class code in order for it to be made persistent.
    I think that there are two kinds of transparency and I am refering to different one then you are.

    Things can be transparent from "outside" or transparent from "inside".

    You are probably thinking about implementation which is not itrusive = transparent from inside. EJBs are not supporting this type of transparency.

    But traditionally when you are speaking about transparency you are juging things from the outside (AOP is a young discipline, Object persitance theory is quite old :) ).
    It means that you are asking the question: "Can I trasparently persist given object from my client code".
    Callbacks should not be mandatory
    I agree. But I am not sure if this would make things much simpler in case of EJBs.
    as Entity EJB states, rather optional, like in real transparent persistence frameworks. So no, Entity EJB is not considered transparent.Regards,Henrique Steckelberg
    Not sure if I understand how can you define a callback and still match your definition of transparency. Accoringly to your definition anything which has at least one callback method is "not transparent" anymore. If somebody uses callback methods supported by hibernate does it mean that he is not using transparent persistence anymore (transparent accordingly to your definition)?
    IMO it still does.

    Michal
  134. My definition and I would say "the normal one" of Transparent Persistence
    http://www.service-architecture.com/object-oriented-databases/articles/transparent_persistence.html

    Michal
  135. My definition and I would say "the normal one" of Transparent Persistencehttp://www.service-architecture.com/object-oriented-databases/articles/transparent_persistence.htmlMichal
    The link you provide gives the standard definition of transparent persistence, which you have misunderstood.
  136. So in your POV, if I take Robin Roos' Employee class and add SaveToDB() and LoadFromDB() methods, then it can be considered transparent persistent then? Not many will agree with you.

    Most (if not all) persistence frameworks are almost the same when looking from outside, from the client code, as they all have almost the same contracts, regarding CRUD operations. The difference will be exactly in the way they affect the "inside", how much of your business model code must be changed in order to make it persistent. So the "internal" is the primary focus regarding the definition of transparency here, as the "external" is expected to be affected anyway in order to make it follow a specific framework contract or API.

    Regards,
    Henrique Steckelberg
  137. So in your POV, if I take Robin Roos' Employee class and add SaveToDB() and LoadFromDB() methods, then it can be considered transparent persistent then? [...]
    It's not the question of what I think. It's just the question of definition of transparent persistency. Term "transparent persistency"
    is quite old. Probably even it exits much longer then Java does. It was also used for discribing solution implemented in different programming languages which even do not provide Runtime Type Information (RTTI) and long before AOP come to play.


    Michal
  138. So in your POV, if I take Robin Roos' Employee class and add SaveToDB() and LoadFromDB() methods, then it can be considered transparent persistent then? [...]
    It's not the question of what I think. It's just the question of definition of transparent persistency. Term "transparent persistency"is quite old. Probably even it exits much longer then Java does. It was also used for discribing solution implemented in different programming languages which even do not provide Runtime Type Information (RTTI) and long before AOP come to play.Michal
    Ok, I'll rephrase it: so according to the definition of "transparent persistency", if I take Robin Roos' Employee class and add SaveToDB() and LoadFromDB() methods, then it can be considered transparent persistent then?
  139. The "transparency" of transparent persistence is most usually used to mean transparency to the Java object model. It is also used to encompass other aspects of transparency, such as datastore abstraction, lazy loading, etc.

    Below is a simple Java object model with two classes, Employee and Department. They have little behaviour - just enough to be vaguely useful. I wrote them in a lightweight IDE (notepad) so please forgive any syntactic glitches.

    Could one of the "CMP is transparent persistence" advocates please show us how these classes can be persisted through EJB 2.0 CMP? In time we'll see how that changes with EJB 3.0 CMP, once the draft spec is available.
    package my.personnel;

    public class Employee {
            // fields
        private String name;
        private String address;
        private Date hired;
        private double salary;
            // constructors
        public Employee(String name) {
            this.name = name;
            hired = new Date(); //deprecated!
        }
        private Employee();
            // methods
        public String describe() {
            return name + " since " + hired;
        }
        public increaseSalary(int increment) {
            salary += increment;
        }
    }

    package my.personnel;

    public class Department {
            // fields
        private String name;
        private Employee boss;
        private Collection employees = new ArrayList();
            // constructors
        public Employee(String name) { this.name = name; }
        private Employee();
            // methods
        public String describe() {
            String description = name + " ";
            Iterator iter = employees.iterator();
            while (iter.hasNext()) {
                description += ((Employee) iter.next()).describe() + " ";
            }
            return description;
        }
        public void setBoss(Employee boss) {
    if (boss.name.equals("Bill")
                throw new RuntimeException("Bill cannot be the boss.");
    else
                this.boss = boss;
        }
    }
    I or someone else will happily post the JDO equivalent in due course, after which someone else may well do the equivalent for Hibernate....
  140. Transparent Persistence Showdown[ Go to top ]

    I decided to put up the JDO equivalent. I see that my Department class had "Employee" constructors - sorry about that. Syntax checking in notepad leaves a lot to be desired!

    Here's a persistence descriptor. It presumes that the relational schema was generated by the JDO implementation, in which case the names of tables and columns follow the defaults and do not need to be enumerated in the persistence descriptor. Adding table and column names would be reasonably straight forward, and is portable in JDO 2.0.

    All you have to do is identify the package and the classes within that package which are to be persistence-capable. The field Department.employees is a Collection which is known to contain Employee objects (or subclasses thereof) - until Java 1.5 Generics you have to tell JDO what the element type of the collection is. That's it. By default all the fields of both classes will be stored and retrieved since they are of "known" types, and are not static, final or transient.
    <jdo>
        <package name="my.personnel">
            <class name="Employee"/>
            <class name="Department">
                <field name="employees">
                    <collection element-type="my.personnel.Employee"/>
                </field>
            </class>
        </package>
    </jdo>
    With this persistence descriptor you can enhance the compiled classes (necessary for most implementations, although ODBMS implementations tend to do so on-the-fly). The enhanced classes know how to communicate with their state manager, know when unloaded references are being traversed, and know when they have become dirty (i.e. they track changes to their fields values).

    Now the application can exploit the services of the PersistenceManager and JDOQL. The persistent instances of the two classes behave just as the transient instances do, except that they live until deleted and are not lost when the JVM shuts down. So you can still use the same JUnit tests to prove that Bill can never manage a department....

    Who's next, Hibernate or CMP?
  141. The "transparency" of transparent persistence is most usually used to mean transparency to the Java object model. It is also used to encompass other aspects of transparency, such as datastore abstraction, lazy loading, etc.Below is a simple Java object model with two classes, Employee and Department.
    Could one of the "CMP is transparent persistence" advocates please show us how these classes can be persisted through EJB 2.0 CMP? In time we'll see how that changes with EJB 3.0 CMP, once the draft spec is available.



    EJB
    ----------
    Employee employee = ....

    employee.setName( "Robin" );



    Hibernate (JDO is quite similar)
    ----------
    ( I don't know hibernate very well but hope that I din't make any fundamental mistakes)

    Employee employee = ....

    employee.setName( "Robin" );

    Session session = ....

    session.saveOrUpdate( employee );




    IMO EJB way is even more transparent then hibernate way.

    Michal

    P.S.

    I still hate ejbs :)
  142. This is how you can do the mapping and persistence calls with JDX OR-Mapper. Exception handling code is omitted for brevity.


    JDX OR-Mapping Specification
    ---------------------------------------------------------------
    CLASS my.personnel.Employee TABLE EMP
      PRIMARY_KEY name
      IMPLICT_ATTRIB deptName ATTRIB_TYPE java.lang.String
    ;
    COLLECTION_CLASS CollectionEmployees COLLECTION_TYPE JAVACOLLECTION
                             ELEMENT_CLASS my.personnel.Employee
       PRIMARY_KEY deptName
    ;
    CLASS my.personnel.Department TABLE DEPT
      PRIMARY_KEY name;
      RELATIONSHIP employees REFERENCES CollectionEmployees BYVALUE WITH name
    ;
    ----------------------------------------------------------------

    JDX code examples
    // Code to initialize JDX handle jdx1
    ...

    // Create business objects
    Department dept = new Department("Engineering");
    ArrayList emps = new ArrayList();
    emps.add(new Employee("Robin");
    emps.add(new Employee("Hood");
    dept.setEmployees(emps);

    // Persist objects
    // JDX will persist Department as well as Employees (persistence by reachability)

    jdx1.insert(dept, JDXS.FLAG_DEEP, null);

    // Query objects
    // JDX will fetch the whole object graph in response to the DEEP flag

    String predicate = "name='Engineering'";
    Vector departments = jdx1.query("my.personnel.Department", predicate,
                                     1, JDXS.FLAG_DEEP, null);
    dept = departments.elementAt(0);



    Comments: Simple declarative mapping. No complex XML to deal with. No need for pre-processing or post-processing of the code. One can do shallow queries followed by lazy fetches. Query predicates can be created dynamically. JDX operations can be done in the context of a global transaction. More details...

    -- Damodar Periwal

    Software Tree, Inc.
    Simplify Data Integration
    http://www.softwaretree.com
  143. In fact transparent persistence in EJBs( I am not a fan of them) is taken to higher level then it takes places in JDO or/and in frameworks like OJB or Hibernate. And this is paradoxically probably one of the major problems of EJBs.
    Tools like Hibernate are more about data access than persistence and it is a more pragmatic way, "Transparent Persistence" is a very nice dream, but database is more than persistent storage and RDBMS is more usefull thing than "transparent object". Looks like JDO 2 is more about realistic things and I hope it will be as usefull as JDBC is at this time.
  144. Hibernate won't take over[ Go to top ]

    Hi MicahelI remember our early discussions about JDO and acknowledge your sentiment.However, J2EE needs a good standard for persistence. History will record that Gavin King did not lead a JSR to extract the essence of transparent persistence from Hibernate into an open standard to foster competition and adoption. Instead it was Craig Russell who led JSR-12 to do the same but from an ODMG and Forte Transparent Persistence background. The JCP standard in this area is therefore JDO and not Hibernate.There is a healthy community of approx 20 JDO implementations. But if you look through the replies to date on this thread you will see a marked absence of vendor-push from the likes of Solarmetric, LIBeLIS, Versant etc. And even David Tinker's original comment was more about dispelling FUD than promoting JDOGenie. Instead the support *for* JDO in this thread has come largely from the community.
    Yes Robin we go back a few years now but what I'm saying is that since then JDO has lost momentum big time. First off, to address your first point: There are two types of standards: Open and defacto. The fact that Hibernate didn't come out of a JSR doesn't bother me the least bit. I think the JDO process is too political, with each compan promoting their selfish concerns instead of what's best for the user. This is very bad for JDO! SUN/BEA/IBM are torturing people with EJB & Entity Beans and making a fortune doing it! It's understandable that they're not going to embrace JDO. So a bloated, inefficient, tangled process involving big companies who want to push their $10,000/cpu servers doesn't concern me. What concerns me are:

    - Does it work?
    - Can I get support
    - Is there a future?
    - Is it widely used? (This is to discuss best practices, etc.)
    - Is there a book available? (Great for new members to a project)
    - Is it free? (perhaps the most important)

    Fortunately the answers for these issues are all YES for Hibernate. Most are yes for JDO except:

    - JDO doesn't seem to be as widely used as Hibernate, especially in Europe
    - JDO isn't free (yes there are open source implementations but last I checked they were not feature complete)

    Don't underestimate the free issue. Yes, there are inexpensive implementations like Kodo (about $800/developer last I checked) but just the process of getting a company to buy a product like this can take longer than the project. There's all kinds of beaurocratic hurdles to overcome. When it's free we just use it and there is no discussion.

    Michael
  145. Hibernate won't take over[ Go to top ]

    Most are yes for JDO except:
    - JDO doesn't seem to be as widely used as Hibernate, especially in Europe
    - JDO isn't free (yes there are open source implementations but last I checked they were not feature complete)
    On the second issue, JPOX (http://www.jpox.org) *does* pass the JDO TCK. It implements several of the "optional" parts of the JDO 1.0.1 spec as well.
  146. Hibernate won't take over[ Go to top ]

    Hi Michael
    The fact that Hibernate didn't come out of a JSR doesn't bother me the least bit.
    Me neither. I have clients who will adopt Hibernate and clients who will not adopt Hibernate. Some of those that have discounted Hibernate, after varying degrees of consideration of its technical abilities, did so on the grounds that it is an open source product that does not implement a standard.

    However, since Hibernate is not a JCP standard it will not be adopted as a persistence solution by J2EE itself.

    If JBoss/Hibernate decided to work with the JDO folks to (a) make Hibernate implement JDO, and (b) convince the J2EE/EJB people that JDO was the correct JCP standard for persistence from the single VM to the Web/EJB Container, then we could probably make things happen together. Hibernate's branding is very strong, and its market share could increase further from such a collaboration. And if we managed to get transparent persistence on the agenda for J2EE it would be good for Java and bad for .NET. Putting the weight of all transparent persistence advocates behind the message "JDO for J2EE" would bee awsome!

    Kind regards, Robin.
  147. Hibernate is just Hype-rnate[ Go to top ]

    I have currently moved a project from JDO to Hibernate.
    Not impressed. JDO is far ahead in usability and stability.
    Just because there is a Hibernate hype does not make it good.
    Hans
  148. Since most of the principle-based arguments have already been well made, I hope to make an obvious pragmatic argument for JDO 2.0.

    We have applications that needed to ship "yesterday," so we use a lightweight persistence framework that is available today and has a future. JDO 1.0.1 works. It isn't the most convenient to use for web applications, but it beats anything else out there for our needs. With JDO 2.0, we finally have nearly all the features we need. Our vendor is already implementing some JDO2 features that we desperately need and now use. Can EJB3 meet our needs? To be honest, I don't know. Why? Because I can't download it and use it.

    So why try to kill a specification before the "competing" specification isn't yet finished, nevermind that there aren't any implementations. We need something today and something next week. We don't need something that might arrive on our desktops next year.

    Oracle, IBM, BEA: I'd be glad to listen to your arguments for killing JDO when you have something I can actually compare to JDO 2.0. I may even agree with you and switch to EJB3. But not today and not until you can at least match the JDO 2.0 spec. We have products to ship.
  149. Oracle, IBM, BEA: I'd be glad to listen to your arguments for killing JDO when you have something I can actually compare to JDO 2.0. I may even agree with you and switch to EJB3. But not today and not until you can at least match the JDO 2.0 spec. We have products to ship.
    They might be waiting JDO 2.0 spec be out to do just a copy and paste to EJB 3.0
  150. They might be waiting JDO 2.0 spec be out to do just a copy and paste to EJB 3.0
    Well then, we'll just have to publish the JDO 2.0 spec for them quickly. I'd hate us to be responsible for delaying another JSR. ;-)

    I presume that the TSS Symposium is going well. I'd expected discussion to heat up still further as the USA came on-line, but presumably they're all in Las Vegas!
  151. Nobody is arguing about useless of Entity Beans there, - so not enough fuel for discussion :-)

    What we actually see is some sort of arguing between Hibernate and JDO folks. IMHO the best will be to combine together best features from both - say specifically ether add more transparent persistence, life cycle management and such to Hibernate, or add standard ORM to JDO, - or both.
    One of the problem of JDO - lack of big vendor and (or) big open source community. Hibernate is by far lead between OS ORM, so it consolidate support from people. JDO - is a dozen of small vendors, a lot of vendor-related uncertainty, and spread of support (and inter-JDO competition).
    Once somebody from big guys bye some JDO vendor - we will see different picture.

    Best,
    Igor.
  152. Best DAO is...[ Go to top ]

    iBatis of course, better than Hibrenate.

    Since the specs don't care about what community want's, why should the comunity care about JCP standards?
    Users use popular standards, such as Struts (not a JCP standard), Apache Jakata Commons, etc.

    http://news.netcraft.com/archives/web_server_survey.html = you should only use popular stuff, not vendor propriatory stuff.

    Why EJB suck:
    http://www.softwarereality.com/programming/ejb/index.jsp

    One sample app in Struts/iBatis is www.basicPortal.com, used by several large clients, listed on above web site.


    .V
  153. <vic>
    iBatis of course, better than Hibrenate.
    </vic>

    sorry Vic but did you read the result of the latest case study of .NET vs. J2EE? TSS had 2 types of J2EE applications:
    - J2EE + Servlet/JSP + EJB CMP and
    - J2EE + Servlet/JSP only (it used JPetstore implementation)

    All the results showed that only J2EE + Servlet/JSP + EJB CMP had a chance to fight against the power of .NET. JPetstore was very slow to compare with two other implementations in that test.

    It would be very interesting to see JDO impl. and Hibernate in the same test...

    Cheers,
    Lofi.
  154. <vic>iBatis of course, better than Hibrenate.</vic>sorry Vic but did you read the result of the latest case study of .NET vs. J2EE? TSS had 2 types of J2EE applications:- J2EE + Servlet/JSP + EJB CMP and- J2EE + Servlet/JSP only (it used JPetstore implementation)All the results showed that only J2EE + Servlet/JSP + EJB CMP had a chance to fight against the power of .NET. JPetstore was very slow to compare with two other implementations in that test. It would be very interesting to see JDO impl. and Hibernate in the same test...Cheers,Lofi.
    Test results are very dependant on tester and I am sure this test is lame or political. Probably JPetstore is not the fasted
    application in the world and I do not think somebody have tried to tune it, single thing you need to tune is a RDBMS (add more cache and create indexes). I am afraid it is not so trivial to tune EJB (How do you trace query plan in EBQL ?).
  155. JDO today[ Go to top ]

    A few words about the state of JDO:

    1. look at this very own thread and you know what credibility JDO has
    2. i noticed hibernate in every 3rd post, even hibernate is good, at large companies i see more JDO adoption (and of course EJB).
    3. the post that you dont need DB classes inheritance is quite funny (just because EJB designers cant do it, doesnt mean its useless)
    4. Good to see that also Richard M.H. voted with yes, i assume he is more involved with EJB than most of us, but this didnt prevented him to vote with yes.
  156. <vic>iBatis of course, better than Hibrenate.</vic>sorry Vic but did you read the result of the latest case study of .NET vs. J2EE? TSS had 2 types of J2EE applications:- J2EE + Servlet/JSP + EJB CMP and- J2EE + Servlet/JSP only (it used JPetstore implementation)All the results showed that only J2EE + Servlet/JSP + EJB CMP had a chance to fight against the power of .NET. JPetstore was very slow to compare with two other implementations in that test. It would be very interesting to see JDO impl. and Hibernate in the same test...Cheers,Lofi.
    Test results are very dependant on tester and I am sure this test is lame or political. Probably JPetstore is not the fastedapplication in the world and I do not think somebody have tried to tune it, single thing you need to tune is a RDBMS (add more cache and create indexes). I am afraid it is not so trivial to tune EJB (How do you trace query plan in EBQL ?).
    I don't have the link handy, but Oracle duplicated the test with optimization while staying true to n-tier. It was faster when the data was cached and not cached. Google for the article and you'll see the .NET Petstore threw design principles out the door to show it was faster. Oracle's test shows you can get great performance while using good design practices.
  157. Yes, fake oracle performance tests are nothing new (aggressive marketing).
    MySQL proved itself as the best database this way too, Do you think mySQL is "fater" than oracle ? Try to cache content on web server and iBatis will be the fasted framework (It will have nothing to do), Does it meens IBatis is the best technology in the world ?
    <vic>iBatis of course, better than Hibrenate.</vic>sorry Vic but did you read the result of the latest case study of .NET vs. J2EE? TSS had 2 types of J2EE applications:- J2EE + Servlet/JSP + EJB CMP and- J2EE + Servlet/JSP only (it used JPetstore implementation)All the results showed that only J2EE + Servlet/JSP + EJB CMP had a chance to fight against the power of .NET. JPetstore was very slow to compare with two other implementations in that test. It would be very interesting to see JDO impl. and Hibernate in the same test...Cheers,Lofi.
    Test results are very dependant on tester and I am sure this test is lame or political. Probably JPetstore is not the fastedapplication in the world and I do not think somebody have tried to tune it, single thing you need to tune is a RDBMS (add more cache and create indexes). I am afraid it is not so trivial to tune EJB (How do you trace query plan in EBQL ?).
    I don't have the link handy, but Oracle duplicated the test with optimization while staying true to n-tier. It was faster when the data was cached and not cached. Google for the article and you'll see the .NET Petstore threw design principles out the door to show it was faster. Oracle's test shows you can get great performance while using good design practices.
  158. "Nobody is arguing about useless of Entity Beans there, - so not enough fuel for discussion :-)"

    Exactly, really the only problem with Entity Beans was the assumption that J2EE developers could design good enough architecture. Entity Beans and J2EE technology is way beyond the means of the masses as this board proves without a doubt.

    Its the useless ability of "Entity is bad" incompetent J2EE developers which engages in empty tank discussions.

    Its really frustrating to see so many people telling everybody about their inadequacies by blaming technology they don't understand.

    If Entity Beans are not appropriate for your project, then it doesn't mean its not appropriate for others.

    The JSP hacks are just out of control...
  159. If Entity Beans are not appropriate for your project, then it doesn't mean its not appropriate for others.
    The JSP hacks are just out of control...
    If you have a few minutes, do you mind enlightening us on the circumstances under which enity beans are appropriate? I am very curious.
  160. Oracle, IBM, BEA: I'd be glad to listen to your arguments for killing JDO when you have something I can actually compare to JDO 2.0. I may even agree with you and switch to EJB3. But not today and not until you can at least match the JDO 2.0 spec. We have products to ship.
    They might be waiting JDO 2.0 spec be out to do just a copy and paste to EJB 3.0
    Yes. That would prove them right regarding the big overlap between JDO and EJB :-)
  161. OK, I ran out of space in the title to finish all the organizations (not even counting individual experts) who voted YES on JD0 2.0. Apple Also voted YES. SO while a few giants voted NO, several giants voted YES along with EVERYONE else!
    ==============================================================================

    On 2004-04-30 Sun Microsystems, Inc. voted Yes with the following comment:
    This is in response to some of the comments on JSR 243 "JDO 2.0".

    If JDO did not exist, it might be a worthy topic for debate as to
    whether the Java community should invest in this area. I can see
    pros and cons on both sides. But JDO does exist, and it has a loyal
    user community who want to see it continued and extended. Sun, as
    specification lead for JDO, is responding to what we perceive as
    legitimate community demand for evolving JDO.

    Sun believes that there is space for both JDO and EJB. I hope the
    expert groups can cooperate to minimize any unnecessary differences
    in areas where they overlap. Whether or not JDO should be included in
    J2EE is an issue for a future J2EE expert group to debate.

    Given that JDO exists and has attracted significant interest from
    the Java community, I think it is appropriate to allow it to continue
    to evolve, based on the feedback and requirements from its users.

                                                         - Graham

    ------------------------------------------------------------------------------
    On 2004-04-20 Lea, Doug voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2004-04-20 SAP AG voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2004-04-20 Monson-Haefel, Richard voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2004-04-22 IONA Technologies PLC voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2004-04-26 Nokia Networks voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2004-04-26 BEA Systems voted No with the following comment:
    JDO is one of many different persistence solutions in server-side Java today. With J2EE 1.5 emphasis on simplification and ease of use, we don't see how having another release of JDO, whose market acceptance is essentially constrained to use with object databases, can be explained in conjunction to similar enhancements being made in the EJB3 expert group. We are also concerned about taking JDO into new areas such as disconnected data set support until we better understand how ball of these solutions fit together. Unless the submitters can explain how all of this fits together, we believe the Java community would be better served with fewer apparently competing alternatives.
    ------------------------------------------------------------------------------
    On 2004-04-26 Apache Software Foundation voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2004-04-30 Fujitsu Limited voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2004-04-30 IBM voted No with the following comment:
    This JSR proposes to develop extensions to JDO that apparently overlap with existing Java technologies and with other JSRs that are already in-progress. In a context where the Java community is working to simplify J2EE, it is undesirable to produce multiple overlapping ways of programming the same function.
    ------------------------------------------------------------------------------
    On 2004-04-30 Macromedia, Inc. voted Yes with the following comment:
    While undesirable overlap does appear to exist between JDO and other JSRs, the feedback we have long heard on this particular subject is that Java application developers prefer to adjudicate the overlap themselves rather than have the decision enforced for them by platform vendors. The community appears to desire a choice between persistence technologies even at the expense of the additional platform complexity and fragmentation that the overlaps between those technologies can cause. We consider our vote in favor of this JSR to reflect not an architectural platform aesthetic, but instead to reflect the more practical majority sentiment long and loudly expressed by customers and others in the community.
    ------------------------------------------------------------------------------
    On 2004-05-02 Caldera Systems voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2004-05-03 Hewlett-Packard voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2004-05-03 Apple Computer, Inc. voted Yes with no comment.
    ------------------------------------------------------------------------------
    On 2004-05-03 Oracle voted No with the following comment:
    JDO 2.0 overlaps with the work being done by the EJB 3.0 expert group to provide a lightweight persistence model. Having 2 specifications address the same problem space with different APIs, persistence and transaction semantics, mapping definitions and query mechanisms does not contribute to the effort of simplifying J2EE and making it easier to use. The direction of lightweight persistence being taken by the EJB 3.0 group will have tremendous appeal to mainstream enterprise Java developers, even those who are critical of the current Entity Bean model. Given the evolution of EJB 3.0 persistence, another independent standard for persistence is unnecessary and will add confusion to those looking to adopt J2EE technology.

    ------------------------------------------------------------------------------
  162. jdo spec[ Go to top ]

    it's nice to see all of this YES votes, i hope that the java community will benifit from both JDO and other persistance models without "big overlaps"
  163. Go JDO![ Go to top ]

    I'm happily using JDO *today* in both J2EE and non-J2EE contexts, and I want the standard to advance.
  164. And the winner is...[ Go to top ]

    Guess who's is clapping to this right now ?

    Yes, you found it, Microsoft and its .NET staff !!!
    I believe any technical orientation taken by the JCP, which has been guided by marketshare/competitor actual positions rather than by overall improvement and enterprise Java marketshare progress is a bad thing for the Java folks.
    In the end, these kind of arguments between the JCP members will only slow down innovation and weaken enterprise Java against Microsoft.

    Keep in mind that "David" has to be way better than "Goliath" (e.g. ease of development, deployment, overall cost ownership etc..) in order to win the fight.

    The most suprising is the "No" from BEA, which does not have any RDBMS on its own. I would have expect a different position from them..


    Happy coding anyway

    Gregory
  165. Let's not mess up this one![ Go to top ]

    Hi all,

    We've used EJBs (even BMPs few years ago :-) for some time in different big projects (using WebLogic, WebSphere and Oracle9iAS). I'm glad that the spec and the implementations are getting better. However it's still too complex/heavy weight/not intuitive/etc. Furthermore, we have many more small "Web Application" projects deployed mostly on Tomcat not using EJBs at all. From now on, starting with the small projects, we're thinking about using Hibernate. (We're researching about Spring framework as well because we're fed up with working with heavy-weight containers in our development environments. We don't have to have coffee breaks because we're deploying!).

    Obviously we're not the only ones in this situation. And I find it more than arrogant that BEA, IBM and Oracle don't want to support JDO. The users/developers have kept crucifying Entity EJBs and heavy-weight containers but they don't want to get it, do they? We had enough! We want to use something that we can develop with simple tools, that we can unit test easily and where we can deploy fast. JDO 2.0 is a part of the solution to a bigger problem and I'm looking forward to it!

    We, the users/developers, drive the industry! Listen to us! Or you're doomed!

     - Yagiz -

    PS: Oracle makes me laugh! I thought they were promising JDO support for TopLink!
    PPS: IBM makes me laugh! As if they cared about overlapping: Have you heard about SWT?
    PPPS: I'm disappointed with BEA because WebLogic is the only product that stands as the only source of hope in me concerning the J2EE Application Servers.
  166. Consider vendors' motivations[ Go to top ]

    Consider this:
    * IBM & BEA each sell an EJB container.
    * IBM & BEA have invested significantly in entity bean support.
    * IBM & Oracle each sell a relational database.
    * Oracle sells an object persistence tool.

    Given that JDO
    * not only integrates with an EJB container but also can be used outside of one,
    * supports different database vendors, and
    * supports multiple implementations over the same or a different data store,
    it becomes quite clear that the vendors, in their no votes, are simply trying to protect their investements. They are beset on many fronts by the threat of commoditization and innovation.

    IBM's & BEA's investments in entity bean support are directly threatened by JDO, and their containers are threatened by the undercurrent of lightweight, containerless frameworks like Pico & Spring, with which JDO can be used. IBM's and Oracle's databases are threatened by JDO's encapsulation of the underlying database. Oracle's TOPLink is threatened because it would lose its customer lock-in and possibly be replaced by another persistence implementation.

    I'm surprised by BEA's comment about object databases. I think anyone who's done any research on JDO knows that there are far more O-R mapping implementations used than any other kind, and there are more O-R mapping implementations than there are object database implementations.

    What I does not surprise me is that the vendors are attempting to protect themselves, something for which I don't blame them. However, they exist only thanks to their customers, and their customers have a long and well-documented history of disliking the entity bean solution. They need to listen to their customers and recognize that there are better solutions out there. By the same token, their customers need to speak up and demand a better solution, JDO or not.

    With JDO 2.0, every concern that I've heard about the specification has been addressed (object graph detachment & reattachment, optional bytecode enhancement, enhanced query capabilities, access to underlying database connection, etc), and products like TOPLink and Hibernate can be compliant much more easily than they could have with JDO 1.x. It's time for the vendors and the EJB specification committee to step up, admit that they fused the object and component models, acknowledge the widespread criticism and lack of use of entity beans, recognize a simpler solution, and embrace it by deprecating entity beans in EJB 3.0 in favor of JDO 2.0.

    I would also like to see Hibernate and TOPLink implement JDO 2.0, unless their fear of commoditization outweighs their perceived ability to capture market share. That's a call that they're going to have to make.

    Additionlly, let's not forget that Microsoft is watching. They have a similar technology called ObjectSpaces, based on ADO.NET 2.0, that is currently under development. Their first technology previews in 2001 looked an awful lot like entity beans, and their more recent previews look a lot more like JDO.

    --matthew
  167. why 4 ejb vendors?[ Go to top ]

    Why are 4 EJB vendors (Sun, IBM, Oracle, BEA) the majority in a committee deciding a competing technology?

    Hardly seems like a fair process for innovation.
  168. why 4 ejb vendors?[ Go to top ]

    I don't think the four you mention form a majority. The executive committee is comprised of 16 well respected organizations and individuals, and I belive the votes held by each to be of equal weighting.
  169. why 4 ejb vendors?[ Go to top ]

    I've just written a brief comparison between SDO and JDO 2.0 Detachment which I hope to publish tomorrow. I'll be sure to link to it from this thread for those who are interested.

    Whilst I was writing it I suddenly understood Amin's question! There are 16 organizations and individuals in the executive committee, but Dion only listed at the top of this thread the five who submitted a comment along with their vote. JSR-243 (JDO 2.0) was approved for further development by a majority of 12-to-3 with 1 abstension, but only 5 companies posted specific comments.
  170. Title: Comparing SDO to Detachment in JDO 2.0

    I'm sorry this took a while, but I needed to do some background research before being confident to write the commentary. I've now looked into SDO (JSR-235) and below I present my comparison of its proposed capabilities with those of JDO 2.0 detachment, part of JSR-243.

    In the end the text was just too long to post as a reply on this thread, so I've had it published at http://www.jdocentral.com/JDO_Commentary_RobinRoos_6.html . Please click on the link to read it - doing so should only take a few minutes of your time. To whet your appetite here's a quote from my concluding remarks:
    The reason there is a choice lies in the fact that JDO detachment exposes the actual domain model to the client, this being both its advantage and its disadvantage.
    I don't particularly wish to turn this thread into a discussion of SDO. Hopefully, however, the commentary is useful to those who might be confused regarding SDO's positioning w.r.t. JDO 2.0.

    Thanks for your time, Robin.
  171. Sun: We have no choice to support JDO effort because EJB really sucks big time in performance, and we know it.

    Macromedia: We like options. The more standard options the developers have the more likely they will consider to use less dominant servers like "JRun".

    BEA: Our livelihood is depends on our popular EJB Container. JDO will only take our customers away.

    IBM: We can hardly (actually have not) keep up with the latest J2EE spec. Maybe later.

    Oracle: JDO promote Object Databases. What are you crazy? We don't do Object Database.


    Seong-yong
  172. Hi Seong-yong,

    Regarding your point:
    Oracle: JDO promote Object Databases. What are you crazy? We don't do Object Database.

    I don't think that this discussion relates to ODBMS versus RDBMS, each is appropriate for a given contexte. The IT world has been hearing for decades: "ODBMS is the end of RDBMS"

    I'm still waiting for it to happen ... there are many many many cases where nothing beats an RDBMS

    a++ Cedric
  173. I don't know what is JDO.....[ Go to top ]

    But I think more choices is much better to users