BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Gavin King谈JSR-299和Weld 1.0对Java EE与JBoss的影响

| 作者 Charles Humble 关注 790 他的粉丝 ,译者 张龙 关注 12 他的粉丝 发布于 2009年11月25日. 估计阅读时间: 9 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

前不久Red Hat的JBoss部门发布了Weld1.0.0——Java EE 6对JSR-299(Java EE的上下文与依赖注入,即Contexts and Dependency Injection for Java EE,后文简称为CDI)的参考实现。Sun GlassFish Application Server v3和即将发布的JBoss AS 5.2.0都使用了Weld实现,然而Weld并不需要完整的应用服务器。它可以运行在Servlet容器内如Jetty 6.1或是Tomcat 6,同时也能用于Java SE 5.0+。为了阐明后一点,Weld发布包中还带有一个示例性的控制台应用及一个Swing应用示例。

在JSR-299草案首次发布后,Google与SpringSource又联合提交了JSR-330,旨在标准化“一个久经考验、无可辩驳的注解集以使得注入类能够跨越多个框架”,因此在我碰到CDI规范的领导者Gavin King时就迫不及待地询问他JSR-330对CDI有何影响。

CDI现在使用JSR-330所定义的注解来声明注入点。这种影响是微乎其微的,因为330所使用的模型基本上与299大同小异。归结起来,只是注解名有所区别罢了。

要知道330并没有定义完整的依赖注入方案。它只定义了带有修饰符的注入点而已,其他的都没有定义。

InfoQ:CDI和EJB是如何处理EE 6所引入的Managed Bean模型的?

新的Managed Bean规范是JSR-299的工作成果(在规范的早期草案中我们称之为“简单Web Bean”)。简单Web Bean支持依赖注入、EL名字与拦截器,但却没有EJB那些编程约束。

Managed Bean规范引起了很多争议,Red Hat说我们确实需要支持普通Java类的注入,而其他EE涉众则表示对299定义这样一个新EE“组件”的行径感到非常不爽。

经过多次讨论后,我们认为这种“简单”组件的想法应该自成一个规范,以此构成所有其他EE组件编程模型的基础,包括EJB等等。这是一个非常棒的愿景,我们都很赞同这个观点,但EE 6并没有完全实现它。

最后的结果是:CDI可以用在普通的Java类(现在叫做“Managed Bean”)以及EJB上。现在的EJB可以看作是一种特殊的Managed Bean,只不过有一些额外的编程约束和功能。这种编程模型能够极大地降低新用户学习EE的曲线。

InfoQ:EJB还需要自己的组件模型么?

我认为EE平台的未来发展方向是逐渐将EJB特有的功能通用化,将其应用在所有的Managed Bean上。举个例子,为何不是所有的Managed Bean都支持@TransactionAttribute和@RolesAllowed呢?简直没有道理嘛。

然而EJB在为消息传输定义端点、远程与异步方法调用、定时器等领域还是有一席之地的。在这些情况下,EJB生命周期模型还是非常有意义的。

InfoQ:Seam为JSF 2和CDI创造了灵感。在JSF中修复这些问题要比在Seam中解决好在哪呢?

在尽力透明化用户体验的过程中,我们从来都没有真正满意过。用户总是注意到何时在使用JSF的特性,何时在使用本应放在JSF中的Seam特性。

CDI来源于Red Hat的开源Seam框架,从广义上来讲,它将Seam的编程模型标准化为Java EE 6的编程模型。CDI实现了Java EE 6的3个主要目的。首先,它提供了声明的方式来管理绑定到上下文组件的范围、状态与生命周期。其次,它为平台提供了标准化、注解驱动、类型安全的依赖注入框架,方式类似于Google Guice。最后,它为Java EE平台的扩展开发提供了Service Provider Interface(SPI)。

CDI的Service Provider Interface已经成为Java EE可扩展性的一个关键组成部分,而可扩展性则是Java EE 6的一个中心议题。JSR-316规范说到:

...我们相信大家都很渴望将这些技术用于Java EE应用服务器之上,或是以插件的形式使用。通过增加更多的扩展点和服务供应商接口,其他技术就可以插件的形式用于平台实现了,这么做既整洁又高效,对于开发者来说使用起来也是非常简单的,就像是内置于平台上的设备一样。

这一点大家可以从下一版的Seam(也就是Seam 3)中看到,Seam 3将CDI作为其核心引擎并使用CDI Service Provider Interface提供了CDI中并没有涵盖的众多特性,如BPM集成、Drools集成、PDF与Email模板支持以及Excel生成等等。这些扩展(也包括第三方厂商提供的其他扩展)可以运行在支持JSR-299的任何环境中,也包括任何Java EE 6环境。CDI规范说到:

可移植的扩展可以通过如下方式与容器集成:

• 提供自己的Bean、拦截器和装饰器。

• 通过依赖注入服务将依赖注入到自己的对象中。

• 为客户化的范围(custom scope)提供一个上下文实现。

• 通过外部注解增强或是提供基于注解的元数据。

Gavin King说到:

CDI和JSF 2的出现预示了Seam的新方向。

在Seam 2中,我们花费了巨大的精力填补JSF的漏洞,结果造成了没有时间集成那些非常吸引我们的表示层技术。JSF 2可以让我们将精力放在其他领域中。

最重要的是,CDI现在提供了一个核心“引擎”,可以在所有的EE 6应用服务器之间移植,甚至还可以用在Tomcat、Jetty和Resin上。该核心并不依赖于任何特定的表示层技术。其所拥有的仅仅是为可移植扩展开发者所提供的一套定义良好的SPI。该SPI作为整个生态系统的根基。如果你是一位框架开发者,那现在就会明确要想将框架与CDI及EE环境集成起来(通过扩展)需要做哪些事情。这也许是CDI最令人激动的特性了。

Seam 3将成为一套CDI可移植扩展,可以用在任何应用服务器上并向CDI编程模型提供扩展,同时能与我们感兴趣的其他技术进行集成。

JBoss CTO Mark LittleCDI和Seam将是其所有项目和平台的未来发展方向:

目前团队正与这些项目和平台(如ESB和SOA-P)紧密合作以确保新版Seam能考虑到其特定的需求。重要的是,一些项目已经认为Seam是其正确的选择,甚至都不用做任何修改,因此紧密与快速的集成要比想象的更容易一些。

King也确认了这一点并说到:

Red Hat已经成功将Seam应用到其所开发的一些项目当中了。CDI将Seam的核心功能放在了坚固的根基之上,而我们对CDI的实现Weld是个更加专注且测试良好的基础设施。这意味着我们可以将Weld应用在Seam 2不适合的各种领域中,而这与构建Web站点无关。

除了Red Hat外还有很多其他的CDI实现也即将破茧成蝶。Resin的创建者Caucho Technology拥有一个实现(CanDI),而Resin容器本身也在内部大量使用了CDI。Apache也正致力于一个名为OpenWebBeans的实现,Granite DS也有一个实现,可以将CDI应用在Flex应用中,如下

我们认为JCDI非常适合于事件驱动架构的Flex RIA。JCDI应用非常整洁,尽管JBoss Seam提供了大量的特性,但他们没必要再开发一个RIA前端了。

查看英文原文:Q&A with Gavin King on the Impact of JSR-299 and Weld 1.0 on Java EE and JBoss

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT