EJB与Spring的全面比较与JavaBean的不同

一：EJB与Spring的全面比较

Rod Johnson将Indeed.com(一个求职网站)职位列表中对EJB和Spring两种技能的需求数量进行了对比，并通过分析这一统计数据得出了一些关于EJB的发展过程及其未来的结论。他围绕着会话Bean和消息Bean对EJB展开了讨论，并承认JPA做为独立的规范是有价值的，JPA“是基于现代技术并已开始体现其价值”。首先，Johnson阐述了职位要求所体现的趋势的重要性：

职位列表是技术真正被采纳的良好指示器。它们表明公司是否把钱花在了“刀刃”上;它们为开发人员指明获取、增强相关技能的重要性(这是技术延续的一个重要因素);它们还为公司稳妥地采用特定技术提供了良好的指导。

随后，Johnson介绍了下面这个EJB和Spring图表。该图表显示，截止到2007年11月，Java职位列表对Spring技能的需求已经超越了EJB。他认为倘若现在基于EJB的应用数量仍相当可观的话，那是很令人惊诧的。

Johnson评论这些趋势的时候有些洋洋自得，因为他2003年以来就预言EJB会因他在J2EE without EJB一书中描述的那些缺点而失去其实用性。甚至在他看来，EJB3.0新的改进也不足以遏制这种趋势：

EJB 3.0改进了一些事情，但还是太少、太迟：依赖注入(DI)的能力不足以满足实际需要;拦截API认识到了需要有一个对横切关注点的解决方案，但我们看到的还是一个最差、最笨重、最容易出错的解决方案(我一直想在博客上发布的一些东西);由于要兼容那些现在已不相关的旧有技术，把它拖累了;沉重的EJB契约(它比“简化的编程模型”多出数百页)需要一个相当复杂的运行时环境，而且开销很大;尽管有语法糖(syntax sugar)，但它还是不能掩盖EJB的大量缺陷，例如启动行为、单例、以及废弃的线程模型。最后，每次改变基础环境的时候，它都要有效地绑定到一个应用服务器环境中去。

接下来，他解释了对整个行业及开发人员个体来说，EJB的衰落意味着什么：

这不是反对标准——而仅仅是有选择性地反对那些无实际意义的标准。正如我长期以来一直指出的那样，Java EE不只是EJB，任何关心这个平台的人都应该真诚地对待其各部分的质量和关联性。

随着越来越先进的技术，业务对象变成了POJOs，对特殊组件模型的依赖在减少，标记也变得不那么重要了。

抛弃EJB后会有更好的架构灵活性来应对需求的变化。随着SOA和其它力量的兴起，公司也越来越多地选择轻量级的部署平台。

Johnson总结到：“由于其绝对数量仍然相当多，EJB不会很快消失。但是趋势曲线清楚地表明它正在逐渐成为过去”。EJB怀疑论者Rick Hightower也相信EJB仍然会存在一段时间。同时，他还表现出对这种对比方式的关注：

然而，EJB被废弃还是比较遥远的事情，难道不是吗?把Spring这样的通用架构(比如Spring MVC、Spring WebFlow、Spring XXX)和EJB这样有侧重点的框架放在一起做比较真的公平吗?正如从Seam，EJB和Spring的比较图中看到的一样，对现有的开发人员来说，这种相对比较的方式是很不公平的。

对于象Seam这样的技术显然有一些疏漏，但Seam结合了EJB 3.0，它也弥补了很多EJB模型原有的缺点，也提供了许多与Spring一样的优点(使用POJOs和IOC等)。依我愚见，它要比Spring更好一些(比如说，它几乎完全基于注释，而不是XML)。我不是想打击Spring，我只是想说结合了Seam和其它技术(像JSF)的EJB3提供了一个非常可行的Spring的替代方法。

假如基于EJB的那些应用中有相当一部分内容是依赖于应用服务器的，而应用服务器恰恰是采用EJB规范专有的实现，那么在一些为它们的核心 Java企业组件模型权衡开源框架的公司中，这些趋势会增加他们的信心。这些对比在表明Spring框架正在走向胜利的同时，不也恰恰表明EJB模型即将开始失去其实用性了吗?查看英文原文：Spring Overtakes EJB as a Skills Requirement?

