EJB3 和 Spring 技术体系比较

随着 EJB3 规范以及支持 EJB3 的 Java EE 应用服务器的即将发布，全新 Java EE 体系架构的新战争将拉开帷幕，在过去 3 年中如火如荼的 Spring 占据了 Java EE 应用开发基础平台的大半江山，面对 EJB3 和 Spring 你应该如何选择呢？

作为一个架构师，我对 EJB 是既爱且恨，对 Spring 又恨又爱，现在我们来也把这两大技术体系来做一个全面分析和对比，希望能给大家在进行技术选型时一个更好的参考。

1. 法制 VS “民主”

EJB 规范一直由国际组织 JCP 来制定，一经通过，即作为官方标准，且各厂商都会不遗余力的推动，所以对于企业应用来说，EJB 就是法，以 EJB 为企业应用的基础架构暂且称为法治；Spring 来自开源社区，由众多的开源软件开发者参与，逐步形成的一种流行的体系标准，它的设计以 IoC(反转控制) 为核心，提倡所谓的“零”侵入设计原则，这里暂且称之为民主。

支持 EJB 的应用服务器一般是一个大而全的产品，包括了构建企业应用需要的方方面面，如果需要额外扩展一般不容易，如果对一个应用服务器不满意的话，那么可以且也只能更换整个应用服务器了，好在由于应用服务器市场百花齐放，从免费到低端再到高端，您可以任意选择；Spring 从 IoC 容器发展而来，通过不断集成 AOP、MVC、OR/Mapping 以及几乎您能想到的各项服务而提供完善的企业应用架。对于一个应用，你可以自由选择具体的技术框架的实现，SSH 就是最常用一套组合，然而且不说是否每个架构师拥有正确选择的能力，无论如何，最终的选择在设计之初一旦确定，要想更换便不那么容易，你不可能轻松的将一个基于 Spring + Struts 的应用轻松的移植到 Spring + WebWork，更不能轻松的将一个基于 Spring + Hibernate 的应用轻松的移植到 Spring + iBatis，所以对于需要长期维护和发展的应用来说，将只能寄希望于你采用的框架都能够很好的发展，并且能在升级的同时保证向前的兼容性。

综上所述，EJB 由于对于整个世界是标准的，就好像是一部国际法，一旦遵循，全球通用，你可以比较轻松的在 WebSphere、WebLogic 甚至 JBoss 之间进行切换，所以如果选择 EJB，你将在一个”法制”的环境下获得最大的民主；而 Spring 对于整个世界看似民主的，然而一旦整套架构确定下来，却成了专制，犹如美国式的民主，一旦被它征服，就成为它的专政统治了，想挣脱它的控制可就不那么容易了，其中的利害，大家细细品味吧。

2. 轻量级组件 VS 轻量级内核 VS 轻量级容器

关于轻量级内核，不论属实是否，现今的应用服务器都宣称采用了微内核技术，在此基础上建立 Java EE 的各项服务构建成完善的应用服务器；而 Spring 本身就是一个基于 IoC 的轻量内核，然后通过集成第三方的服务器来提供完整的架构。

EJB 组件曾经被认为是一个重量级的组件，而备受批评，EJB3 规范的重要目标就是简化 EJB 的开发，提供一个容器管理的轻量级的组件方案。

但是有必要提醒一下，轻量级的组件，并不意味着提供服务的容器是轻量的，不管是 EJB2 还是 EJB3，应用服务器因为需要管理组件的负责生命周期以及行为，并且内置提供了各项服务，容器自然是一个重量级的服务；至少现在看来，现有的 Application Server 提供的容器都还不足够的轻量，从个人偏好来说，我就非常喜欢 JBoss 2.4 这个版本，它有我需要的功能，同时又够简单，而现在，JBoss 4 的启动速度已经逐渐让我对它对失去了耐心。

而对于 Spring，也有同样的问题，轻量级的内核，也不意味着整个框架是轻量的，更不意味着基于 Spring 的整个应用架构是轻量的。对于 Spring，你需要去寻找并粘合各种服务，然后让他们能够稳定的在一起工作，如果应用对技术的需求较多，伸缩性要求也较高，你就会不断的在应用服务中加入其他服务，如：资源池、消息队列、集群等。当加入这些后，Spring 的解决方案已经和 Java EE Application Server 解决方案一样重量级了。

追求简单、轻量，是每一个应用架构的目标，对于企业应用的构建来说，轻量级组件标准 + 轻量的内核 + 轻量级的容器，并以此构建轻量级的应用平台，才是最终需要的。如果有轻量级的容器出现，将帮助 EJB3 在企业应用中重新占据有利的地位。

3. 可管理性与可控性

这个问题对于一次性交付的项目也许不是问题，但是对于质量要求更高、生命周期更长的产品，却是衡量平台和架构的重要因素。

