【翻译】EJB3.1真的来了吗？EJB3.1系列文章(四)

kyo100900

浏览: 639420 次
性别:
来自: 北京

最近访客更多访客>>

囧囧有神

fancycat

smilezh

zhoujing_06

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

专家文章翻译

webbeans Seam EJB JSF JPA

前言

Raza 同学终于又出 EJB3.1 文章了，真是姗姗来迟，我也是刚翻译出来，希望和大家分享 EJB3.1 的新特性。今天主要讲的是 WebBeans ，相信很多关于 EJB3.1 的人，一定会对它感兴趣的，今天我们谈到 WebBeans 两个方面：依赖注入和增强的拦截器模型。相信今天的文章会让你有所收获。

原文：http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesinEJB3-Part4

正文

WebBeans 和 EJB ：如漆似胶

WebBeans 是当前 JavaEE6 日程安排中最激动人心的 JSRs 规范之一。支持集成 WebBeans 的主张非常有号召力。如果你用过 JSF 和 EJB3.0 来开发应用程序的话， JSF 的那层薄薄 backing bean 一定让你印象深刻。实际上，即使你可以用 @EJB annotation 很容易的将 EJB 注入到 backing bean 的话，那么 backing beans 还是在充当 glue-code 的角色。而 WebBeans 却允许你直接使用 EJB 作为 JSF 的 backing beans ，从而去掉了多余的 glue-code 。在第二小节的时候，我们共同来验证这样的美事吧。

除了更有效的整合 JSF 和 EJB 编程模型外， WebBeans 当然也少不了提供一系列很酷的特性，包括：

l 更健壮的基于 annotation 的依赖注入

l 越发简洁易用的 JavaEE 拦截器模型

l 更加合理的对 Web 应用程序的组件上下文进行管理

这里的最后一点我不想多说，因为这里更侧重的是 JSF 而并非 EJB ，但剩下的精彩主题是会一一向大家介绍的。

WebBeans 很大程度上受 JBoss Seam 和 Google Guice 的启发。现在该 JSR 规范由 Gaving King 和 Bob Lee 所领导 ( 注：两位绝对是 Java 界响当当的牛人 ) 。我个人觉得，虽然东西到了 JSR 手里肯定会有自己的实现版本，但 Seam 的核心代码仍然是 WebBeans 的基石。

让 EJB 成为 JSF 的 Backing Beans

好吧，现在我们从 EJB3 in Action 拿一个例子进行重构，从总体上看看 WebBeans 究竟是什么。在 EJB3 in Action 中，最经典的 Session bean 例子自然还是那个“竞标”例子了 (adding a bid) 。 Session bean 使用了 JPA 将一个 Bid entity( 实体 ) 持久化到数据库。现在我们来看看在 WebBeans 的环境下， session bean 和 entity 变成什么样子了：

@Component
@Stateless
@Named("placeBid")
public class PlaceBidBean {
	@PersistenceContext
	private EntityManager entityManager;

      @In
      private Bid bid;

	public void addBid() {
	    entityManager.persist(bid);
	}
}

@Component
@Entity
@Named("bid")
public class Bid {
    private Long bidId;
    private String bidder;
    private String item;
    private Double bidPrice;

    @Id
    @GeneratedValue
    public Long getBidId() {
        return bidId;
    }

    public void setBidId(Long bidId) {
        this.bidId = bidId;
    }

    public String getBidder() {
        return bidder;
    }

    public void setBidder(String bidder) {
        this.bidder = bidder;
    }

    public String getItem() {
        return item;
    }

    public void setItem(String item) {
        this.item = item;
    }

    public Double getBidPrice() {
        return bidPrice;
    }

    public void setBidPrice(Double bidPrice) {
        this.bidPrice = bidPrice;
    }
}

