JCP发布EJB3.0 Public Review

JCP发布了EJB3.0 Public Review，包括3个PDF文件，和前面版本相比，最大的变化就是Persistent API单独拿了出来进行讲解，并且规范指出EJB3.0 Entity Bean可以在J2EE容器外面运行，即可以只运行在J2SE环境下。

然而仔细阅读一下该规范第100页，明确指出只有JTA Entity Manager能够实现全局容器事务，而Resource-Local Entity Manager则无法使用全局容器事务。最近Hibernate网站发布了Hibernate EntityManager版本，即Hibernate的EJB3.0 Entity Bean的实现版本，我们同样可以通过阅读Hibernate EntityManager的文档得知，在J2EE容器外面使用EJB无法获得全局容器事务的支持。

如果无法使用全局容器事务，那么你就必须手工写代码来处理事务，而对于跨方法调用的事务，则必须自己使用ThreadLocal模式来进行管理。这意味着，你可以在J2EE容器外面使用EJB，但是代价就是自己手工写代码管理事务，而无法享受全局容器事务带来的好处！我们知道EJB最大的价值之一就是全局容器事务管理和自动的资源管理，如果这两点好处都没有了，我们还何必去用EJB？所以这种在J2SE下面运行EJB的承诺只不过是个幌子而已，一道cookie而已。

那么既希望使用全局容器事务，也希望不必使用J2EE容器，有没有办法呢？办法就是使用SpringFramework！SpringFramework提供了和EJB全局容器事务原理一致的可声明式容器事务。

从这些情况来看，未来的企业应用软件开发，单独在J2SE上面运行EJB，而手工写代码去管理事务这种方式不会成为主流，主流的方式一定是必须在某个容器的管理下运行，这个容器既可以是EJB3.0容器（或者广义的说J2EE5.0容器），也可以是Spring容器。

因而从某种程度上来说，SpringFramework和EJB3.0 Container是一对互相竞争的对手关系！SpringFramework的优势是更加轻量级，源代码更加开放，成本更低，低端的用户基于这些考虑会更多的使用SpringFramework；而EJB3.0的优势是大厂商的商业技术支持，更好的集群分布式功能，高端的用户基于这些原因会更多的使用EJB3.0。

何以见得使幌子？EJB3的意义在于Persistence API和容器管理是分开的，意味着EJB3无需一定运行在厂商提供的容器内，可以在任何需要的地方使用标准的API来存取数据。你可以用spring + ejb3或者ejb3自己跑在tomcat, 跑在桌面客户端，后台处理程序，也可以泡在webogic express上。不管是j2se或者j2ee都可以运行基于ejb3的应用。

当然除非我们认为spring也是j2ee容器。但实事上spring本身只需座一些简单的改进就可以一个适合的轻量级ejb3容器了。

事实上我一直认为SpringFramework就是一个轻量级的、非标准的类J2EE容器。没有容器支持情况下单独去run EJB，有多大价值？我觉得不会有很多人会这样去用。

ejb3不过是一个加了annotation的java bean， web/桌面应用/后台进程都可以用ejb3，ejb3的java bean本身就是被ejb3实现( ejb3 Persistence implemenation ）管理的，ejb3 Persistence  implemenation本身就是一个容器，而这个容器管理的仅仅是ejb3的entity bean。而传统的j2ee容器和spring管理的是应用层的所有bean，包括ejb3 Persistence  implmenetation容器这个bean。

就像hibernate/jdo实现本身就是个pojo的管理容器，然后他们本身又可以被spring作为bean来管理。

则在ejb2的容器中，管理entity bean的容器和管理应用（所谓应用就是session bean, message-driven bea, 安全阿等）的容器是同一个，所以entity bean也就无法脱离所谓的容器运行了。

而在ejb3中，用户只需要一个ejb3 persistence impl就可以在任意需要的地方使用ejb3的entity bean，然后可以根据需要选择使用对象管理容器，如spring

可以测试.

EJB容器/Spring容器在我看来最主要的功能是提供了全局容器事务（可声明的方式，而不是手工编程方式）和自动的资源管理（不需要操心如何获取Session，什么时候关闭Session，以及出现异常情况下的事务回滚等等）。这些容器提供的功能如果自己手工去编写，会非常烦琐，而且也很难管理的很好。我想这就是容器的主要价值的所在。至少对于我自己来说，尝试过Spring容器和JBoss容器给Hibernate提供的这些功能之后，我不会再考虑脱离容器来写Hibernate代码了。并且我觉得将来主流的做法都是在容器里面写，而不是脱离容器写，所以我认为脱离EJB容器的EJB组件价值不大。

那后台应用，桌面应用不可以用ejb组件？

我想你没有搞清楚在J2SE上面编写EJB和在容器里面编写EJB的差别。

因为没有容器的全局事务和自动资源管理，所以当你在J2SE上面编写EJB的时候，代码和在容器里面编写是两样的。在J2SE上面写的话，要自己编写事务处理代码，异常捕获处理代码，Session的获取和关闭等等，而在容器里面，这些代码都不需要写。因此你不可能把一个J2SE下面写的代码不改的放到容器里面跑，反之亦然。

即使在容器下面编写的代码一样可以测试，这个没有区别。

一、感觉Robbin对规范的理解有误。
1、EntityManager从使用环境角度（J2EE/J2SE）分：Container-Managed/Application-Managed。
2、EntityManager从Transaction角度分：JTA EntityManager/Resource-Local EntityManger。
很显然，Container-Managed EM必须是JTA EM。而Application-managed entity managers may be either JTA entity managers or resource-local entity managers。（这和目前Hibernate的用法一样。）
没有谁说，J2SE环境下的EntityManager必须手工编程来获得全局事务。

二、就针对声明性事务来说，从实现者的角度来说，和容器关系很小。
资源(譬如JDBCConnection）自动征集是声明性事务的关键，而自动征集的关键又在于DataSource(一般是XADataSource)和厂商特定的JDBC驱动。这些东西完全是实现的细节问题，也就是说你来做声明性事务，可以采用任何的方法，和“容器”这样的概念扯不上太多。

三、EJB3.0规范最大的特色就如Charlesxp说的，很重要的一点就是将Persitence API独立出来。

我想在spring下写的代码直接放在ejb3 container里也运行不了（如果不是把spring一起deploy进去）。spring不能算ejb3容器，而是一个轻型的对象管理容器，而它本身又可以跑在j2ee容器内。如何有效使用ejb3 entity bean有很多的方法和形式，但真正的意义就在于ejb3 entity bean可以被自由的使用而不依赖于j2ee容器。可以单独使用，也可以跟spring等ioc轻型对象容器使用，使得ejb entitybean/persistence api可以作为java的通用数据访问平台。对用户来说，最大的好处是代码的可移植性和重用率大幅提高。比如在桌面应用中采用ejb3 entity bean写的组件同样可以在server端运行，反之亦然。（session bean还是不行的）