基于 Spring 架构的应用，由于过分的自由和灵活，随着项目的进展，逐渐集成的第三方框架越来越多，很难保证集成的服务和编写的组件中有没有漏洞，甚至相互之间有严重的冲突，那么，掌控整个项目的质量成了难题，光是一页接一页的配置文件，就知道今后的维护成本也就随之增高，回想一下 EJB2.0 时代的 ejb-jar.xml 吧；而 EJB 因为集成的都是标准服务，而且组件模型也是固定的，加之应用服务器一般提供控制台，用来查看运行时的各项属性，并可对服务进行实时的管理，显然比 Spring 开发的应用可控性更好。

4. 功能性对比

4.1 IoC 容器，AOP 能力

在 IoC 的能力 Spring 要略强一些，但是在 EJB3 中可以完全用 Annotation 方式进行注入，在开发上要简单很多，对于一些相对比较固定的注入，采用 Annotation 更好，而对于一些可能需要经常变动的注入，XML 更加灵活，EJB3 刚好提供了这样的两种解决方案。如果你已经患有 XML 恐惧症，那么 EJB3 无疑将给您以解脱。

同时，EJB3 组件中，支持多种方式注入，比如依赖于名称、接口或者 JNDI 名，另外还支持使用 @PersistenceContext 注入 EntityManager，@Resource 注入服务器资源，如 EJBContext、TimerService 等，而一些 Annotation 已经成为 JDK6 的一部分，将来可能直接被 JDK 支持。

AOP 方面，如果您需要彻底的 AOP，并且在 Spring 中集成了 AspectJ ，那么 EJB3 自然无法比拟，但是如果您的项目以够用为原则，只需要一般方法拦截意义上的 AOP，EJB3 提供的各种回调方法应该可以满足您的要求了。

4.2 事务处理

EJB 的看家本领，Spring 也通过提供 TransactionTemplate 以及集成第三方事务处理器来支持 JTA，都支持申明式事务，可以 BMT，CMT，但无论如何，移植的器官总也没有自身长的好吧。

4.3 分布式能力

一般使用 Java EE 体系的公司都认为这是 EJB 的最大长处，但是实施并不如想象那样，一来绝大多数都是 Web 应用，依赖 Web 提供的分布式能力已经可以满足 90% 的需要了，二来大家基本上都是 Web 容器和 EJB 容器整体部署，EJB 组件的分布部署少之又少。当然如果您需要 Web 层和应用层分开部署，那么 Spring 一定不在你的考虑范围之内了。

4.4 Cluster 能力

Cluster 也是 EJB 的传统优势，但是老师说，能够发挥 EJB 集群优势的地方并不多，因为即使项目中采用了 EJB，一般也采用 Stateless SessionBean，而使用 HttpSession Cluster，既然如此，无论 EJB 还是 Spring，大家都是平等的。当然，如果您正在构建一个大型的应用，对集群的能力要求非常高，比如需要事务级的 Cluster，而且还有分布式的需求，那么估计没有多少因素会让您考虑 Web Server + Spring 的架构了。

4.5 Web Services

EJB3 中的 Web Service 和 EJB 组件集成得如此之好，使用起来再简单不过了，如下面实例所示，JAX-WS 也将逐步成为 Java Web Service 事实标准；至于 Spring 可以实现各种基于 Http 的远程调用方法，其优势并不明显。

@Stateless<br></br>@Remote<br></br>@Local<br></br>@WebService(endpointInterface = "jfox.test.ejb3.webservice.Calculator")<br></br>public class CalculatorBean implements CalculatorRemote, CalculatorLocal {<p> public int add(int x, int y) {</p><br></br> return x + y;<br></br> }<p> public int subtract(int x, int y) {</p><br></br> return x - y;<br></br> }<p>}</p>### 4.6 集成第三方框架

如果需要集成第三方框架的时候，估计您需要 Spring 了，当然前提是 Spring 已经给出很好的集成方案；而如果采用 EJB，则需要视特定的应用服务器了，推荐当类库来用，或者使用 context listener 来启动，是在不行，只能基于特定的应用服务器来进行集成，一般来说，应用服务器均提供了 JMX 集成能力。

5. 总结

纵观人类历史，官方过于强势，则必然官逼民反；而民间力量过于强大，社会必将不稳定，这都是我们不愿看到的，在技术世界里也一样。对于 EJB3 和 Spring 这两种方案，Spring 现在处于压倒性的优势一方，希望 EJB3 的出现，一来能为官方挽回一些失去的领地，二来也能继续引发更多的探讨，不再拘束于一家之言，只有百家争鸣的环境，才能让开发人员和架构人员对企业应用的构建认识得更加完善，所以最好的方式是 EJB3 和 Spring 互相促进，和谐发展。

期待一个轻量的真正以开发需求为中心的 EJB3 应用服务器的出现，为疲软的 EJB 市场注入新的活力！