二、JavaBean与EJB的不同：

您现在可能已在使用 JavaBean，但还不了解它。如果有支持 Java 的浏览器，那么，在桌面上使用 JavaBean 就没有限制。使用的 Web 页面可以将 bean 作为小应用程序的一部分。您很快就会和作为浏览器可视部分的 JavaBean 交互，然后，那些 JavaBean 将与服务器上的 EJB 接口。这种能力也可以扩展到因特网和内部网。

JavaBean 和 Server Bean（通常称为 Enterprise JavaBean (EJB)）有一些基本相同之处。它们都是用一组特性创建，以执行其特定任务的对象或组件。它们还有从当前所驻留服务器上的容器获得其它特性的能力。这使得 bean 的行为根据特定任务和所在环境的不同而有所不同。

这开辟了巨大商机。因为 JavaBean 是与平台无关的，所以对于将来的解决方案，供应商可以轻易向不同用户推出其客户机方的 JavaBean，而不必创建或维护不同的版本。这些 JavaBean 可以与执行商业功能（例如订购、信用卡处理、电子汇款、存货分配、运输等）的 EJB 配合使用。这里有巨大潜力，而这正是组件代理（WebSphere Application Server 企业版）设计提供的那种潜力。

JavaBean 是一种组件，它在内部有接口或有与其相关的属性，以便不同人在不同时间开发的 bean 可以询问和集成。可以构建一个 bean，而在以后构造时将其与其它 bean 绑定。这种过程提供了先构建，然后重复使用的方法，这就是组件的概念。可以将这种单一应用程序部署成独立程序、ActiveX 组件或在浏览器中。

JavaBean 因其外部接口（即属性接口）而与纯对象不同。这种接口允许工具读取组件要执行的功能，将其与其它 bean 挂钩，以及将其插入其它环境。JavaBean 设计成对单一进程而言是本地的，它们在运行时通常可视。这种可视组件可能是按钮、列表框、图形或图表 - 但这不是必需的。

可执行组件

Server Bean 或 EJB 是部署在服务器上的可执行组件或商业对象。有一个协议允许对其进行远程访问或在特定服务器上安装或部署它们。有一系列机制允许它们将服务安全性、事务行为、并发性（由多个客户机同时访问的能力）和持久性（其状态可以保存多久）的主要方面授权给 EJB 服务器上其所在的容器。当安装在容器中时，它们获得各自的行为，该行为提供不同质量的服务，因此，选择正确的 EJB 服务器至关重要。这正是 IBM WebSphere 企业版的优势所在。

EJB 是设计成运行在服务器上，并由客户机调用的非可视远程对象。可通过多个非可视 JavaBean 构建 EJB。它们有一个部署描述符，其目的与 JavaBean 属性相同：它是以后可由工具读取的 bean 的描述。EJB 还独立于平台，一旦编写好，还可以在任何支持 Java 的平台（包括客户机和服务器）上使用。

因为 EJB 由诸如 IBM VisualAge for Java 这样的工具集生成，所以，它是基于服务器的对象，并用于远程调用。它们安装在 EJB 服务器上，并象调用其它 CORBA 远程对象那样获得进行调用的远程接口。

ActiveX 对象

可以将 JavaBean 部署成 ActiveX 对象，虽然 EJB 的代理也可以这样做，但是，因为 ActiveX 运行在桌面上，所以，EJB 本身不能成为 ActiveX 对象。要在与平台相关的、仅 Windows 平台上做到这一点，开发人员可以将 JavaBean 变换成 ActiveX 组件。

好处

