JBoss野心勃勃的Web Beans(中篇)

1. Web Beans风光出炉

Web Beans是JBoss以Gavin King为首，向Java SE/EE执行委员会提交的Java 规范请求，编号为299，即JSR 299。2006年5月23日，执行委员会开始投票表决，到6月5日，投票结果公布，JSR 299以全票赞成获得通过。

SE/EE执行委员会由十六个委员组成，全都是在Java领域赫赫有名的企业或者个人，其中包括像IBM、Intel、Oracle、Borland、Google和SAP这样的业界领袖，当然，Sun肯定也在执行委员会之列。在JSR 299的表决中，十六个委员意见惊人地一致，全部投了赞成票，没有反对票，甚至连弃权的都没有。

是什么让这些心高气傲的巨鳄如此步调统一，我们不得而知，不过，Hibernate的影响一定是其中一个因素，因为Hibernate实在是太成功了。除此之外，Gavin King的技术说服力，恐怕也是另一个重要原因。Gavin King目光犀利，胃口挑剔，长于发现对手的破绽，下结论很痛快，并且不留情面。在JSR 299中，Gavin King罗列了JSF的几大“罪状”，来为Web Beans寻找兴师问罪的理由。例如，JSF未提供从Managed Beans访问交易相关资源的方法，缺乏组件级或方法级的安全机制，上下文模型无法满足复杂的企业应用需求，组件模型与现有的JNDI、依赖注射、打包和部署标准不一致等等。老实说，Gaving King对JSF的数落，倒也不失公允。

Gavin King不单指出了JSF的不足，甚至刚刚发布的EJB 3.0也未能幸免。Gavin King认为，EJB的组件模型存在诸多局限性。一方面，EJB组件对Web端的上下文范围一无所知，也无法访问Web端的上下文状态，另一方面，EJB的stateful组件无法纳入Web端的上下文管理，而且，EJB的组件，总的来说，不适合用在表示层。

不要忘记，Gavin King自己就是EJB 3.0的专家组成员之一，Gavin King对JSF和EJB的抨击，绝非批评与自我批评，醉翁之意不在酒，Gavin King看中的，是JSF和EJB的弱点给了Web Beans可趁之机。

正是在这样的背景之下，Web Beans风光出炉了。一伺JSR 299获得通过，6月6日，专家组即被组成，而此时离表决结束才仅仅一天，Gavin King动作之迅速，可见一斑。专家组毫无悬念地由Gavin King担任组长，组员有十五位，Apache、Oracle、Sun和Google等位列其中，阵容十分强大。

按照专家组的初步计划，Web Beans的规范，将于2007年3月出台草案，草案经过半年的讨论和意见收集，于2007年9月发布公开案，而最终的版本，则要等到2008年的4月份了。前后一年多一点的时间，对于一个Java规范来说，不算长，尤其是，考虑到Web Beans志存高远，大有一口气吃出一个胖子来的架势，因此，十三个月对于Web Beans来说，用“非常紧迫”来形容都不为过。

2. 来自巨头们的担心

前面提到过，Web Beans以全票赞成通过SE/EE执行委员会的表决，但有个细节值得注意。十六个委员中，有十四个“voted Yes with no comment”，也就是说，他们投了赞成票，但没有作出任何评论，唯独有两个委员提出了自己的担心，这两个委员，一个是Bea，另一个是IBM。Bea认为，Web Beans是一项巨大的挑战，实现起来绝非易事，而IBM则担心，Web Beans试图从深层次上实现框架的集成，过于野心勃勃。

尽管Bea和IBM发表了不同意见，但他们最后还是投了赞成票。实际上，从表决的日志可以看出，Bea和IBM投票时，Gavin King已经获得了十六票中的十三票赞成，JSR评审通过已成定局，即使Bea和IBM全部投反对票，也改变不了JSR 299的命运。所以，与其得罪Gavin King，倒不如送他一个人情，免得自己的产品哪天也被Gavin King“惦记”上了。

另一个有趣的事，是Apache成为最后一个投票的委员。Apache投赞成票，估计心态和Bea、IBM一样，不过，Apache的这一赞成票更难投出。这是有原因的。Apache是Struts的拥有者，Struts称雄Web框架领域多年，就其影响力而言，比Hibernate有过之而无不及。Struts和JSF不同，JSF只涉足表示层，而Struts则脚踏表示层和应用层这两只船，虽然两脚都不是很稳。

按照Sun的规划，JSF其实和Struts是互为补充的，JSF弥补了Struts在表示层上的不足，而Struts则给JSF以应用层的支撑。Web Beans的出现，势必打破这样的布局，因为Web Beans明确以EJB为Java Web应用的应用层框架，而这可能会动摇Struts用户基础。Apache留待最后一刻才不得不投出赞成票，原因该如此。

如果说Apache在对待Web Beans的态度上，不免有一些私心的话，那么，IBM和Bea的担心，则完全是从纯技术的角度去判断的结果。看看Web Beans的目标，就会明白IBM和Bea的担心绝非多余。概括地说，Web Beans试图统一EJB和JSF两种组件模型，使EJB能够被用做JSF的Managed Beans，从而大大简化Java Web应用的编程模型。必须说明的是，这只是对Web Beans目标的高度概括，熟悉EJB和JSF的专家，可以从这个目标中分解出一长串的任务清单，其中的每一项任务，都足以令他们挠头。

3. Web Beans口气有多大？

Gavin King显然也意识到了这一点，所以，Web Beans在理想的天堂里遨游过之后，很快回到了现实的世界。Web Beans对自己的适用范围作了限定，只有简单的、以数据驱动为核心的应用，才是Web Beans的适用对象。这样的应用，不需要用到Java EE平台的所有特性，本来就应该有一个简单的编程模型，但Java EE的全套行头显然过于沉重，如同披挂在三岁小孩身上的西装革履。大而全的规范，是Sun的拿手好戏，在获得专家们声声喝彩的同时，也暴露出Sun对小规模应用的忽视。还好，感谢开源运动，Sun未能做到的，开源世界里林林总总的轻量级框架替Sun做到了，Struts、Hibernate和Spring等俱是明证，Web Beans又何尝不是呢？

回到人间脚踏实地后的Web Beans目标，让专家组的成员们松了一口气，不过，即便如此，Web Beans的涉及面还是不小，EJB、JSF、JPA、标注、Web Service以及JSR 227（数据绑定和数据访问规范）等，均在Web Beans的视野范围之内。更何况，不甘于只在简单Web应用场合呼风唤雨的Gavin King，给Web Beans留了一个尾巴，那就是增强型的上下文模型。所谓增强，是相对于JSF来说的，在JSF的上下文模型中，Sun定义了request、session和application三个范围，而Web Beans的增强型上下文模型，增加了conversation和business process两个新的范围。有了这两个新增的范围，即使生成包含复杂状态和用户界面的应用，也会“戏剧性地（Gavin King 原话）”得到简化。

可见，Web Beans的胃口其实一点也不小，Bea和IBM的担心是有道理的。两大巨头都发话了，换作别人，也许真的会去检讨目标是否太过遥远，不过，Gavin King不会。不是Gavin King自视过高，他是聪明人，明白自己将要干什么，如果没有信心能够按期达成目标，他不会这么贸然给自己套上枷锁。是什么在背后支撑着Gavin King呢？答案就是JBoss的Java Web框架利器，Seam。

出处:IT168