J2EE persistence: JBoss chose JDO

zhaozj2021-02-08  428

In J2EE applications, what technology is used? This is a long-awaited problem. SUN's information is always emphasized: "We want developers to use Entity Bean's persistence issues." But many people think that Entity Bean is not a good solution, they may prefer JDO (Java Data Object). Of course, some people will use third-party O / R mapping frameworks (such as hibernate). Hold management, although this is not the technical scope of the technology I excellent, but watching others quarrel is also full of fun :)

A few days ago, JDO's support was quarreled with people in TSS. Now they find the evidence that is conducive to their own: JBoss chose JDO as a data layer core technology. If this is inexplicable, JBoss will be the first application server that does not use EJB management persistence.

---------------------------------------------------------------------------------------------------------------------------------------

JBoss Chooses Java Data Objects

According to JDO Lead Craig Russell, ".... the JBoss team discussed their strategy for persistence outside the EJB tier. After investigating all the persistence APIs currently available, they concluded that Java Data Objects would be the best interface for them to use. "

If true, this would be the first time an appserver group acknowledged that persistence outside the EJB tier matters. It's not in an appserver vendor's interests to support JDO, because such a spec adds a lot of value to non-ejb development projects, reducing the Value proposition for the EJB Container. Perhaps Jboss' Move, Along With The New 'Express' Editions of Weblogic and WebSphere Will Mean More Attention For JDO from Sun and The Big Vendors.

Excerpt from the Latest Newsletter (Which Was Emailed Today) from

JDOCENTRAL .:

JBoss Chooses Java Data Objects by Craig Russell

Several months ago, Marc Fleury announced that JBoss would make their CMP implementation available to developers working on persistence solutions outside the server environment. With no details, rumors flew about what this actually meant for persistence and the open source community.

Today, almost no-one uses BMP any more as the power of CMP is proven and working. In other words, if the CMP2.0 engine's applicability goes beyond EJB alone, why could not we imagine a CMP engine working on abstract plain old java objects? We will look at making it the default service for persistence in JBoss. in fact I would argue that CMP2.0 is doing what JDO failed to do, providing a robust and framework-worthy persistence engine for Java (once generalized). While it was widely used in designs a year ago, JDO will probably go down in history as the proverbial chicken that crossed the road when the CMP2.0 truck came along. Marc Fleury, Why I Love EJBs.But after looking at the alternatives, the JBoss team changed their tune. This week at JavaOne, the JBoss team discussed their strategy for persistence outside the EJB tier. After investigating all the persistence APIs currently available, they concluded that Java Data Objects would be the best interface for them to use.

According to Alexey Loubyansky, the author of JBossDO, At first, I planned to write our own framework for POJO persistence. I looked at Java Data Objects, Hibernate, OJB, a couple of others and decided to start with Java Data Objects. At least To have it as the base. And it is really a good spec. Thank you.

Dain Sundstrom, a committer of JBoss CMP, concurred that they plan to use their persistence abstraction engine, developed for CMP, to abstract user-visible APIs, starting with CMP for the server and Java Data Objects outside. This approach will allow them to support Other APIS as Customers Demand.

转载请注明原文地址:https://www.9cbs.com/read-711.html

New Post(0)