EJB For Architects Day 3: A Look Inside EJB 2.0 and JDOs


News: EJB For Architects Day 3: A Look Inside EJB 2.0 and JDOs

  1. The third day of class covered many of the new features of EJB 2.0, including the benefits of CMP 2.0, local interfaces, and container-managed relations. During lunch, I talked to another one of the students to get a better idea of the different backgrounds of the people attending the course. The highlight of the afternoon was an indepth look into JDOs and a study of their pros and cons. Photos of the class have also been added.

    Read EJB For Architects Day 3
  2. "The morning started off with a lecture on using CMP in EJB 2.0. With BMP entity beans, we have to write the JDBC ourselves which means possibly having to write a large amount of code. With CMP 2.0 entity beans, the JDBC is implicitly provided for you through a Persistence Manager (PM). The Persistence Manager is new to EJB 2.0 and specializes in complex O/R mapping. The PM is pluggable into your J2EE server. Examples of proprietory PM's include Webgain's TOPLink and Thought Inc.'s Cocobase."

    Could anyone elaborate on this. This isn't suggesting you have to have a third party PM seperate from your application server for EJB 2.0, is it? The statement above states that CMP 2.0 entity beans JDBC is provided by the PM. Isn't it still container managed, like CMP 1.1? Should the statement be referring to new BMP 2.0 changes, as opposed to new CMP 2.0 changes.

    Thanks in advance for clarification.

  3. I think the point being made is that the spec brings up a logical "thing" called a "Persistence Manager". In the real world, most of the application servers are providing this role themselves, but there are some cases (like TOPLink etc) where they plugin as the PM. The next step is for the PM to be spec'd out, so you could plugin any manager into any container. This would allow (in theory) you to use Borland's PM in WebLogic's application server, as well as letting TOPLink plug into anything.

    The PM in JDO *has* been spec'd out.
  4. Dion,

    Thanks for the feedback. So Weblogic "has" a PM built in, and WebSphere (when IBM gets to EJB 2.0) will have a PM built in. I see discussions based on deciding whether to use a tool like TopLink vs the built in CMP 2.0. Do people go with a tool like TopLink because it is more robust and offers more options at this time? I guess with EJB 1.1 they would go with such a tool because EJB 1.1 is just to limiting or requires to much JDBC code slinging. ??
  5. Mike -

    TOPLink, CocoBase, and others, offer great features. Many of which are lacking from various "off the shelf" PM's that come with our application servers today.

  6. Dion,

    Thanks for making that point!

    The CMP built-in is usually there for just spec compliance
    and isn't O/R or a real Persistence manager in the classic
    sense of the word. The approach is what we call 'code
    generation' and not O/R mapping. When we talk about O/R
    mapping it assumes that a persistence manager has some map
    that it reads at runtime to do persistence giving the
    customer on the fly mapping and querying.

    Generally CMP is all static in its mapping and as a result
    is just a front end to unmanageable embedded SQL that the
    customer doesn't even get access to - hardly a solution
    suited to the enterprise in my opinion... The good news
    however is that CocoBase provides CMP for some 30 versions
    of App Servers from a variety of vendors - so customers
    can use CMP without being stuck with a solution that's
    completely proprietary to only one app server container.
    And they get access to a world of features simply not
    available in the container.

    As for JDO, unfortunately the current JDO 1.0 wasn't written
    for O/R mapping or J2EE, so it's highly incompatible with
    building optimized J2Ee applications with relational
    databases. They promise to fix all of its standalone/ODBMS
    slants in the 2.0 release, but what JDO did get right was
    the concept of a persistence manager which is how CocoBase
    has been handling persistence for ~5+ years. I'm glad
    they at least got that part right :) To bad they still
    think java is C++ and require bytecode manipulation in
    order to be transparent...

    Just my $.02
    Ward Mullins
    THOUGHT Inc.