【翻译】EJB3.1真的来了吗？EJB3.1系列文章(一)
讨论部分已经翻译过了，详情请看：http://www.iteye.com/news/964
原文请看：http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesinEJB3-1
第一部分 EJB接口是可选的
第一个显著的改变是专家组将最后一个使得EJB不够Pojo的障碍给去掉了——Session Bean的bussiness（业务）interfaces改成了可选接口。
基于接口的编程毫无疑问的使代码之间松耦合，而且便于单元测试。这也正是EJB2.1和Spring所倡导的“组件接口”(component inerfaces)理念。但实际上，EJB3.0的Session Beans仍然至少要保证实现一个接口(EJB3.0的Message Driven Beans则没有此特殊要求)。
现在的问题是很多场合下，这种接口组件抽象是没有必要的。我已经记不得有多少次这样的经历：因为EJB框架机制，我不得不写接口，然后边写代码，心中边骂EJB以及那些只会坐在象牙塔里开发它的专家。（这里应该说的是那些曾经脱离实际的专家组们吧。）其实真的很多时候，一个普通的Java对象完全能满足你的需求，尤其那些没有做足够测试以及代码松耦合的应用系统。
EJB3.1可以做到。现在Session Bean不再需要额外的接口了，这一点和JPA Entities和Message Drivern Beans它们一样了。唯一要做的就是在你的Pojo标注上@Stateless或@Stateful就可完成Session Bean的功能。现在我们来看一个从EJB3.0中改过来的实例：
@Stateless public class PlaceBidBean {
@PersistenceContext
private EntityManager entityManager;
public void placeBid (Bid bid) {
entityManager.persist(bid);
}
}
为了使以上代码更有意义，我们来给这个 bargain-basement Bean添加一些新东西：
@Stateless @WebService
public class PlaceBidBean {
@PersistenceContext
private EntityManager entityManager;
@WebMethod public void placeBid (Bid bid) {
entityManager.persist(bid);
}
}
上面的例子中，我们使用JAX-WX2.0规范将placeBid方法暴露为一个web service。当然Bid entity也是用JPA来持久化的。PlaceBidBeans完全具备Stateless Session Bean的特性：接连池，线程安全，组件的生命周期，拦截器，安全以及声明式的事务处理都包括在内。举个例子来说，如果你熟悉EJB3.0，那么也许会想是不是placeBid方法已经被封装在一个容器事务所托JTA事务中。基于RMI的远程调用仍然支持，但确切的语法还没有定夺。除了屏弃实现必须的接口外，WebBeans使用也更容易了。Gavin King当前所领导着的WebBeans JSR(JSR 299)，大多数灵感来自JBoss Seam。Web Beans期望将JSF,JPA还有EJB3.1无缝整合起来，并且让Java EE6也如同一个整体。
第二部分 Singleton Beans
EJB 3.1的Singleton Bean等价于GOF设计模式中的Singleton模式．在JavaEE的上下文(context)中，主要用来共享应用程序存储的数据．为了不一遍又一遍的在应用程序各处查找数据库中的记录，你需要一些缓存来帮你存储一些有意义的数据．Stateless Session Beans可以做到，Stateful Session Beans也可以做到．只不过Stateful Session Beans维护的一个session缓存，并不能很轻松的在应用程序之间共享．
有很多办法来解决这个问题．最简单的就是使用static字段或GOF的Singleton模式．更复杂的策略，诸如JBoss Cache, OSCache, JSC以及SwarmCache还可以实现应用程序的集群．商业级的解决方案有：Tangosol Coherence和Terracotta．虽然这些方案都运用了很长时间，但他们都有缺点．有一些根本没有考虑线程安全（static 字段，Singleton Pojo），有一些不支持事务（Singleton POJOs, the Servlet application scope, OSCache, JCS, SwarmCache）．所有以上方案都不支持远程(remoteable)并且都没有安全机制(security mechanisms)．当你进入EJB3.1殿堂的时候，不再需要使用这样不非标准化的第三方类库了。
容器会保证维护单一共享的EJB3.1 Singletons Bean实例，这就意味着Singletons的缓存可以在应用程序级别共享。因为是EJB，它的Singletons允许你使用所有你所希望的中间件服务包括声明式事务管理，安全机制，远程调用，同步管理，依赖注入，组件生命周期回调，拦截器等等。与其它EJB组件一样，Singletons也是带有元数据的Pojos。下面就是一个简单的例子：
@Singleton
public class DiscountRateBean {
@PersistenceContext
private EntityManager entityManager;
private Rate rate;
@PostConstruct
private void init() {
rate = entityManager.find(Rate.class, 1);
}
@PreDestroy
private void destroy() {
entityManager.merge(rate);
}
public void setRate(Rate rate) {
this.rate = rate;
}
public Rate getRate() {
return rate;
}
}
在这个例子中，JPA在Bean创建时加载数据，并且在Bean销毁时保存数据（Bean通常是随着应用程序的关闭而关闭）。任何bean调用getRate和setRate都将保证只访问一个存储数据的DiscountRateBean实例。你会注意到一些有趣的问题：如果容器没有机会去回调pre-destory方法，所有的更新操作都会被取消。我们将在以后的文章介绍如何通过类似于cron timers这样的技术来将这个问题所带来的影响降到最低。
通常情况下，所有的Singleton方法都是线程安全的并且具备事务处理。这意味着所有线程会轮流访问该bean，并且所有的方法假设已经有了REQUIRED事务行为属性。（你觉得这些默认值合理吗？如果不是，请说明为什么？）。你可以通过@TransactionManagement来改变事务行为，并且还可以通过@TransactionAttribute的元注释来表示是一个Stateful Session Bean还是Stateless Session Bean。如果你已经在一些相对大型的应用程序这么做了，你会发现getRate和setRate方法连续访问会成为一个严重的性能瓶颈。实际上，你只需要简单的在getRate方法上设置成只读(read-lock)，在setRate方法上设置成可读写(read-write)。你可以通过@ConcurrencyAttribute这么做：
@Singleton
public class DiscountRateBean {
@PersistenceContext
private EntityManager entityManager;
private Rate rate;
@PostConstruct
private void init() {
rate = entityManager.find(Rate.class, 1);
}
@PreDestroy
private void destroy() {
entityManager.merge(rate);
}
@ConcurrencyAttribute(READ_WRITE_LOCK)
public void setRate(Rate rate) {
this.rate = rate;
}
@ConcurrencyAttribute(READ_LOCK)
public Rate getRate() {
return rate;
}
}
如果看过Doug Lea（《Concurrent Programming in Java》一书的作者）的著作话，READ_LOCK和READ_WRITE_LOCK这两个术语来自于java.util.concurrent包。有一些应用程序共享数刚好就是只读的。在这里的话，加锁真的没有必要，因为你可以这样来建立一个非同步的Singleton。
@Singleton
@ConcurrencyAttribute(NO_LOCK) // READ_LOCK would also work...
public class DiscountRateBean {
@PersistenceContext
private EntityManager entityManager;
private Rate rate;
@PostConstruct
private void init() {
rate = entityManager.find(Rate.class, 1);
}
public Rate getRate() {
return rate;
}
}
以下两种风格是可选的：
@ConcurrencyAttribute(READ_LOCK), @ConcurrencyAttribute(READ_WRITE_LOCK) and @ConcurrencyAttribute(NO_LOCK) 以及 @ConcurrencyReadLock, @ConcurrencyReadWriteLock and @ConcurrencyNoLock。
为了保证这些低级别元注释的一致性，@TransactionAttribute将分成@TransactionRequired, @RequiresNewTranscation, @TransactionNotSupported等几种类别。
有人指出使用元注释会造成“元注释泛滥”(“annotation bloat”)，并且使源文件更加复杂。EJB与Spring，C#.NET在声明式事务上的使用annotation尺度是不一样的，支持者们都认为标记为@ConcurrencyAttribute(READ_WRITE_LOCK)更容易使用。你是怎么想的呢？
完全有可能除了得到容器提供中间件服务之外，你还想亲自管理Singleton Bean的并发以及容器本身。这个已经通过并发管理实现了（从Bean的事务管理中得到灵感）。以下是一个例子：
@Singleton
@ConcurrencyManagement(BEAN)
public class DiscountRateBean {
@PersistenceContext
private EntityManager entityManager;
private Rate rate;
@PostConstruct
private void init() {
rate = entityManager.find(Rate.class, 1);
}
@PreDestroy
private void destroy() {
entityManager.merge(rate);
}
public synchronized void setRate(Rate rate) {
this.rate = rate;
}
public synchronized Rate getRate() {
return rate;
}
}
注意到这次我们亲自管理并发事务使用同步关键字。既然容器不在干涉，你可以自由的去使用你喜欢的并发管理机制，包括java.utils.concurrent，但不仅仅限制于此。目前，新的并发管理风格只有EJB3.1的Singletons Bean有，但也有可能会对别的Bean进行类似的扩展。
Singletons同样也可以把延迟/立即加载(lazy/eager loading)的控制权交给你，在这里我们先不做过多讨论，但仍然欢迎你提出更好的建议。当前规范并没有包括集群支持，不过大多数厂商很可能都会实现Singletons的集群(就像Stateful Session Beans那样)。
第三部分 更多的EJB3.1特性
当前讨论的两个新特性已经浮出水面了。还有很多其它有意义的风格列举在JSR的议程里，以下就是一些最重的特性：
-
通过更简化的可选封装，支持 Servlet 容器直接使用 EJB 。 当前想的是把 EJB 类让在 WEB-INF/classes 目录下， ejb-jar.xml 和 web.xml 一样，放在 WEB-INF 目录下。类似的，你也当然可以把 EJB 的 jar 包放在 WEB-INF/lib 目录。
-
EJB 的作业调度服务（ Timer Service ）因支持类似于 cron 那样的作业安排 (scheduling), 部署时 timer 的建立以及 Statefult Session Bean 定时对象而得到了显著增强。
-
通过 Stateful Session Bean 支持 stateful web services 终端。
除些之外，还有一大堆特性虽然不在JSR的议程上，但同样很重要：
-
更简化的 JMS ， JavaMail 和数据库注入。比如说，你可以注入 MessageSender, 并不一定要 Queues 和 ConectionFacotry 的引用。 Gaving King 的支持使得这一切得到加强。
-
为 EJB 提供接口服务的支持。这就意味着很多第三方库可以整合进来，比如说 iBATIS, Spring, Acegi, Quartz 甚至 Groovy Beans. Bill Burke, Mike Keith 和 我都极力推荐这个特性。
-
让 EJB 有能力支持像 Tomcat 这样轻量级的 Servlet 容器，这点类似于开源中的 Embedded Jboss 。
-
除 JTA 之外，本地事务 (local transactions) 也应该在 EJB 中得到支持。我想对于一些相对较小，并不想使用 JTA 的 web 应用程序来说，是非常有用的。
Adam Bien所提到的JNDI的标准映射，同样十分有意义。它让不同的容器之间的使用更加便捷。最后的列表你是怎么想的？这样风格有用吗？它们还要再增强吗？他们比在当前JSR议程上的特性更有用吗？
第四部分 你的帮助是必要的
正如你看到，专家组正努力的为EJB3.1增加新特性，但仅凭我们的力量还是有限的。我们需要你的反馈：我们有没有偏离正确的方向？我们是还应不应该尝试别的方法？你可以直接通过JCP的邮箱[email protected]反馈给我们。如果方便的话，还可以给我抄送一份[email protected]。接下来的几个月里，我会给你们介绍专家组的讨论。到时候见吧，祝我们好运。
第五部分 相关链接