JBoss野心勃勃的Web Beans
1. 企业应用乃兵家必争之地
熟悉Java企业应用框架的开发者都知道，企业应用是Java最重要的技术领域，也是Java赖以生存和发展的巨大市场。在企业应用中，Web应用 又随着互联网的普及，成为独占鳌头的企业应用类型。在互联网基础架构日益发达的今天，越来越多的企业将自己的核心业务系统搬上Web，巨大的市场容量和诱 人的赢利前景，使得Java Web企业应用成为众多IT厂商觊觎的对象。在三流厂商忙于抢单子，二流厂商热衷创品牌的时候，手握标准和规范话语权的一流厂商，也在进行着争夺话语权的 你死我活的斗争。
一个标准的Java Web企业应用，由三个层组成，即表示层，应用层和数据层。三个层中，数据层负责维护需要长久保存的应用数据，提供数据存储、查询等功能，由关系数据库一 统天下；表示层即用户界面层，经历了从“客户端/服务器”到“浏览器/服务器”的演变，现在，基于HTTP协议的HTML浏览器成为硕果仅存的客户端标 准；应用层是竞争最激烈的战场，不但有Unix和Windows的操作系统之争，有ASP和JSP的动态网页之争，就连Java内部，也有众多的框架技术 一比长短，当然，公认的胜者非EJB莫属了。
可见，在企业应用领域，数据层多为关系数据库，这是数据库厂商们争夺的对象，与Java无 关，但应用层和表示层则需要用到Java的技术，这其中就包含Java的框架技术。从目前各种Java框架的博弈结果分析，官方的建议是在Web表示层使 用JSF框架，而在应用层采用EJB框架。
2. Hibernate试水
显然，层的划分只是出于开发、管理和维护的方便，是一种逻辑的 概念，在实际的企业应用系统中，上述的三个层是耦合在一起的，需要沟通和互动。在应用层和数据层之间，SQL曾经是标准的沟通语言，但随着面向对象思想的 深入人心，结构化的SQL语言越来越和组件模型格格不入，于是对SQL进行封装，以面向对象的方式建立应用层和数据层的沟通机制，就独立出来，成为一门叫 做“持久化”的技术。
Hibernate是近几年最热门的Java持久化技术之一，而刚刚过去的 2006年，Hibernate更是收获颇丰。Sun的Java EE 5弃Entity Beans于不顾，全盘接受Hibernate的技术、概念和思想，在EJB3.0的持久化层面，上演了一出大义灭亲的好戏，将Hibernate推向功 成名就的荣誉顶峰。
从此，Java企业应用标准的议事厅里，Sun的声音变小了，JBoss的声音变大了，Hibernate堂而皇之地坐在了Java持久化的头把交椅上。JBoss以Hibernate试水Java企业应用标准，获得了意想不到的成功。
持 久化技术，虽然只是Web企业应用框架的补充，但也是不可或缺的一部分。JBoss的聪明之处，是发现了这样一个涉足Web企业应用标准的机会，而与 Gavin King的联手，则是成功的关键。Gavin King的Hibernate是应用层和数据层的粘合剂，多年的打拼，Hibernate早已成为Java持久化技术“事实上”的标准。JBoss和 Gavin King强强合作，试水企业应用标准，一举成功是意料之中的了。
3. Web Beans入局
Hibernate大获全胜，无疑让JBoss和Gavin King尝到了甜头，同时也增强了他们的信心，等待着下一次机会的到来，随时准备发动下一场战役。当Sun的JavaServer Faces技术推出以后，凭着独创性地在Web开发上引入了组件模型和事件驱动模式，Java Web企业应用框架的重心逐渐向JSF倾斜。随着Sun及其合作伙伴的大举投入，JSF在经历了长时间的蛰伏之后，慢慢崭露头角，大有成为表示层框架的标 准之势。
2006年是JSF加速发展的年头，1.2版本规范颁布，解决了JSF使用过程中暴露的主要问题，JSF的各种实现 （Implementation）和扩展如雨后春笋般涌现。当Java EE 5将JSF上升为强制规范之后，JSF成为Java Web表示层框架的标准，几成定局，JBoss和Gavin King等待的机会又来了。他们的武器还是粘合剂，不过这次，他们要粘合的不是数据层和应用层，而是应用层和表示层。粘合剂的名称，就叫做Web Beans。
称Web Beans为粘合剂，也许不太恰当，因为Web Beans的目标，并非粘合应用层和表示层那么简单。Web Bean其实是JSF的Managed Beans的升级版或者替代品。Managed Beans是JSF的一项技术，用于在Web页面和业务逻辑之间建立联系。页面通过EL访问Managed Beans，而Managed Beans可以访问后台的EJB或者应用层的其他组件和功能，这样，用户就可以通过页面实现对应用系统的操作。
Managed Beans机制最突出的优势，是其对象的实例化由JSF框架自动控制，无需程序员干预，这在一定程度上简化了Java Web开发。另外，值得一提的是，JSF为Managed Beans定义了三种上下文范围，分别是请求范围、会话范围和应用范围。所谓上下文，是指Web应用的一系列请求之间的前后联系，Managed Beans的上下文范围，定义了其生存周期，例如，会话范围的Managed Beans，始于会话的开始，止于会话的结束。Managed Beans在生存周期内，其实例状态得到维护，因此，是在不同请求之间传递应用系统状态的一种手段。
可惜的是，JSF没有在应用层上 下太多的功夫，与应用层交互的唯一手段，只有Managed Beans。这倒也怪不得JSF，因为JSF的定位本来就是表示层框架，在Sun的蓝图里，应用层由EJB主持大局。如同应用层和数据层之间需要持久化技 术来粘合一样，应用层和表示层之间，同样需要某种技术来粘合。Managed Beans有一定的粘合作用，但远远不能满足企业应用编程的需求。这正是Gavin King所需要的。Gavin King做事向来雷厉风行，这次也不例外，抓住JSF的几条小辫子之后，Gavin King和JBoss祭出了Web Beans的大旗。
4. 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来说，用“非常紧迫”来形容都不为过。
5. 来自巨头们的担心
前面提到过，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的专家，可以从这个目标中分解出一长串的任务清单，其中的每一项任务，都足以令他们挠头。
6. 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。
7. Seam为Web Beans铺路
Seam是JBoss的拳头产品之一，与Hibernate有着同等重要的地位。JBoss Seam是一个功能强大的Web应用框架，Seam的英文含义是“缝合”的意思，正如Seam的名字所暗示的那样，Seam是一瓶极具粘合力的技术缝合 剂，能够将Ajax、JSF、EJB3、Portlet以及Business Process Management （BPM）等诸多技术缝合在一起。Seam的剑锋直指下一代的Web2.0应用，而它所统一和集成的这些技术，正是Web2.0所必须的。
Seam的使命是降低Java应用的复杂度，不但从架构级，而且深入到API级别。在Seam看来，复杂的Web应用，可以通过一些简单组件的组合来实现，这些组件包括经过注释的POJO，用户界面组件或JavaScript部件，以及少量的XML。
组件模型是Seam的核心，在Seam里面，什么都是组件。这不奇怪，随着面向对象思想的深入人心，组件模型早已成为软件编程的不二选择，不过， Seam的组件模型有其出人意表之处，那就是Seam打破了传统编程理论中，表示层组件和应用逻辑组件之间牢不可破的界线，将表示层组件模型和应用层组件 模型，合而为一。Seam的这一做法是一面双刃剑，一方面，对于小规模应用，两个组件模型界线的模糊化，显然简化了应用框架的格局，降低了编程的复杂度， 但另一方面，表示层和应用层的融合，与现代分层理论和实践相违背，是否适用于大规模复杂应用，有待实际项目的考验。
两种框架经Seam缝合之后，在Seam里面运用组件就非常容易了。简单的POJO自然不在话下，即使是EJB，由于EJB3已经通过注释技术，将 EJB从重量级、粗粒度的对象，转变成了轻量级、细粒度的对象，在Seam里面的运用也是轻而易举的。当然，Seam的用途并不局限于EJB3，Seam 可以用在任何J2EE环境中，甚至在简单的Tomcat中，Seam也能找到用武之地。这得益于Seam的API级别的基础框架。
在Seam之前，HTTP Session是Web应用状态管理的唯一手段，Seam改变了这种状况。Seam提供了多种不同粒度的上下文状态，其范围涵盖从对话级别到业务流程级 别，将程序员从HTTP Session的局限性中解脱出来。例如，Seam可以编写支持多浏览器窗口的Web应用，就像桌面环境下的多窗口应用一样。
此外，Seam集成了JBoss的jBPM，即JBoss业务流程管理，使得Seam具备了实现和优化复杂的工作流和页面流的能力。
在可测试性方面，由于Seam的组件都是POJO，因此，对Seam应用实施单元测试，是非常容易的。不过，对于复杂应用，单纯依赖单元测试是不够 的，因此，Seam在其框架的核心特性中，提供了对测试的支持能力，这使Seam获得了良好的可测试性。Seam的开发人员可以编写JUnit或 TestNG测试，完整地模拟系统和用户的交互过程，这样就可以在IDE内，完成系统所有组件的测试。
Seam的最新版本是1.1版，和它的前一个版本（Seam 1.0版）相比，1.1版的Seam最大的卖点是Ajax。Seam集成了基于JSF的若干开源Ajax方案，例如ICEfaces和Ajax4JSF 等。由于对Ajax功能的集成利用了Seam独特的状态和并发管理引擎，开发者无需学习JavaScript，就能替应用涂上Ajax的油彩。
8. Web Beans信心十足
从上面对Seam的介绍，可以看出Seam与Web Beans几乎完全类似，事实上，Seam正是Web Beans的前身，只不过Seam是JBoss自己鱼缸里的一条大鱼，而Web Beans则是JBoss投向Java棋盘的一枚棋子。Web Beans试图收获的果实，JBoss已经在Seam这块试验田里播下了种子。这正是Gavin King信心的来源，是Gavin King敢于夸下海口的原因。这一点，从Seam和Web Beans在时间上的前后呼应，也可以看出。Seam 1.0的发布时间是2006年6月，而此时距离Gavin King抛出JSR 299不足一个月，也就是说，在Seam发布前不到一个月，当JBoss的Seam项目刚刚结束内部发布，准备推向公众之时，Gavin King看到了Web Beans的目标是可以达成的，所以毅然提交了Web Beans的JSR。
Seam和Web Beans在时间上的重叠，绝非巧合，就连Gavin King自己，也承认Seam和Web Beans承前启后的关系。在提交给SE/EE执行委员会的申请中，Gavin King解释Web Beans现有的技术基础时，提到了JBoss的Seam。Gavin King认为，Seam揭示了Web Beans某些技术问题的一种可能的解决方案，并且Seam表明这些方案在原理上是可行的。
9. JBoss的野心
现在，让我们来看看，如果Web Beans成功了，Java Web企业应用框架，会是怎样一种格局呢？如前所述，从下到上，Java Web企业应用由三个层构成。最底层是数据层，中间是应用层，最上面是表示层，而粘合这三个层的，是JBoss的Hibernate和Web Beans。我们不妨稍做分析：数据层是关系数据库的世袭领地，在下一代面向对象数据库出现之前，关系数据库的地位固若金汤，不会有什么变动；表示层不如 数据层那么风平浪静，但Sun的JSF因其创新性的引入了组件模型的概念，成为众多框架中出类拔萃者，未来无疑是JSF的；应用层可以说是最动荡不安的区 域，Sun的EJB过去有着一段失败的历史，现在虽然以全新面目推出了EJB3，但EJB的未来仍有很多未知数。所以，如果说Java Web企业应用框架会发生一些事情的话，应用层将会是主要战场。
如果上面的分析是正确的，那么，JBoss在应用层框架之役上，已经占据了相当有利的地形。应用层的下面有Hibernate虎视眈眈，上面则埋伏 着Web Beans的十万大军，JBoss之手，如同一把钳子，牢牢地控制着应用层框架。处于Hibernate和Web Beans夹击之下的应用层框架，完全落入JBoss掌中，并非不可能。只需将Hibernate的触角向上延伸，配合Web Beans的向下渗透，JBoss想要吞并应用层框架，比任何其他对手的胜算都要大一些。
JBoss是Java开源领域的一个传奇企业，以一个开源的应用服务器JBoss起家，现在已经是开源领域最活跃的力量之一了。Hibernate 和Gavin King的加盟，是JBoss发展道路上举足轻重的事件。Hibernate是JBoss梦寐以求的，Gavin King也需要一个相对稳定收入和环境，来支撑Hibernate的开发，所以，二者一拍即合。一家传奇企业与一个传奇人物走到了一起，如果不继续制造一 些传奇的产品，那倒奇怪了。Seam的身体里流淌着JBoss和Gavin King的血液，脱胎于Seam的Web Beans，是否也会在Java Web企业应用框架的历史上，写下一段传奇的经历呢？
被Red Hat以3.5亿美金的巨资收购后，JBoss迎来了企业发展的第二个春天，有Red Hat做靠山，JBoss在IBM、Sun和Oracle这些巨人面前，多少鼓起了一些抬头正视的勇气。JBoss的脾气，一如它的创始人Fleury， 坚定而固执，在Bea的WebLogic和IBM的WebSphere大收其费时，JBoss“顽固地”坚持走自己开源和免费的道路，终于在应用服务器市 场上占据了一席之地，并且获得丰厚回报。精神和物资，是迈向成功的两大基石，Red Hat的雄厚财力、Fleury的坚定信念以及Gavin King的不凡勇气，或助Web Bean成功闯关，成就JBoss在Java Web企业应用框架领域的勃勃野心。