J2EE应用中，数据层用什么技术？这是个争论已久的问题。Sun的资料中总是强调：“我们希望开发者使用Entity Bean管理数据的持久性问题。”但是很多人认为Entity Bean并不是一个好的解决方案，他们或许更喜欢JDO（Java Data Object）。当然，还有些人宁可使用第三方的O/R mapping框架（例如Hibernate）。持久化管理，这虽然不是我擅长的技术范围，不过看着别人吵架也是满好玩的 :)
前几天，JDO的拥护者们在TSS上跟人大吵了一架。现在他们找到有利于自己的证据了：JBoss选择了JDO作为数据层核心技术。如果此言不虚，JBoss将是第一个不使用EJB管理持久性的应用服务器。
————————————————————————
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 couldn't 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.
The race is now on to be the first Java Data Objects standards-compliant open-source product. With JORM, TJDO, XORM, OJB, and now JBossDO in the running, this promises to be a very interesting competition that will greatly benefit the Java Data Objects community and Java developers all over the world.
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 couldn't 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.
The race is now on to be the first Java Data Objects standards-compliant open-source product. With JORM, TJDO, XORM, OJB, and now JBossDO in the running, this promises to be a very interesting competition that will greatly benefit the Java Data Objects community and Java developers all over the world.
扫一扫
411
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
