【翻译】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的邮箱[e-mail]反馈给我们。如果方便的话，还可以给我抄送一份[e-mail]。接下来的几个月里，我会给你们介绍专家组的讨论。到时候见吧，祝我们好运。

 

 

 

 

第五部分　相关链接

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

 

评论

3 楼 cuiyi.crazy 2008-04-01  

呵呵 原来读过了

2 楼 cuiyi.crazy 2008-03-22  

如果ejb可以在web容器运行，就只能用这样的话形容了：很好很强大

在web容器运行 与 是否可以动态改变而不须部署 未必可划等号吧？

1 楼 打倒小日本 2008-03-21  

谢谢楼主的辛勤劳动 对EJB3.1很期待