在 stateless bean PlaceBidBean 和 Bid JPA entity 使用 @Component annotion ，这样就可以将它们同时注册到通过 WebBeans 容器里去。 @Named annotation 给组件分配的名称可以由 WebBeans 容器识别出来。而这些名称可以直接在 JSF 页面上使用。 ( 注：比如说上面的 @Named(“bid”) 相当于为 Bid 类起了一个别名，这样做的意义在于 JSF 可以用 bid 直接取值了，比如说 #{bid.bidId}, #{bid.bidder} 等，与 Struts2 需要写一大堆 set,get 方式相比，确实精简不少。 ) 在 bid 实例变量上的 @In annoation 是告诉该 session bean ， bid 是注入进来的。我相信到这里，你应该很清楚在使用 WebBeans 组件后，相应的 JSP 页面代码会是怎么个情况了吧。图一，显示了一个实际竞价页面：

<html>
  ...
  <body>
    <f:view>
      ...
      <h:form>
        <table>
          <tr>
            <td>Bidder</td>
            <td><h:inputText value="#{bid.bidder}"/></td>
          </tr>
          <tr>
            <td>Item</td>
            <td><h:inputText value="#{bid.item}"/></td>
          </tr>
          <tr>
            <td>Bid Amount</td>
            <td><h:inputText value="#{bid.bidPrice}"/></td>
          </tr>
        </table>
        ...
        <h:commandButton type="submit" value="Add Bid" 
            action="#{placeBid.addBid}"/>
        ...
      </h:form>
      ...
    </f:view>
  </body>
</html>

正如你所看到，使用 EL 绑定在 JSF 页面上的 bidder ， item 和 bid amount 字段都与 Bid entity 的属性是一致的。而“ bid ”和“ placeBid ”匹配的就是 @Named 所标注过的组件。当 WebBeans 第一次遇到符合 @Named 所标注的 Bid 实体时，它会在隐式的在后台创建一个 Bid 的实例，并将压入 request 的 context ，供页面使用。同时你还要注意到 PlaceBidBean.addBid 方法也已经作为一个 action listener 绑定在 JSP 页面的添加按钮上。当按钮点击时，触发表单提交， WebBeans 所绑定的表单值又会自动依次中填充回 Bid 实体的各个属性，这一切还得归功于 @In annoation 。与 Bid entity 不同的是， EJB 这一块会从 JNDI 去 look up PlaceBidBean ，然后将它放入 reqeust 的 context 中。当添加按钮触发后， addBid 方法就会被调用， EJB 马上就会使用 JPA entity manager 来保存注入的实体。除了 request , application, session context, WebBeans 来发明了“ conversation ” context 。关于这些 contexts 的更多细节，请参看 WebBeans 的草案。

单凭以上代码就吹捧 WebBeans 编程模型的确没有多大的说服力。 WebBeans 用一种方法将 JSF,EJB 和 JPA 整合起来，让人感觉这似乎是一个真正的 JavaEE 无缝开发平台。它的 out of box( 即拆即用 ) ，最小化 boilerplate code ，让你如同正在使用像 Ruby on Rails 这样的框架。你是不是这样看待的呢？你觉得还是这样很牵强？这样的模型有缺陷吗？

WebBeans 的依赖注入

绝大部分的企业应用程序组件无非就是： service 组件， DAOs 以及 domain model 组件。一般来说， JPA 是实现 domain model 组件的最佳选择；而 service 和 DAO 组件又是 EJB 的不二选择。因为 EJBs 默认具备事务和线程安全的特性。 ( 很多人其实错误的认为 EJBs 默认也是支持 remote 的，这不是真的。 ) 如果你要使用声明式的 security ， remoting ， web services ， messaging ， scheduling 或者 asynchronous processing 的话， EJB 其实显然是一个更具优势的组件。上述这些 services 我们已经完全以 annoation 的形式给封装好成 EJB 组件了。

尽管如此，在一个应用程序里，总是还有一些组件并根本不需要声明式 servies ，不需要事务的感知 (transaction-aware) ，也不需要显式的线程安全保证。就拿 utilities 或 helper 组件来说吧，它们确实没有必要。因为 EJB3.0 对那些非托管的组件，并不支持依赖注入，因此不把它们也搞成 EJB ，是没法直接使用依赖注入的。 WebBeans 的依赖注入很好的解决了这个问题——因为 @Component annoation 可以运用于任何 POJO 对象，不再局限于 EJBs 和 JPA 实体了。刚才的咱们不就用 @In annoation 将 Bid entity 注入到 PlaceBidBean 这个 stateless session bean 中去了吗？因此， WebBeans 同样可以将普通的组件注入到 EJBs 中去了。

现在我们还是快速来看一个例子。假设用户输入的 bid amount 属性需要先通过一个 utility 类进行四舍五入到小数点两位，然后再保存，那么我们可以这么做：

@Component
public class MathUtil {
    ...
    public static double round(double value, int decimalPlaces) {
        BigDecimal converter = new BigDecimal(Double.toString(value));
        converter = converter.setScale(decimalPlaces, 
            BigDecimal.ROUND_HALF_UP);
        return converter.doubleValue();
    }
    ...
}

@Component
@Stateless
@Named("placeBid")
public class PlaceBidBean {
	@PersistenceContext
	private EntityManager entityManager;

      @In
      private Bid bid;

      @In
      private MathUtil mathUtil;

		public void addBid() {
          bid.setBidPrice(mathUtil.round(bid.getBidPrice(), 2));
	   	 	entityManager.persist(bid);
	}
}

在这个例子里，当 EJB 需要时，一个新的 MathUtil 的实例会被创建，然后注入到相应的 EJB bean 中去。尽管普通的 WebBeans 组件无法直接使用 EJB 的声明式 services ，但他们可以使用自己的依赖注入，生命周期回调（ life-cycle callbacks ，使用 @PostConstruct/ @PreDestroy 实现）以及 interceptoer 。

@In 和 @Component annotations 还只是冰山一角。 WebBeans 为 JavaEE 带来了一套完整的依赖注入特性，包括 Guice 风格的方法创建和 annoation 绑定。注意所有的 EJB 类型包括消息驱动 Bean 都可以使用 WebBeans 特性。

WebBeans 的 Interceptor Enhancements

相对于 EJB 来说， WebBeans 另一个主要的特性就是对现有 interceptor model( 拦截器模型 ) 的扩展。现在你可以直接在 EJBs 中使用 @Interceptor 和 @Interceptors annotations 了。这样的结构既优雅又直接，不过不是非常灵活。 WebBeans 在些基础上，通过使用 annoation, ，引入了更加灵活的 Interceptor 机制，却没有仍然没有增加什么复杂度。理解它的最好方法还是代码。现在假设我们想使用一个 auditing interceptor 来拦截 EJB 的 PlaceBidBean ，我们可以这么做：

@InterceptorBindingType
@Target({TYPE, METHOD})
@Retention(RUNTIME)
public @interface Audited {}

@Audited @Interceptor
public class AuditInterceptor {

    @AroundInvoke
    public Object audit(InvocationContext context) throws Exception {
        System.out.println("Entering: "
            + context.getMethod().getName());
        System.out.println("  with args: "
            + context.getParameters());
        return context.proceed();
    }
}

@Component
@Stateless
@Named("placeBid")
public class PlaceBidBean {
	@PersistenceContext
	private EntityManager entityManager;

      @In
      private Bid bid;

      @Audited
	public void addBid() {
	    entityManager.persist(bid);
	}
}

在 @Audited annotation 上面的那个 @InterceptorBindingType annotation 是用来声明它要绑定到一个 interceptor 上。与 EJB3.0 interceptor model 不同的是， WebBeans 通过使用 @Interceptor annotation 将一个 interceptor 绑定在一个或更多的 annotations 上。因此 @Audited 和 @Interceptor annotations 同样放在 AuditInterceptor 上面表示凡是标注了 @Audited 的组件或方法都会被拦截器拦截。因此，当 placeBid 方法被调用时， AuditInterceptor 先会触发 audit 方法的执行。

除了它的间接性与灵活性外，我觉得这个扩展真的让代码变得更加可读。你觉得呢？是不是 EJB 规范也应该采纳这个扩展，正式成为 JavaEE 整体中的一部分呢？

继续工作

由于 JavaOne 大会的原因，专家组进度慢了下来也是情有可原。但不管怎么说，还是要言归正传，回到正常的工作中来。还有很多有趣的主题正在激烈的讨论着，它们是：

l 标准 JNDI 的映射机制同时由 JavaEE6 和 EJB3.1 两个专家组同时进行讨论。相信将来这一块应该没有多少水份。（笑：难道 JSR 专家组们自己觉得自己的东西都很有水份？）

l 支持 JavaSE 环境也可以使用 EJB3.1 （比如说单元测试）的工作仍然在进行着。实际上，继 OpenEJB ， EasyBeans 和 Embedded JBoss 的路线之后， Embedded GlassFish 的动作也强烈的表明了它的决心。

l 一个很牛的扩展机制下在 JavaEE6 专家组中炸开了锅。而且好像它还是本次专家组的讨论最后一个 Big Thing 。如果通过审核，那么就会为 JavaEE 社区提供一个非标准的第三方基于 annoation 的声明式 services 组件。（ BTW ：究竟是什么，这么神秘， Raza 也真会“炒作”啊，呵呵）

你是怎么看待这些特性的？如果你觉得它们很重要，请大胆发表你的意见，并给专家组发 Email ． EJB3.1 专家组的电子邮件 jsr-318-comments@jcp.org WebBeans 专家组的电子邮件是 jsr-299-comments@jcp.org 。也可以随时给我 reza@rahmannet.net 发邮件。在此期间，我还会继续给你们介绍接下来专家组们正在讨论的特性，也许是本系列的最后一篇了。敬请期待。

参考

New Features in EJB 3.1, http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesinEJB3-1 .
New Features in EJB 3.1 - Part 2, http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesEJB31 .
New Features in EJB 3.1 - Part 3, http://www.theserverside.com/tt/articles/article.tss?l=NewFeaturesEJB31-3 .
JSR 316: Java EE 6, http://jcp.org/en/jsr/detail?id=316 .
JSR 318: Enterprise JavaBeans 3.1, http://jcp.org/en/jsr/detail?id=318 .
JSR 299: Web Beans, http://jcp.org/en/jsr/detail?id=299 .
Seam, http://www.seamframework.org .
Google Guice, http://code.google.com/p/google-guice/ .

16
顶

0
踩

分享到：

linux下websphere6.1布署webwork+spring+h ... | 【翻译】Rod Johnson——Spring的宣言：开 ...

2008-06-18 23:10
浏览 38217
评论(8)
查看更多

8 楼 spiritfrog 2008-06-23

引用

我很关系的是相应容器的热部署能力。
如果每次修改EJB都需要重新启动服务器的话，那它绝对不可能流行。

想当初用jboss+seam的时候，其他的基本都可以热部署。惟独ejb组件不行，最后没辙，直接把EJB用pojo换掉来做，但这样的话，容器换成tomcat又有何妨？seam对我来说唯一的好处就是不用在faces-config中添加managedbean了。

我很想使用EJB容器的事务等服务，但容器的热部署能力更本不能满足开发速度的要求

这种情况就会让人在技术选型的时候犹豫了，如果不是非ejb不可，多半会放弃掉。

7 楼 terranhao 2008-06-20

我感觉EJB之所以流行不了关键是容器，至少我这就是这样的

6 楼 terranhao 2008-06-20

这种变成模型真的很好很强大
我很关系的是相应容器的热部署能力。
如果每次修改EJB都需要重新启动服务器的话，那它绝对不可能流行。

想当初用jboss+seam的时候，其他的基本都可以热部署。惟独ejb组件不行，最后没辙，直接把EJB用pojo换掉来做，但这样的话，容器换成tomcat又有何妨？seam对我来说唯一的好处就是不用在faces-config中添加managedbean了。

我很想使用EJB容器的事务等服务，但容器的热部署能力更本不能满足开发速度的要求

5 楼 icess_ma 2008-06-20

这个东西感觉和现在的seam差不多，只不过是把seam的东西变成了标准

4 楼 hantsy 2008-06-19

Seam并不符合Web beans 标准。

3 楼 phoenixup 2008-06-19

引用

目前有实现么, jboss seam?

Seam可以说是个预览或者风向标~

2 楼 rocwon 2008-06-19

目前有实现么, jboss seam?

1 楼 zhoden 2008-06-19

EJB3的发展真是不错,非常喜欢这个简洁的编程模型.以前看EJB2.0,也试验过;也用了ibatis,hibernate,感觉EJB3才是我真正值得深入的一个编程模型.毕竟他借鉴了开源的这些思想,然后总结再发展而来,所以技术也更超前,总的来说,很妙,很酷!我喜欢!

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论