EJB3.0和Spring比较
(译“POJO Application Frameworks: Spring Vs. EJB 3.0”)
摘要:
阅读“POJO Application Frameworks: Spring Vs. EJB 3.0”一文的读书笔记,翻译其中部分,主要分6点讲述两者的差别。
0.比较目录
1) Vendor Independence
2) Service Integration
3) Flexibility in Service Assembly
4) XML versus Annotation
5) Declarative Services
6) Dependency Injection
1. 厂商无关性(Vendor Independence )
Java平台最具竞争力的优势是厂商无关,(不依赖某个特别的厂商)。EJB3.0的标准也是开放的,并且继承了这一优势。EJB3.0的规范是由包括几乎所有Java社区内的开源和商业组织定义并支持的。EJB3.0隔绝了开发者和应用服务的具体实现。比如说:JBoss的EJB3.0是在Hibernate的基础商实现的,而Oracle的EJB3.0是基于TopLink实现的。但开发者在使用EJB3.0开发企业应用时,即不需要学习Hibernate也不需要学习TopLink,EJB3.0依然能够在JBoss或Oracle上面运行得很好。厂商无关性时EJB3.0框架现在区别于任何其他POJO中间件框架的一大特色。
当然,也有一些EJB3.0的批评者立刻指出,EJB3.0的规范还没有最终定稿,EJB3.0得到业界主要J2EE厂商完全接受还有一到两年的路要走。是的,是这样,但是既便现在企业软件采用的应用服务还不支持EJB3.0,但是,(在将来)仍然能够通过下载安装“可嵌入(embeddable)”EJB3.0产品来获得支持。这方面走在前面的JBoss就已经推出的可嵌入EJB3.0产品,开源并且支持所有兼容J2SE-5.0的环境,现在正处于beta测试阶段。其他厂商也正在迅速跟进,很快会推出他们自己的可嵌入的EJB3.0产品,特别是EJB3.0规范中的“数据持久化”部分。
另一方面,Spring是一个非基于标准的技术解决方案,并且在将来很长一段时间也将继续维持这样的状况。你可以在任何应用服务上使用Spring框架,但同时意味着你的应用已经和Spring以及Spring所选用的应用服务套牢了。
- Spring框架是一个开源项目(而不是标准),自己定义了一套XML配置文件大纲以及程序接口。几乎所以的开源项目都是这样。从长远考虑,使用Spring框架的企业应用恐怕得更关注Spring项目的运作情况(以及Interface21 Inc. ――大部分Spring的核心开发人员都来自于Interface21 Inc.)。另外,如果企业应用中采用了Spring专用服务(Spring-specific services),比如Spring事务管理或Spring MVC,事实上这个企业应用已经和Spring牢牢绑死了。
- Spring没有实现和最终服务提供者的隔离。比如,现在在选择数据持久化服务时,Spring框架使用不同的DAO和Helper类以利用JDBC、Hibernate、iBatis或JDO。所以,如果你打算改变数据持久化方式,比如从JDBC改为Hibernate,你就需要重构你的应用代码了,新的Helper类编写也是不可避免的。
2.服务集成 (Service Integration)
Spring框架站在一个高于应用服务和服务相关类库的层次上。服务集成代码(如:数据访问和Helper类等)位于框架中,并直接暴露给应用开发者。EJB3.0则相反,EJB3.0框架牢牢的集成到应用服务中,所有的服务集成代码都被封装到标准接口下面。
这样的设计使得EJB3.0的厂商可以集中优化总体性能,优化开发者体验。例如:在JBoss EJB3.0实现中,当你使用EntityManager持久化一个实体Bean POJO时,底层的Hibernate会话事务被自动的指派调用JTA事务的方法,并在JTA事务提交时被提交。使用一个简单的注释(annotation)@PersistenceContext,就可以将EntityManager和底层的Hibernate事务绑定到一个有状态的会话Bean中应用事务中。应用事务在一个会话中跨越多线程,这在Web应用的事务处理中非常有用,比如一个包含多页面的购物车功能。这样的简单性和接口集成都得益于EJB3.0、Hibernate、JBoss中的Tomcate的紧密集成。在Oracle EJB3.0框架中的情况是一致的,只不过Hibernate换成了TopLink而已。
EJB3.0服务集成的另一个例子是集群支持。如果你将一个EJB3.0应用部署到一个服务集群中,所有的负载均衡、分布缓存、状态复制等全都自动的生效了。底层的集群服务隐藏在EJB3.0编程接口后面,屏蔽了所有的复杂性。
在Spring这边,优化框架和服务之间的交互要困难得多。比如,如果要使用Spring的声明式事务服务来管理Hibernate事务,必须手工显式的在XML配置文件中配置Spring的TransactionManager和Hibernate的SessionFactory对象。Spring应用的开发者必须显式的管理那些跨越多个HTTP请求的事务。另外,Spring没有简单的利用集群的方法。
3. 服务装配灵活性 (Flexibility in Service Assembly)
因为Spring中的服务集成代码是以编程接口的形式发布的,所以应用开发者在装配服务时可以获得极大的灵活性。这使得开发者可以装备自己的轻量级的应用服务。Spring 的一个最普遍的应用就时粘合Tomcat和Hibernate来支撑简单的数据库驱动应用。在这种情况下,Spring提供事务服务,Hibernate提供持久化服务,这样的配置构成了一个迷你型的应用。
EJB3.0应用服务没有给你这类可以选择的灵活性。在大多数情况下,你将得到一套已经打包好得特性,尽管其中有些你根本就用不着。当然,如果应用服务内部是模块化设计,比如JBoss,你可以剥离这些你不用得部分。这样得定制对一个成熟得应用服务是非常有价值的。
当然,如果应用发生伸缩,范围超出了单一服务节点,你就应该在应用服务中加入其他服务,如:资源池、消息队列、集群等。当加入这些后,Spring的解决方案已经和EJB3.0 一样重量级了。
使用Spring,服务装配的灵活性使得利用模拟对象(mock object)非常容易。模拟对象可以在单元测试中代替真实的服务对象,从而使得容器外测试得以成为可能。EJB3.0应用中,大部分组件都是简单的POJO,也很容易在容器外进行测试。但是,那些牵涉到容器对象的测试(如:EntityManager),容器内测试才是最佳选择,比使用模拟对象测试更简单、更健壮、更准确。
4. XML v.s 属性注释(XML Versus Annotation)
再应用开发者看来,Spring的编程接口主要是基于XML配置文件的基础上,而EJB3.0则大量使用Java注释。XML文件可以表达复杂的(从属)关系,但是也非常冗长而且不够健壮。注释则比较简单,但却很难表达复杂关系和子属结构。
Spring和EJB3.0分别对XML配置文件和Java注释的选择是由两种框架背后的构架设计所决定的。因为注释只能容纳非常少量的配置信息,所以只有预集成的框架(大多少工作已经在框架内部完成)可以大量使用注释作为其配置解决方案。正如同我们已经讨论的那样,EJB3.0符合这种要求,而Spring,作为一种DI框架,就不能这么做。
当然,EJB3.0和Spring都在发展中都相互借鉴了对方的长处,都在不同的程度上支持XML配置或Java注释配置。XML配置文件在EJB3.0中也被用来配置注释的缺省行为。而在Spring中,注释也用来配置Spring服务。