Spring和EJB3的技术对比

随着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的远程调用方法，其优点并不明显。

 1 @Stateless
 2 @Remote
 3 @Local
 4 @WebService(endpointInterface = "jfox.test.ejb3.webservice.Calculator")
 5 public class CalculatorBean implements CalculatorRemote, CalculatorLocal {
 6 
 7     public int add(int x, int y) {
 8         return x + y;
 9     }
10 
11     public int subtract(int x, int y) {
12         return x - y;
13     }
14 
15 }

4.6 集成第三方框架

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

5. 总结

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

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