JDO also supports persistence of POJOs and JDO is a standard, Hibernate is not. The EJB 3.0 persistence solution is being driven by a committe of 12 people. Hibernate and TopLink each have 1 representative on that committee of 12. 6 of the 12 committee members are JDO vendors. The JDO vendors support all the major app server vendors and are independent of all the app server vendors. JDO 2.0 implementations will be coming out in the next month or so, providing standardized OR mapping metadata, extensive query language enhancements, and attach/detach functionality that rivals that popular feature from Hibernate. Those very familiar with Hibernate and JDO 2.0 have stated that JDO 2.0 will be the best solution.
I will agree with Andy, either JDO or Hibernate is a MUCH better choice now than either CMP or BMP. JDO has 20+ vendors/implementations now. JPOX is the open source implementation that will serve as the JDO 2.0 reference implementation. So if you are leaning towards Hibernate because it is a free open source implementation, you should consider the JPOX JDO implementation. JDO is an interface based standard that provides binary compatibility across the 20+ implementations. Hibernate requires import of hibernate specific interfaces. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Andrew C. Oliver > Sent: Monday, January 10, 2005 11:03 AM > To: A. Kevin Baynes; Research Triangle Java User's Group mailing list. > Subject: Re: [Juglist] Application Servers > > > All three major vendors include statements that can be summarized as > "never use BMP" on their websites. BMP, in general, forces a > N+1 load > semantic. > > Hibernate also has a programming model that makes it easier > to seperate > the two. For instance, objects retrieved are POJOs. > > Consider Hibernate. It runs on all three and in plain java > and is most > similar to the future of EJB. The competitor of note is Toplink. > > Both JBoss and Oracle support their respective O-R systems on other > appservers. > > -andy > > A. Kevin Baynes wrote: > > >I think that my application is relatively simple, and I'm hoping to > >make the application as portable as possible. I'm trying to > completely > >separate the business rules from the persistence mechanism, allowing > >customers to connect to their DB of choice. I'm looking for > transaction > >support and single-signon. > > > >It sounds like CMP may pose portability issues, and that > maybe I should > >avoid it in favor of BMP? > > > >What other features are most prone to affect portability? > > > >Thanks. > > > >~akb > > > > > >On Sun, 09 Jan 2005 15:31:29 -0500, Cory Foy > ><[EMAIL PROTECTED]> wrote: > > > > > >>A. Kevin Baynes wrote: > >> > >> > >>>Thanks, Andy! > >>> > >>>If I understand you correctly, then the simplest thing for > me to do > >>>is to pick an app server and write to it specifically, > only taking on > >>>the task of porting to another app server as a last > resort, right? If > >>>that is the case then it will probably be JBoss. > >>> > >>> > >>Actually, the way I read it was that to determine if your > app is going > >>to be portable across app servers, you have to see what features of > >>the app servers you are going to use. In Andy's case, if > you are using > >>CMP, then you need to think about how you are going to make that > >>portable. However, if all of your app uses features that are > >>implemented similarly on the app servers, and you target the J2EE > >>standard, then you should only have minor issues with portability. > >> > >>Cory > >> > >> > >> > > > > > > > > > > > _______________________________________________ > Juglist mailing list > [email protected] > http://trijug.org/mailman/listinfo/juglist_tri> jug.org > _______________________________________________ Juglist mailing list [email protected] http://trijug.org/mailman/listinfo/juglist_trijug.org
