导读:
随着EJB3规范以及支持EJB3的JavaEE应用服务器的即将发布,全新Java EE体系架构的新战争将拉开帷幕,在过去3年中如火如荼的Spring占据了Java EE应用开发基础平台的大半江山,面对EJB3和Spring你应该如何选择呢?
作为一个架构师,我对EJB是既爱且恨,对Spring又恨又爱,现在我们来也把这两大技术体系来做一个全面分析和对比,希望能给大家在进行技术选型时一个更好的参考。
1. 法制 VS “民主”
EJB规范一直由国际组织jcp(www.jcp.org)来制定,一经通过,即作为官方标准,且各厂商都会不遗余力的推动,所以对于企业应用来说,EJB就是法,以EJB为企业应用的基础架构暂且称为法治; Spring来自开源社区,由众多的开源软件开发者参与,逐步形成的一种流行的体系标准,它的设计以IoC(反转控制)为核心,提倡所谓的”零”侵入设计原则,这里暂且称之为民主。
支持EJB的应用服务器一般是一个大而全的产品,包括了构建企业应用需要的方方面面,如果需要额外扩展一般不容易,如果对一个应用服务器不满意的话,那么可以且也只能更换整个应用服务器了,好在由于应用服务器市场百花齐放,从免费到低端再到高端,您可以任意选择;
Spring从IoC容器发展而来,通过不断集成AOP、MVC、OR/Mapping以及几乎您能想到的各项服务而提供完善的企业应用架。对于一个应用,你可以自由选择具体的技术框架的实现,SSH就是最常用一套组合,然而且不说是否每个架构师拥有正确选择的能力,无论如何,最终的选择在设计之初一旦确定,要想更换便不那么容易,你不可能轻松的将一个基于Spring + Structs的应用轻松的移植到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 Service
EJB3中的Web Service和EJB组件集成得如此之好,使用起来再简单不过了,如下面实例所示,JAX-WS也将逐步成为Java Web Service事实标准;至于Spring可以实现各种基于Http的远程调用方法,其优势并不明显。
@Stateless
@Remote
@Local
@WebService(endpointInterface = "jfox.test.ejb3.webservice.Calculator")
public class CalculatorBean implements CalculatorRemote, CalculatorLocal {
public int add(int x, int y) {
return x + y;
}
public int subtract(int x, int y) {
return x - y;
}
}
4.6 集成第三方框架
如果需要集成第三方框架的时候,估计您需要Spring了,当然前提是Spring 已经给出很好的集成方案;而如果采用EJB,则需要视特定的应用服务器了,推荐当类库来用,或者使用context listener来启动,是在不行,只能基于特定的应用服务器来进行集成,一般来说,应用服务器均提供了JMX集成能力。
5. 总结
纵观人类历史,官方过于强势,则必然官逼民反;而民间力量过于强大,社会必将不稳定,这都是我们不愿看到的,在技术世界里也一样。对于EJB3和Spring这两种方案,Spring现在处于压倒性的优势一方,希望EJB3的出现,一来能为官方挽回一些失去的领地,二来也能继续引发更多的探讨,不再拘束于一家之言,只有百家争鸣的环境,才能让开发人员和架构人员对企业应用的构建认识得更加完善,所以最好的方式是EJB3和Spring互相促进,和谐发展。
期待一个轻量的真正以开发需求为中心的EJB3应用服务器的出现,为疲软的EJB市场注入新的活力!
Infoq链接: http://www.infoq.com/cn/articles/ejb3-spring-compare
本文转自
http://linpeitian.blog.163.com/blog/static/179312020079150560708/
随着EJB3规范以及支持EJB3的JavaEE应用服务器的即将发布,全新Java EE体系架构的新战争将拉开帷幕,在过去3年中如火如荼的Spring占据了Java EE应用开发基础平台的大半江山,面对EJB3和Spring你应该如何选择呢?
作为一个架构师,我对EJB是既爱且恨,对Spring又恨又爱,现在我们来也把这两大技术体系来做一个全面分析和对比,希望能给大家在进行技术选型时一个更好的参考。
1. 法制 VS “民主”
EJB规范一直由国际组织jcp(www.jcp.org)来制定,一经通过,即作为官方标准,且各厂商都会不遗余力的推动,所以对于企业应用来说,EJB就是法,以EJB为企业应用的基础架构暂且称为法治; Spring来自开源社区,由众多的开源软件开发者参与,逐步形成的一种流行的体系标准,它的设计以IoC(反转控制)为核心,提倡所谓的”零”侵入设计原则,这里暂且称之为民主。
支持EJB的应用服务器一般是一个大而全的产品,包括了构建企业应用需要的方方面面,如果需要额外扩展一般不容易,如果对一个应用服务器不满意的话,那么可以且也只能更换整个应用服务器了,好在由于应用服务器市场百花齐放,从免费到低端再到高端,您可以任意选择;
Spring从IoC容器发展而来,通过不断集成AOP、MVC、OR/Mapping以及几乎您能想到的各项服务而提供完善的企业应用架。对于一个应用,你可以自由选择具体的技术框架的实现,SSH就是最常用一套组合,然而且不说是否每个架构师拥有正确选择的能力,无论如何,最终的选择在设计之初一旦确定,要想更换便不那么容易,你不可能轻松的将一个基于Spring + Structs的应用轻松的移植到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 Service
EJB3中的Web Service和EJB组件集成得如此之好,使用起来再简单不过了,如下面实例所示,JAX-WS也将逐步成为Java Web Service事实标准;至于Spring可以实现各种基于Http的远程调用方法,其优势并不明显。
@Stateless
@Remote
@Local
@WebService(endpointInterface = "jfox.test.ejb3.webservice.Calculator")
public class CalculatorBean implements CalculatorRemote, CalculatorLocal {
public int add(int x, int y) {
return x + y;
}
public int subtract(int x, int y) {
return x - y;
}
}
4.6 集成第三方框架
如果需要集成第三方框架的时候,估计您需要Spring了,当然前提是Spring 已经给出很好的集成方案;而如果采用EJB,则需要视特定的应用服务器了,推荐当类库来用,或者使用context listener来启动,是在不行,只能基于特定的应用服务器来进行集成,一般来说,应用服务器均提供了JMX集成能力。
5. 总结
纵观人类历史,官方过于强势,则必然官逼民反;而民间力量过于强大,社会必将不稳定,这都是我们不愿看到的,在技术世界里也一样。对于EJB3和Spring这两种方案,Spring现在处于压倒性的优势一方,希望EJB3的出现,一来能为官方挽回一些失去的领地,二来也能继续引发更多的探讨,不再拘束于一家之言,只有百家争鸣的环境,才能让开发人员和架构人员对企业应用的构建认识得更加完善,所以最好的方式是EJB3和Spring互相促进,和谐发展。
期待一个轻量的真正以开发需求为中心的EJB3应用服务器的出现,为疲软的EJB市场注入新的活力!
Infoq链接: http://www.infoq.com/cn/articles/ejb3-spring-compare
本文转自
http://linpeitian.blog.163.com/blog/static/179312020079150560708/