【翻译】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的议程里，以下就是一些最重的特性：

 

 

1. 通过更简化的可选封装，支持 Servlet 容器直接使用 EJB 。 当前想的是把 EJB 类让在 WEB-INF/classes 目录下， ejb-jar.xml 和 web.xml 一样，放在 WEB-INF 目录下。类似的，你也当然可以把 EJB 的 jar 包放在 WEB-INF/lib 目录。
2. EJB 的作业调度服务（ Timer Service ）因支持类似于 cron 那样的作业安排 (scheduling), 　部署时 timer 的建立以及 Statefult Session Bean 定时对象而得到了显著增强。
3. 通过 Stateful Session Bean 支持 stateful web services 终端。

除些之外，还有一大堆特性虽然不在JSR的议程上，但同样很重要：

 

1. 更简化的 JMS ， JavaMail 和数据库注入。比如说，你可以注入 MessageSender, 　并不一定要 Queues 和 ConectionFacotry 的引用。 Gaving King 的支持使得这一切得到加强。
2. 为 EJB 提供接口服务的支持。这就意味着很多第三方库可以整合进来，比如说 iBATIS, Spring, Acegi, Quartz 甚至 Groovy Beans. Bill Burke, Mike Keith 和 我都极力推荐这个特性。
3. 让 EJB 有能力支持像 Tomcat 这样轻量级的 Servlet 容器，这点类似于开源中的 Embedded Jboss 。
4. 除 JTA 之外，本地事务 (local transactions) 也应该在 EJB 中得到支持。我想对于一些相对较小，并不想使用 JTA 的 web 应用程序来说，是非常有用的。

Adam Bien所提到的JNDI的标准映射，同样十分有意义。它让不同的容器之间的使用更加便捷。最后的列表你是怎么想的？这样风格有用吗？它们还要再增强吗？他们比在当前JSR议程上的特性更有用吗？

 

 

第四部分　你的帮助是必要的

正如你看到，专家组正努力的为EJB3.1增加新特性，但仅凭我们的力量还是有限的。我们需要你的反馈：我们有没有偏离正确的方向？我们是还应不应该尝试别的方法？你可以直接通过JCP的邮箱jsr-318-comments@jcp.org反馈给我们。如果方便的话，还可以给我抄送一份rrahman@tripodtech.net。接下来的几个月里，我会给你们介绍专家组的讨论。到时候见吧，祝我们好运。

 

 

 

 

第五部分　相关链接

1. JSR 318: Enterprise JavaBeans 3.1
2. JSR 299: Web Beans
3. JSR 316: Java EE 6