EJB 的主要好处在于：构建 bean时，bean开发人员可以规定需要什么类型的行为，而不必规定如何去做。开发分为两部分：程序员开发 bean，然后验证：它可与构建工具一起工作，并包括标识所需服务质量行为种类的部署描述符。下一步，另一个程序员可以采用这个 bean，并使用读取 EJB 部署描述符的部署工具，然后将该 bean 安装到 Enterprise Java Server 上的容器中。在第二步中，部署工具采取一些操作 - 这可能意味着生成如状态保存代码，放入事务挂钩，或执行安全性检查这样的代码。所有这些操作由部署工具生成，bean 开发人员和部署人员可以是不同的人。

可以通过使用部署工具，将任何独立于平台的 JavaBean 改写成具有可靠服务质量、特定于平台的 EJB，以满足现有商业系统和应用程序的特定需求。这就是 EJB 服务器对集成系统、网络和体系结构如此重要的原因所在。

EJB 与 IBM WebSphere 企业版

在 IBM WebSphere 企业版中使用时，可以将 EJB 配置成被管理的商业对象。接受它们授权服务的容器是其安装到的容器。将 EJB 的持久性部分映射在数据或状态对象中。EJB 服务器为 EJB 提供不同的服务质量，选择正确的 EJB 服务器可能对满足完整的商业需求至关重要。“组件代理”功能极其健壮，该功能提供如负载均衡和支持服务器组中多台机器的高级功能。它还有大大超出 Enterprise Java Server (EJS) 规范所倡导的系统管理功能。因此，按照基本标准编写的 JavaBean 或 EJB 可以运行在使用“组件代理”功能的 WebSphere 企业版上，并获得那些所有的附加功能。

EJB 服务器还提供独特的特性和服务质量，而且不完全相同。IBM“组件代理”有一些强大特性 - 例如，可伸缩性，它允许开发人员将 EJB 部署到从小型系统到大型网络的不同类型服务器。开发人员可以从小处入手，例如，在一个部门中，首先在 LAN 的 Java 服务器上部署，一旦准备好，就知道可以将在那里创建的 JavaBean 和 EJB 部署到全球网络。然后，开发人员可以测试并熟悉这些 bean，试运行，制作样本等等。满意之后，开发人员可以通过将其移至高性能服务器，来大幅度扩大其规模。JavaBean 和 EJB 不受任何计算机体系结构边界的限制。它们用 Java 编写，可以运行在任何具有 Java 虚拟机的系统上，并可以使用任何 Enterprise Java Server (EJS) 来部署对象。因此，开发人员现在可以在方便的系统上构建，以后在方便的系统上部署，而不必是同一台或同样类型的机器。

IBM WebSphere 企业版支持将商业对象部署到多台服务器。EJB 作为商业对象集成到“组件代理”功能，并作为任何其它商业对象处理。因此，EJB 可以连接到所选的后端系统，并执行任何所需操作，以满足其商业需求。这就成为“组件代理”为 EJB 提供的基础设施。通过将“组件代理”用作 EJB 服务器，开发人员将能够继续使用当前旧有系统，并将其与电子商务接口一起提供。

为使 EJB 能在 WebSphere“组件代理”环境中工作，可以使用“组件代理”部署工具将其安装在一台或多台服务器上，然后将其添加到命名服务器，以便可以全局查找到它。任何可以访问公共命名服务器的人都可以找到它，找到其宿主，并可以在宿主上执行方法，同时创建 EJB。这就是“代理组件”要做的事。

示例

让我们举一个在 Web 购物站点上可以看到的电子购物车的例子。用户的购物车是一个 JavaBean。用户将货架上的商品放入购物车，这些商品本身是 JavaBean。它们全部可视，并且面向用户。结帐时，将用户购物车中的商品发送到服务器上的 EJB，该 EJB 执行一些必要的操作，如检查信用卡授权和可用额度，生成封条，或生成给发货部门的有关提什么货和发货地点的特殊指示 - 这就是商业程序已在进行的活动。

结束语

Bean 的全部意义不只是其现有能力，更在于其可以为商业提供的有竞争力的潜在能力。IT 设计师和应用开发人员现在可以将精力完全集中在商业逻辑，而将如事务、持久性和安全性的底层工作留给服务器。WebSphere 的“组件代理”功能将提供所有这些（还有后端访问）和对象事务管理器。