Design Considerations When Using Entity Beans with CMP

Discussions

News: Design Considerations When Using Entity Beans with CMP

  1. Almost every real world application has some state that it needs to persist to a persistent store, typically a database, to be accessed later by the application. There are many aspects of persistence that application architects need to be aware of before designing their persistence application and choosing a persistence provider.

    Sastry Malladi discusses these issues and other advanced persistence management issues that every architect needs to know when evaluating persistence architectures. Read his paper "Design Considerations When Using Entity Beans with CMP " to find out more. Sastry also outlines some guidelines on to how to choose what's best for the application in this paper.

    Tune in to Week 10 of Middleware Architecture Series: Container Managed Persistence

    Threaded Messages (40)

  2. It's a good paper about the details of CMP, especially for the insight it gives into Oracle's plans for their app server, which sound very good.

    However, it reiterates many common assumptions about the benefits of entity beans and CMP without providing any proof.

    "It is best if the container or the application server vendor provides solutions to these [complex persistence] issues, so that the application writers can focus on the business logic." (p2) This sounds reasonable, but it's difficult--if not impossible--to produce a good one size fits all solution that's portable across databases, so the reality is somewhat different.

    "JDBC is good for small applications [with] simple data"--by implication, CMP is a better choice for complex data models (p2). In my experience, the reverse is true in many cases. Entity bean CMP doesn't handle complex relational data models very well. As soon as aggregate functions, batch updates etc. are required the limitations of EJB 2.0 CMP become painfully apparent. JDBC allows us to use the full capabilities of an RDBMS--assuming we're using one, which we normally are. I think the real indication for entity beans is not a complex data model, but the likelihood of the app server being able to cache entities effectively, which can be determined by looking at projected usage patterns.

    "Applications written using JDBC are not portable [between databases]" (p3) Does this really matter in that many applications? People choose an Oracle technology stack because they want the Oracle database, not because they might want to use Oracle's app server with Versant (even though Oracle's app server is now a good product).

    "Using CMP avoids the complexities of state management and O/R mapping" (p3). Isn't CMP a (primitive) form of O/R mapping? Aren't deployment descriptors complex? CMP moves complexity from Java code to XML deployment descriptors.

    I discuss these issues in chapters 7 and 8 of Expert One-on-One J2EE Design and Development.

    Rod Johnson
  3. Rod's comment is head-on. CMP is *nothing* but yet another form of O/R-mapping, and actually a pretty limited one IMHO. And from my experience, persisting even simple objects with a decent O/R-mapper like Hibernate is straightforward and can be learned in a day. I did NOT learn CMP in a day :)!

    If you need to persist more complex object graphs, it seems to me that O/R-mappers win even more conclusively over CMP than for simple objects.

    Just compare the mapping XML files from Hibernate with any deployment descriptor and tell which file is simpler to use... and then look at the code of the persisted object: In the reflection-based O/R-world, getters and setters. In the EJB-World, ejb*(). Which is more complex?

    To give you a real-world example: We currently have to meet a tough deadline (Jan 31st) for a J2EE-based portal. Did we use CMP for persistence? Nope (even though I'm a Sun-certified trainer for J2EE including EJB). The EJB-pain was just not worth it. Rather, we took the risk to use hibernate and rapid-prototype the hell out of it. It worked *well*.

    Cheers,
        Henrik
        TNGtech

    Rod writes:
    >"Using CMP avoids the complexities of state management
    > and O/R mapping" (p3). Isn't CMP a (primitive) form of
    > O/R mapping? Aren't deployment descriptors complex? CMP
    > moves complexity from Java code to XML deployment
  4. Mistakes and broken promises[ Go to top ]

    I remember the early days of EJB, somewhere around mid-'98. There were two very interesting ideas about entity beans. As far as I known about, these ideas have never been put in practice:

    1) The container was supposed to use the native database protocol instead of JDBC. The idea was to allow developers to achieve top performances without sacrifiying portability. I think that it is widely accepted within the industry that JDBC is *really* slow compared to native database calls.

    2) Entity beans containers had to be pluggable. The idea was to allow developers to acquire the best container implementation for their database and simply plug it into the application server. For example, plug an Oracle container in a BEA application server.

    JDO was also promising. However, SUN made the mistake to try developing a "one size fits all solution" instead of focussing on 95% of the developers's needs, i.e. a good persistence solution for relational databases.

    I also have to notice that JDBC is not that successful either. Current version is 3.x. Where are the databases supporting it, where are the drivers? Even starting from JDBC 2.0, there are really interesting things developers could use instead of EJB or JDO. Indeed, most leading relational databases come with an object layer nowaday, and JDBC can query it...

    My opinion is that the only next smart move of SUN with regard to persistence is to start a JCP on object-relational mapping. Java developers should have one (and only one) way to define object-relational mapping whatever the technology used to implement it, being EJB entity beans or JDO. And as an important goodie, this approach would also make it easier to move entity beans from one application server to the other.

    Bertrand Fontaine
    INSPIRE IT - INSPIRE IT
    JavaShelf.com: Your Java bookstore on the Web!
  5. Mistakes and broken promises[ Go to top ]

    The closest one to get what you describe is the JVM inside the Oracle 8i+ database.

    I tried it out a little bit, but haven't used it much at all since.

    Steve
  6. Mistakes and broken promises[ Go to top ]

    Betrand,

    I agree 100% with everything you said.

    JDO was developed as a standard for "transparent persistance".
    People dont really want transparent persistance - they want O-R mapping.

    In any case, I have the same feelings about "transparent persistance" as I have about "location transparency" - they dont really exist in the real world.

    | SUN made the mistake to try developing a "one size fits all
    | solution"

    While I agree, my feeling is that the spec was kinda "hijacked" by the ODBMS vendors.
    Personality clashes with some of the leading O-R vendors, and their subsequent abstainance from the spec didnt help this balance either.

    -Nick
  7. the JDO position[ Go to top ]

    Nick Bertrand

    A lot of interesting things has been discussed in this thread.
    Let me expose the position of a JDO Vendor:

    * we do already have large accounts (Societe Generale, Sanofi, Line Data Service, France Telecom just to mention few of them in France) using our JDO product in critical applications. Saying the opposite is just relaying FUD against JDO.

    * JDO is definitely not yet another ODBMS standard !!! 10 of the 12 implementations are JDO compliant O-R mapping tools, only the 2 other ones are related to ODBMS vendors.

    * JDO is not a technology for RDBMS vendors because it tend to commoditize the DB as a raw storage facility. Oracle surely prefers to have a proprietary O-R mapping tool using Oracle proprietary features in order to lock their customer base. This is why they bought TopLink and why they don't like standards.
    JDO is rather a market for middleware companies.

    * Having JDO implementations based on low-level RDBMS APIs is a nonsense from the technical point of view, and will never happen, forget it.

    * It is a common feeling that all Company Data are stored within RDBMS. Most JDBC programmers tend to thinks that everything is in Oracle. The reality is that in large accounts a huge amount of data is still stored in MainFrames, AS-400, Unisys, C-ISAM files, Cobol files and so on.
    I'm obviously not saying here that RDBMS is not important but there is a strong need for JDO as a universal standard and not a standard limited to O-R mapping.

    * From what I can see every day on the field, people don't want to deal themselves with O-R mapping complexity, they just want that transparent persistence covers O-R mapping and they want to be able to externalize performance rules and heuristics out of the jave source code

    * However, JDO 2.0 will have a sub-project dedicated to O-R mapping standardization within JDO as we recognize there is a need for this.

    * And you'll soon see some important RDBMS vendors (not Oracle) publicly announcing they certify some JDO products with their database and tools.

    * As you mentioned, Craig Russel is now in charge of persistence within SunOne Server 7. That EJB persistence layer has been designed on top of JDO.

    * Some people are saying that JDO sucks because there is no big company supporting it. They are the ones saying in 1997 J2EE has no future, when WebExpress was still a small company with a product named Tengah.

    The very important thing is that JDO is gaining more and more popularity through the Java Community. It clearly addresses an important need, that is not covered by EJB.
    As a basic proof you can observe that many TSS threads related to EJB are now quickly deriving into threads on JDO.

    Best Regards, Eric.
  8. the JDO position[ Go to top ]

    Eric, I hope you succeed, and it's good to hear of large companies adopting JDO. Totally agree that "JDO is definitely not yet another ODBMS standard": my experience with JDO vendors is that they have strong experience of working with RDBMSs.

    A significant JDO success story posted on TSS might do a lot to make people feel more comfortable adopting JDO.

    Rod
  9. JDO Success Stories[ Go to top ]

    A significant JDO success story posted on TSS might do a lot to make people feel more comfortable adopting JDO.



    Rod,

    you're right we're in the process to write and publish such testimonials, it should help JDO adoption.

    best regards, Eric.
  10. JDO - materials[ Go to top ]

    Yes I agree with Rod. Couple of success stories about JDO implementation will have a good impact and better understanding. Do we have any reading material/white papers about JDOs. can anybody let me know.

    Ravi
  11. the JDO position[ Go to top ]

    Marc (or is it Eric ?),

    I'm planning to evaluate JDO pretty soon and I hesitate between implementations. The alternatives are pretty much Kodo, Lido and OpenFusion. You say you represent a vendor and you provide client references. Could you please tell which vendor ? And how JDO was used for instance at the Société Générale and why it was chosen against other persistence strategies ? What I plan to evaluate is mostly performance, scalability and ease of use.

    Many thanks,

                    Yann
  12. the JDO position[ Go to top ]

    Eric,

    I think I have parts of the answers. I downloaded LiDO today and they give the same references (Société Générale, Sanofi, ...) but also BNP Paribas (used in trading) and Raytheon. That's not too bad. I'll see how it integrates with MySQL and Oracle.

    Still, is it possible to know how JDO is being used on those projects (performance-wise: how many TPS, concurrent users, etc.) without breaking any NDA or privacy rule ?

    Cheers,

                    Yann
  13. LiDO references[ Go to top ]

    Yann
    I guess we can continue this discussion over the phone as forums are not rally convenient for this.
    If you downloaded the product today, I'll be able to get your contact information.
    Talk to you soon.
    best Regards,
  14. JDO vendor[ Go to top ]

    Yann

    I represent LIBeLIS and the LiDO product.

    LiDO has been selected at Societe Generale for Trading room applications in their Asset Management division (SGAM).

    They use LiDo in a J2EE App Server, throught Session Beans.
    They mostly need performance and transparent persistence as they have a complex model.

    JDO compliance was a key point in their decision (SG used to be a TopLink account).
    Also we have a special feature making the difference: LiDO supports temporal versioning. With this feature, each time you modify an object it creates a new copy and stores the time limits where that copy was valid. Then you're able to set a viewTimePoint (a point in past or future) and you'll automatically get versions of objects (using queries or object navigation)that were valid at that time. You can imagine how this feature is important for trading room applications.

    Hope this helps.

    Best regards.
  15. JDO vendor[ Go to top ]

    Eric,

    Thanks. It's not too bad to know that JDO is used in such platforms and configurations. I'll take the time to evaluate your product next month or so in a sample application so that I can draw my own conclusions and position your product among other persistence strategies.

                    Yann
  16. the JDO position[ Go to top ]

    It is good to hear the position of a JDO vendor. Thank you, Eric. The sub-project on object-relational mapping in JDO 2.0 is a really good news. However, let me notice that the JDO project is dated around 2000 (I remember to have talked to the architect of Versant Judo at JavaOne 2000). Now let me ask you a question (I will be more than happy to be wrong on this one): do you know any JDO implementation around that deals (now, in 2003, not in yet another 6 months or 1 year) with legacy systems such as C-ISAM, Cobol files, etc.

    Now, please understand my point, I don't say that JDO is good or bad, here. I don't say either that JDO should be limited to dealing with RDBMS. I just think that we have more and more a requirements prioritization problem when it comes to developping new Java technologies. Ambition is for sure a good thing... when/if one can deliver (and hopefully within an acceptable time frame).

    Bertrand
  17. JDO for Legacy[ Go to top ]

    Bertrand

    LiDO is not yet another O-R mapping tool.
    LiDo has been originally designed to access any kind of data source.
    We already support RDBMS, ODBMS and binary files on disk. These are very different kind of data sources. The same binary code can access all of the supported data sources without any need to recompile, just changing some properties in a config file.
    We have customers using LiDO on IBM AS/400 or old Unisys systems.

    We currently have an R&D project to support legacy data sources (CICS...) through a LiDO for JCA/CCI version. It will be available somewhere in 2003.

    best regards,
  18. legacy systems[ Go to top ]

    Bertrand: "Now let me ask you a question (I will be more than happy to be wrong on this one): do you know any JDO implementation around that deals (now, in 2003, not in yet another 6 months or 1 year) with legacy systems such as C-ISAM, Cobol files, etc."

    Definitely. I went to an IBM WebSphere user group meeting where a JDO vendor called SolarMetric (KODO) presented a number of supported back ends in addition to JDBC. It's the only JDO presentation I've seen, so I can't really speak to the other vendors in the space like Hemtech, Exadel, LiDO, JRelay, Versant, etc. Obviously, most "pure" JDO vendors are focusing on JDBC first.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  19. the JDO position[ Go to top ]

    <quote>Some people are saying that JDO sucks because there is no big company supporting it. They are the ones saying in 1997 J2EE has no future, when WebExpress was still a small company with a product named Tengah.</quote>

    Good point, but don't forget WebLogic was nowhere as popular as it is today before BEAS bought it in '98-'99. So the bottom line is one of the big boys (IBM, SUNW, ORCL, and BEAS) has to start throwing money at JDO. The dozen or so niche players currently in the market will not have the critical mass unfortunately, and JDO is probably too complex for Apache Jakarta to handle.
  20. the JDO position[ Go to top ]

    Hi Eric (Samson?),

    | we do already have large accounts (Societe Generale ...
    | Saying the opposite is just relaying FUD against JDO.

    You will note in my post that I made no such assertion. I am sure that JDO vendors have "large accounts" (whatever that means) - so no charges of FUD please! ;-)
    I merely stated that none of the BIG VENDORS are backing it - and for me, the important ones to watch in this particular space are the RDBMS vendors.

    |
    | JDO is definitely not yet another ODBMS standard !!!
    |

    Well, its certainly not an O-R standard.

    The only thing that leads me to have this *feeling* about JDO is that:
    a) Most of the JDO proponents are ex-ODBMS people (versant in your case?)
    b) None of the RDBMS vendors seem interested.
    c) None of the O-R mapping tool vendors seem that interested (but perhaps thats more to do with the personalities involved than for any technical reason)
    d) O-R mapping is not really defined in the spec.

    As I said, what people are really looking for is a good O-R standard. Regardless of the fact that apparently 10 out of the 12 implementations do O-R mapping. My criticism is that, given peoples desire for an O-R mapping spec, there is not enough in the standard to *standardise* O-R mapping.
    I feel I may as well use something like Hibernate or OfBiz Entity Engine.

    | JDO is not a technology for RDBMS vendors because it tend
    | to commoditize the DB as a raw storage facility

    And thats where I see JDO's problem (at least in so far as the way its being marketed). 90% of enterprise application data is stored in a relational database. No-one is particularly interested in flat-file storage or ODBMS storage.

    | Oracle surely prefers to have a proprietary O-R mapping
    | tool using Oracle proprietary features in order to lock
    | their customer base. This is why they bought TopLink and
    | why they don't like standards

    meow! ;-)
    What about Sybase or Ibm? What are their reasons?
    At the moment, no disrespect to Libelis, the primary JDO players are small niche companies. Perhaps, as the standard matures, it will gain popularity and momentum and the vendor support will come.

    | Having JDO implementations based on low-level RDBMS APIs is
    | a nonsense from the technical point of view, and will never
    | happen, forget it.
    Really?
    I wasnt really referring to low-level api's, but more to vendor specific features. I would imagine that if Oracle were to provide a JDO implementation for 9i, they would CERTAINLY be using Oracle-specific features. If it gave them better performance or made their development easier, why at all wouldnt they?

    -Nick

    PS:
    No disrespect, but in reference to "large accounts" - its a well known fact that vendors always emphasise their "large accounts". The thing is, this can mean anything from 1000's of licenses to "they downloaded an eval once". I only say that because I know that in one of the ones listed in this thread, there is very little JDO penetration at all. (in fact, I wasnt aware of *any*)
  21. LiDO at BNP Group[ Go to top ]

    Nick,

    I've seen no disrespect in your e-mail, don't worry.

    BNPParibas (if it is the account you are speaking about) is not limited to its London offices.
    It is a quite large account in France and some of their teams are more open to JDO/LiDO (I agree that your team has always been constantly reluctant to it).

    Sanofi-SyntheLabo and SG are also large accounts (you must at least know the second one) and I would be pleased to invite you to visit them and see by yourself what kind of real projects they have on LiDO. I hope this could change your opinion.

    Most of our customers are using LiDO on Web[Sphere/Logic] and this is "not always" for small trivial applications. They pay us development and runtime licenses because they clearly understood the benefits in terms of performance and ease of use. More than 80 universities through the world are using LiDO in their courses, and large SIs like Atos are also using LiDO.

    LIBeLIS just closed its first funding round, and I can tell you that very few IT companies did it in Q4 2002. The former General Manager of BEA EMEA is now President of our Board. Some RDBMS vendors (not Oracle) are looking at LiDO very closely, and there is a JDO tutorial on the IBM developerWorks site based on LiDO. And we have actions on the field with IBM, BEA and Sun sales teams.

    IBM and Oracle approved JDO 1.0 in March 2002. They were part of the JDO expert group as TopLink guys as well. TopLink provides a basic JDO support in their latest version, but obviously this is not part of the whole Oracle strategy.
    At the same time they spit on JDO and they spend time to support it.
    What a clear strategy for a BIG VENDOR.
    Just try to freeze the market, as always.

    Sun is also a BIG VENDOR. They decided to redesign the persistence layer of SUNOneServer on top of JDO.

    Last, I agree JDO 1.0 is not an O-R mapping standard.

    But what is an Hibernate/TopLink application today:
    * proprietary design, architecture, tools, APIs, global metadata, mapping metadata, J2EE integration

    What is a LiDO application:
    * standard design, architecture, APIs, global metadata, J2EE integration
    * proprietary tool and mapping metadata

    Make your choice.

    best regards,
  22. LiDO at BNP Group[ Go to top ]

    This has become a really interesting thread. I'm glad to learn that I may have been wrong in being negative about JDO takeup.

    Rod
  23. JDO versus Entity Beans[ Go to top ]

    Many discussions about Entity Beans Persistence derives into discussions about JDO versus EJBs.

    As a JDO vendor, I'd like to say that we do not position LiDO against Entity Beans at all.

    What we say is:
    * Most J2EE applications only use JSP/Servlets and JDO is a convenient solution for them
    * Most EJB applications only use SessionBeans and JDO is an erffcient solution for them again. Doing like that, they get all benefits of EJBs (transactions, security...) and the flexibility and performance of plain persistent Java/JDO classes

    Very few applications are using Entity Beans today, but I think there is still a need for Entity Beans because they provide a component model.

    The big mistake has been to couple the persistence layer at the Entity Bean level. Entity Beans should be reserved for large business objects, allowing to present a component model.
    Entity Beans (even in EJB 2.0) have too much overhead to be persistent by themselves.

    I can imagine future applications calling services (Session Beans) calling components (Entity Beans) accessing low-level information through plain JDO classes.

    This is not the standard envinorment today. The fact is the Component market is not ready. Is it not enough to get a component model (EJB) and deployment infra-structure (container), a lot of extra tools are necessary in order to get a real Component market.

    Best Regards,
  24. JDO versus Entity Beans[ Go to top ]

    This article definitely has thrwon very interesting aspects about how JDO technology *stands* out, in the sense, it entirely may not be a competing technology with 'Entity EJBs' but may complement them.
    Hope that aspect can be appreciated.
    -Linux Rox
  25. JDO not limited to J2EE[ Go to top ]

    Nick

    you said:
    >>No-one is particularly interested in flat-file storage or ODBMS storage.

    I agree with you when we limit the discussion to large IS management applications in J2EE Appl. Servers.

    But JDO is not limited to J2EE. We have prospects and customers interested in using LiDO in mobile devices or embedded applications. For instance LiDO + its internal binary file DB gives you a very fast transactional, persistent storage running in less than 350 KB.

    Best Regards,
  26. Depends what you mean by 'native'[ Go to top ]

    <bertrand>
    1) The container was supposed to use the native database protocol instead of JDBC. The idea was to allow developers to achieve top performances without sacrifiying portability. I think that it is widely accepted within the industry that JDBC is *really* slow compared to native database calls.
    </bertrand>

    Alot of JDBC drivers out there today *are* indeed native. ("instead of JDBC" makes no sense. JDBC is an API which wraps a driver implementation of that API) Now, I consider native meaning the output of the driver is the network packet protocol used by the network listener of the database. For instance, the Sybase jConnect driver actually does wrote out TDS packets on the wire, without the need to call to an underlying protocol. So in my mind, this is indeed 'native'. Yes, Sybase does provide a C library called OpenClient which also writes out TDS packets, but this is in my mind at the same level of 'nativity' that the JDBC driver is at.

    What do you consider a native driver?
  27. Depends what you mean by 'native'[ Go to top ]

    Dave, if database vendors implement the EJB containers, you can just remove JDBC out of the picture, they can directly invoke the native database functions without calling it through an additional layer. Also, container developers don't need to take cross-database portability into consideration anymore, they can use any relevant database optimization feature they want. Java developers, however, keep portability because changing the target database is just a matter of switching the container, the EJB code is not hurt. This was the idea.

    Bertrand
  28. JDBC isnt an additional layer[ Go to top ]

    Bertrand,

    No matter what the database or container vendors do, they must have some kind of API to allow your Java code to execute DML calls. (Unless you consider inline SQL, which then the compiler itself would abstract out to some interface API). I dont consider that an 'additional' layer. JDBC happens to be that API. There is no more overhead in JDBC as an API, then there would be in another API. Yes, JDBC can introduce some overhead in the use of standard escape syntaxes which must be parsed by the driver, but these can be avoided by the use of literal syntax as well.

    What do you propose the container and database vendors do which is thinner or faster then JDBC? No matter what, doesnt there need to be some API to allow you to apply DML operations against the RDBMS?

    <DISCLAIMER>
    I was a former architect at a container vendor and database vendor.
    </DISCLAIMER>
  29. Excellent remarks, Rod!
    I just wanted to add comment to this statement:
    "It is best if the container or the application server vendor provides solutions to these [complex persistence] issues, so that the application writers can focus on the business logic."
    Business logic can span to the database layer. And in real life projects you have to think about performance, so you tune every single sql statement, every stored proc. CMP is not the best choice in that case.
  30. JDO comment[ Go to top ]

    Is this comment on industry acceptance of JDO true?

    'Using JDO (Java Data Objects) to persist your data is another option, although the
    industry is certainly not moving toward this model.'
  31. JDO comment[ Go to top ]

    Enrique,

    That's likely. JDO needs to gain momentum. It's still very new and existing alternatives such as entity beans, O/R mapping tool s or JDBC are widespread. I'm very interested in the JDO model but if it takes off, I'm aware it should take at least a year for a wider acceptance. The specification probably has problems that are not yet evidenced because there's little use AFAIK of JDO in critical systems. And the quality of implementations can probably be much enhanced. Also it will take time before big names like BEA and IBM embrace the technology and contribute to its diffusion. Oracle through TopLink is the only one application server that proposes JDO and still I think it is merely an incomplete legacy implementation of TopLink.

    So in those respects, the industry is not moving toward this model now. But it may very well do in a year from now if the EJB specification team does not update its record-centric entity bean model approach. JMO.

                    Yann
  32. JDO comment[ Go to top ]

    Sadly, I think it is true. Compare the Amazon sales rank of Robin Roos's JDO book with any book on EJB.

    I think this is a great pity. I think JDO is very promising. Unfortunately, Sun and the app server vendors aren't interested in promoting JDO, because they're so committed to the entity bean model, despite its flaws.

    It looks like some of the open source O/R mapping frameworks like Hibernate are stepping into the gap and getting increased takeup.

    Rod
  33. JDO comment[ Go to top ]

    |
    | Unfortunately, Sun and the app server vendors aren't
    | interested in promoting JDO
    |

    I think that to attribute the lack of popularity of JDO to a CMP conspiracy theory is ignoring the primary problem (is everything blamed on EJB these days? ;-).

    If JDO is to gain any serious traction in the enterprise, it needs to be supported by the major *relational* database vendors - Oracle, Sybase, IBM. So far they have displayed little interest. (Only the OO database vendors are involved in any meaningful way).

    You have to ask yourself why this is? Is it, perhaps, some vindication of early criticisms that JDO was more a OODBMS spec than an O-R spec? I dont know.

    Until these major RDBMS vendors start supporting it (as they do JDBC), I see difficult times ahead for JDO in the enterprise.

    -Nick
  34. JDO comment[ Go to top ]

    I didn't call what Sun is doing a "conspiracy". There are 2 competing specifications, and they've chosen to stick with the one that came out first and already had industry momentum. IMHO, this wasn't the correct choice on the technical merits, but Sun have the right to make this call.

    It's a fact that Sun are doing very little to promote JDO. One indication of Sun's position is that Craig Russell (JDO lead) was moved to work on implementing entity bean persistence for Sun One.

    I'm not convinced that RDBMS vendors need to buy into JDO: most JDO implementations are based on JDBC, so they don't need proprietary support. I think app server vendors getting on board would make a bigger difference.

    Rod
  35. JDO comment[ Go to top ]

    Well, 2 of the 3 biggest app server vendors happen to be the largest RDBMS vendors also (IBM and ORCL), and both seem to be in no hurry to support the JDO spec (although ORCL should because it has TopLink under its wings). Until they start to get warm to JDO, the only other guy who can make a difference is BEAS. I guess BEAS is taking a wait-and-see attitude towards JDO while devoting most of the resources to enhance its EJB container.
  36. JDO comment[ Go to top ]

    |
    | I'm not convinced that RDBMS vendors need to buy into JDO:
    | most JDO implementations are based on JDBC, so they don't
    | need proprietary support. I think app server vendors
    | getting on board would make a bigger difference.
    |

    I agree that the appserver vendors getting on board would make a difference - any large company support would help.

    However, there are a couple of reasons (my opinions) why I think that the RDBMS vendor support is more important than appserver vendor support:

    1) Almost all of enterprise persistance deals with a relational database. It would make sense that the database vendors themselves supported it as they did with CMP (and as ERP vendors support their connectors)

    2) It would make sense if the RDBMS vendors used their own optimised & proprietary API's in order to get the best performance. Having the standard JDBC layer in the middle is only really of interest to 3rd party vendors. The standard JDBC in the middle is otherwise redundant.

    3) My take on JDO is that it is essentially the same as JDBC, but instead of getting a non-typesafe ResultSet, you get back your domain model - but its still a resultset. (this fits the usage, perform a query, make some in-memory changes, commit the unit of work)

    4) The appserver vendors dont need to be interested in it. Most of the implementations I have seen have been implemented as J2EE connectors - which plug into any appserver.

    5) Perceptions or otherwise, most people feel that its not an O-R mapping spec - rather its an OODBMS spec. Having some of the heavyweight RDBMS vendors supporting it would change that perception.

    Again, the question I have to ask is why are the RDBMS vendors not supporting it? I dont know the answer. I would like to know the answer.

    -Nick
  37. Re: JDO Comment[ Go to top ]

    JDO certainly is not JDBC ResultSets nor is it an "Object-database" tool. There are a variety of implementations of RDBMSs out there, and they provide simple solutions to all the hackneyed EJB patterns we've all spent so much time learning (or more accurately, unlearning all the OOP patterns). JDO includes all the "great" things about Entity Beans such as locking and cacheing, while not requiring a cluster of supercomputers to get anything resembling performance.
  38. JDO?[ Go to top ]

    Enrique: "Is this comment on industry acceptance of JDO true?"

    Oracle: "Using JDO (Java Data Objects) to persist your data is another option, although the industry is certainly not moving toward this model."

    If you know anything about Oracle and JDO, you know what they mean is "[Oracle] is certainly not moving toward this model." Oracle _is_ on the JDO committee, and Oracle bought TopLink, but Oracle does _not_ suggest using JDO, and their TopLink product is _not_ moving to support JDO. Those are the raw facts; you can draw your own conclusions ;-)

    Regarding the industry, it is not moving en masse to JDO, but it is moving. Until recently, there wasn't a lot of choice in the JDO market and the implementations were very young and supported only basic features. That has changed, and we are now seeing more activity with JDO. When it comes down to it, if you like TopLink or Cocobase or any of the similar open source O/R mapping kits, then you should probably be standardizing on JDO. It's going to happen this year or next year, but it will happen.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  39. if you like TopLink or Cocobase or any of the similar

    >> open source O/R mapping kits then you should probably
    >> be standardizing on JDO

    Yeah I like TopLink but not necessarily JDO because the former offers be more features than the spec to solve O/R mapping problems.
    We all know O-R mapping is fundamentally flawed.
    I suggest using an O-R mapping tool primarily as a replacement for writing painful SQL but not to map a complex object graph.
    Map simple objects one-to-one to tables, abstract the data access mechanism (O-R mapping, JDBC, etc) from rest of your code so that you can replace the database access layer if such a need arise.
    I think this is the way to go instead of relying on a spec which is written before your project requirements are written.

    My 2 cents.
  40. Rajnikant,

    Excellent comment. The problem is not with the technology, but how you use it. An OR tool should allow you to abstract a select statement with 3 unions over some five level deep subqerries(preserving speed:-).
    It is also true that Joe Celko doesn't read these threads. He'd come thuuunddering on us:-)))
  41. Kodo JDO[ Go to top ]

    Representing SolarMetric, another vendor who has developed an implementation of the JDO Spec (Kodo JDO was first released in May 2001), I want to highlight our partial customer list on our website (http://www.solarmetric.com/Software/Customers/) as evidence that JDO is gaining traction today. A few case studies and testimonials can be seen there. I think all the JDO vendors are actively gathering more case studies as we speak.

    Also, to compare JDO to EJBs book sales seems like you are comparing apples to a fruit basket. What I find interesting are the number of books that are coming out on JDO (in addition to "Java Data Objects", O'Reilly has one currently being written, Core JDO is currently being technically reviewed on the Server Side, Apress has one coming out soon) and the number of books that are talking about some of the issues relating to entity beans being misused (another book being technically reviewed on the Server Side is Bitter EJBs - for full disclosure, Patrick Linskey, SolarMetric's VP of Engineering, is a co-author of it).

    Finally, I have a question in to Oracle if the the comment was opinion or based on fact of some form or fashion e.g., interviews, surveys, etc. If I get a response and am allowed to publish, I'll pass it on.

    Neelan Choksi