Spring Vs. EJB 3.0

【导读】Spring框架是一个广受欢迎的但是非标准的开源框架。EJB 3.0框架是JCP定义的并且被所有主流J2EE提供商支持的标准框架。这两个框架有着一个共同的核心设计理念，但采取了不同的方式来提供POJO服务。爱因斯坦曾经说：“任何事情都应该越简单越好，而不是比较简单。”实际上，科学真理的目的就是在假设的前提下去简化一个理论，这样，人们可以去关注真正重要的问题。在企业软件开发中

zengbo0710

758人浏览 · 2007-04-16 00:06:00

zengbo0710 · 2007-04-16 00:06:00 发布

【导读】Spring框架是一个广受欢迎的但是非标准的开源框架。EJB 3.0框架是JCP定义的并且被所有主流J2EE提供商支持的标准框架。这两个框架有着一个共同的核心设计理念，但采取了不同的方式来提供POJO服务。

爱因斯坦曾经说：“任何事情都应该越简单越好，而不是比较简单。”实际上，科学真理的目的就是在假设的前提下去简化一个理论，这样，人们可以去关注真正重要的问题。在企业软件开发中，道理是一样的。

简化企业软件开发的一个关键是，提供一个这样的应用框架：它可以使开发人员不用关注于很多复杂的问题，比如事务处理、安全和持久化等。一个设计良好的框架将提升代码的可复用性，提高开发者的效率，并得到更高质量的软件。然而，目前J2EE 1.4下的EJB 2.1 框架被广泛认为是设计较差而且过度复杂的。不满足于EJB2.1框架，JAVA开发者使用了很多其他的中间件服务产品。最值得关注的是，以下两个框架吸引了大量开发者的兴趣和积极反馈。这两个框架很可能成为未来企业JAVA应用开发框架的选择。

Spring框架是一个广受欢迎的但是非标准的开源框架。它主要由Interface21公司开发和控制。Spring框架的体系结构是基于注射依赖（DI）模式。Spring框架使用了大量的XML配置文件，它可以独立应用，或者在现有的应用服务器上工作。

EJB 3.0框架是JCP定义的并且被所有主流J2EE提供商支持的标准框架。EJB 3.0规范的预发布版本目前已经有开源的和商业的实现，如JBOSS和ORACLE。EJB 3.0大量使用了JAVA注解（Java annotations，是JDK1.5提供的新功能。译者注）

这两个框架有着一个共同的核心设计理念：它们的目标是为松耦合的POJO类提供中间件服务。框架通过在运行时截取执行环境，或将服务对象注射给POJO类的方式，将应用服务和POJO类“连接”起来。POJO类本身并不关注如何“连接”，而且也很少依赖于框架。这样，开发者可以将注意力集中在业务逻辑上，可以对他们的POJO类进行与框架无关的单元测试。并且，由于POJO类不需要继承框架的类或实现框架提供的接口，开发者可以在更加灵活性的基础上构建继承体系和搭建应用。

尽管有着共同的理念，但这两个框架采取了不同的方式来提供POJO服务。由于已经出版了大量的比较Spring与JB2.1或者EJB3.0与EJB2.1的书籍和文章，而没有关于比较Spring和EJB3.0的认真研究，因此，本文将考察它们之间几个关键的不同，讨论他们优缺点。本文谈到的主题同样适用于其他不太有名的但同样提供“松耦合POJO”设计的企业中间件框架。我希望，这篇文章可以帮助你选择最合适的你需求的框架。

提供商无关性

开发者选择JAVA平台的一个最重要的原因就是它的提供厂商无关性。EJB 3.0是一个被设计为对提供商没有依赖性的开放的标准。EJB 3.0规范由企业JAVA社区的主流开源组织和厂商共同编写和支持的。EJB 3.0框架使开发者的应用程序实现可以独立于应用服务器。比如，JBoss的EJB 3.0的实现是基于Hibernate的，Oracle的EJB 3.0实现是基于TopLink的，但是，在JBoss或者Oracle上跑应用程序，开发者既不需要去学习Hibernate，也不需要学习TopLink提供的独特API。厂商无关性使EJB 3.0框架区别于当前其他任何的POJO中间件框架。

然而，就象很多EJB 3.0的批评者很快指出的一样，目前EJB 3.0规范正在编写还未完全完成最终发布版。很有可能，还需要1至2年，EJB 3.0才会被主流J2EE厂商完全接受。但是，就算你的应用服务器本身不支持EJB 3.0，你也可以通过下载和安装一个“可嵌入的”EJB 3.0产品，来使你的应用服务器支持EJB 3.0应用。比如，JBoss“可嵌入的”EJB 3.0产品是开源的，它可以运行在任何兼容J2SE 5.0环境下（如你的应用服务器），目前处于Beta版测试中。其他厂商同样可以快速发布他们自己的可嵌入EJB 3.0产品，特别是规范中“数据持久化”部分。

另一方面，Spring一直是一个非标准的技术，而且在可以预计的未来仍将如此。尽管你在任何应用服务器都上可以使用Spring框架，但基于Spring的应用仍然被限制于Spring本身和在你的应用中使用到的Spring提供的各种特别服务。

由于Spring框架是一个开源项目，因此，它使用的配置文件XML格式和开发接口都是私有的。当然，这种限制不仅体现在Spring框架中，其他任何非标准产品都会有这种限制。但是，你的Spring应用的长期生存能力将依赖于Spring项目本身（或者说Interface 21公司，因为它雇佣了大多数的Spring核心开发人员）。并且，如果你使用了Spring提供的特殊服务，如Spring事务管理器或者Spring MVC，你同样被限制于Spring提供的API。

并且，Spring应用是知道后端服务提供者的（即应用程序是知道服务提供者的，这样应用程序将会在一定程度上依赖于服务提供方：译者注）。例如，对于数据持久化服务，Spring框架提供了不同的DAO和模板Helper类，用于JDBC、Hibernate、iBatis和JDO。这样，假如你需要改变一个Spring应用的持久化服务提供者（如，从JDBC换到Hibernate），你将需要重构你的系统应用代码，来使用新的Helper类。

服务整合

Spring框架是建立在应用服务器和服务库之上，它的服务整合代码（如数据访问模板和Helper类）是基于框架的，并暴露给应用开发者。相反，EJB 3.0框架是紧密整合到应用服务器中的，它的服务整合代码是封装在一个标准的接口下的。

因此，EJB 3.0厂商可以轻松的优化整体性能和开发者体验。如，在JBoss的EJB 3.0实现中，当你通过实体管理器持久化一个实体BEAN POJO时，Hibernate session事务将在JTA事务提交时自动提交。通过使用简单的PersistenceContext注解（例子参看后面文章），你可以甚至可以将实体管理器和其下的Hibernate事务绑定到一个有状态的session bean上。应用程序事务可以在一个session中跨越多个线程，在事务性的WEB应用中这是非常有用的，如多页面的购物车。

基于EJB 3.0 框架、Hibernate、和JBoss 内部Tomcat的紧密整合，上面提到的简单的整合的编程接口是可能的。Oracle的EJB 3.0框架和它内部的Toplink持久服务可以达到同样层次的整合。

EJB 3.0中整合服务的另一个好例子是集群支持。假如你部署一个EJB 3.0应用到一个集群服务器，所有的故障切换、负载均衡、分布式缓存、和状态复制服务对于应用程序来说，都是自动完成的。集群服务被隐藏在EJB 3.0编程接口之下，对于EJB 3.0开发者来说，这些服务都是完全透明的。

在Spring中，优化框架和服务之间交互更加困难一些。例如，想要用Spring的声明式事务服务来管理Hibernate事务，必须在XML配置文件中明确的配置Spring的事务管理器（TransactionManager）和Hibernate SessionFactory对象。Spring应用开发者必须自己管理跨越多个HTTP请求的事务。并且，没有简单的方法可以在Spring应用中实现集群服务。

服务聚合的灵活性

由于Spring中的服务整合代码是作为编程接口暴露给应用开发者的，因此开发人员可以根据需要来聚合多个服务。这个特性使你可以集成一个你自己的“轻量”级应用服务器。Spring的一个通常的用法是将Tomcat和Hibernate连接起来来支持简单的数据库驱动的WEB应用程序。在这种情况下，Spring本身提供了事务管理服务，Hibernate提供了持久化服务，这种设置本身就创建了一个小型的应用服务器。

通常，EJB 3.0应用服务器不提供给开发者这种按照你的需要来选择服务的灵活性。大多数情况，你会得到一系列已经预先打包好的特性，其中有些你可能是不需要的。然而，如果应用服务器提供了模块内部的独特设计，就象JBOSS一样，你可以不去关心这些不必要的特性。在任何情况下，去定制一个全功能的应用服务器并不是一个琐碎而没有意义的工作。

当然，如果一个应用不是一个单一的结点，你将需要连接多个应用服务器提供的服务（如资源池、消息队列和集群）。这种情况下，从总的资源消耗上看，Spring框架就和任何EJB 3.0方案一样是“重量级”的。

为了进行容器外的单元测试，Spring的灵活的服务聚合也可以来连接假对象，来替代真的服务对象。在EJB 3.0应用中，大多数的组件都是简单POJO，他们可以容易进行容器外的单元测试。但是，如果要测试与容器服务相关的服务对象（如持久化实体管理器），更好的方式是进行容器内的测试，因为这样比使用假对象来替代的方式更加容易，更加健壮，而且更加准确。

XML vs. 注解

从应用开发者的角度来看，Spring的编程接口主要基于XML配置文件，而EJB 3.0则大量的使用了JAVA注解。XML文件可以表达复杂的关系，但是它们更加冗长而且不健壮。注解的方式很简单明了，但是很难去表达复杂的或者继承性的结构。

Spring和EJB 3.0分别选择了XML和注解方式，这取决于框架的体系结构：由于注释只能描述相当少的配置信息，只有一个预先整合好的框架（如大多数重要事情已经在框架中实现了）才能大量的使用注释作为它的配置选项。象我们讨论的一样，EJB 3.0满足了这些要求，而Spring作为一个一般的注射依赖框架，它没有做到这一点。

当然，由于EJB 3.0和Spring相互学习了很多特性，所以，它们都在某种层次上支持XML和注释。例如，EJB 3.0中可以应用XML配置文件来作为一个选择性的机制，用来改变注释的默认行为。注释也可以用来配置一些Spring服务。

研究XML和注释直接区别的最好的方式就是通过例子。在下面的几节中，我们将一起看一下EJB 3.0和Spring是如何为应用程序提供关键服务的。

声明式服务

EJB 3.0和Spring都将运行时服务（如事务管理、安全、日志、消息、和信息服务）连接给应用程序。由于这些服务同应用程序的业务逻辑并不是直接相关的，因此，它们不被应用程序本身来管理。相反，这些服务被服务容器（如EJB 3.0和Spring）以不可见的方式在运行时提供给应用程序。开发人员（或系统管理员）通过配置来告诉容器什么时候，以怎样的方式来应用这些服务。

EJB 3.0通过JAVA注解的方式来配置声明式服务，Spring则通过XML配置文件来完成。大多数情况下，EJB 3.0 的注解方式是应用这种服务的更加简单和优美的方式。下面是一个在EJB 3.0中对一个POJO的方法使用事务管理服务的例子。

public class Foo {    @TransactionAttribute(TransactionAttributeType.REQUIRED)    public bar () {      // do something ...    }    }

你可以对一段代码声明多个属性，并应用多个服务。下面是一个对EJB 3.0中POJO类同时使用事务管理服务和安全服务的例子。

@SecurityDomain("other")public class Foo {    @RolesAllowed({"managers"})    @TransactionAttribute(TransactionAttributeType.REQUIRED)    public bar () {      // do something ...    }   }

使用XML指定代码属性和配置声明服务将导致冗长的和不桅顶的配置文件。下面是Spring应用中一个XML元素的例子，它用来在Foo.bar()方法上应用一个非常简单的Hibernate事务。

     
     


     
     
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">


     
     
      
      

      
      

      
      
      
      

      
      

     
     


     
     
      
      

      
      

      
      
      
      

      
      

     
     


     
     
      
      

      
      

      
      
      
      

      
      

     
     




     
     


     
     
class="org.springframework.orm.hibernate.HibernateTransactionManager">


     
     
      
      

      
      

      
      
      
      

      
      

      
      
      
      

      
      

     
     




     
     


     
     
class="org.springframework.transaction.interceptor.NameMatchTransactionAttributeSource">

XML文件的复杂程度将随着你对同一个POJO类增加的拦截器的数量成几何增长。意识到了仅使用XML配置文件的限制性，Spring支持在JAVA源代码中使用Apache Commons metadata来指定事物属性。在最新的Spring 1.2中，JDK 1.5风格的注释也被支持。为了使用事务元数据，你需要为上面例子中的AttributesTransactionAttributeSource 改变一个transactionAttributeSource bean，并且增加一个附加的对元数据拦截器的设置。

     
     
class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator"/>


     
     
class="org.springframework.transaction.interceptor.AttributesTransactionAttributeSource"

autowire="constructor"/>


     
     
class="org.springframework.transaction.interceptor.TransactionInterceptor"

autowire="byType"/>


     
     
class="org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisor"

autowire="constructor"/>


     
     
class="org.springframework.metadata.commons.CommonsAttributes"/>

当你有许多事务方法时，Spring元数据简化了transactionAttributeSource元素。但是它没有解决XML配置文件的根本问题：仍然需要冗长的、易错的事务拦截器，事务管理器和事务属性。

注射依赖

中间件容器的一个主要优点是它们使得程序开发人员可以去构建松耦合的应用程序。服务使用者仅仅需要知道服务接口就可以使用服务。容器把具体的服务实现实例化，然后将它们提供给服务使用者。这样，容器可以在可替换的服务实现之间进行切换，而不改变服务接口和服务使用者代码。

注射依赖模式是实现松耦合应用程序的一个最好的方式。比起以前的方式，如通过JNDI进行查找或回调容器，注射依赖模式更容易使用，而且更加优美。使用注射依赖模式，框架扮演了构建服务的对象工厂角色，然后根据运行时的配置，把这些服务对象注射到应用程序的POJO类中。从程序开发人员的角度看，作为客户端使用者的POJO在需要使用服务对象前就自动的得到了它们。

Spring 和 EJB 3.0都提供了大量的DI模式支持。但是，它们之间也有着根本的不同。Spring支持了通常意义上的但是复杂的基于XML配置文件的注射依赖API；EJB 3.0支持的注射大多数通用服务对象（如，EJB和容器对象）和JNDI对象，它通过简单的JAVA注解来完成。

EJB 3.0的注射注解相当的简洁易用。@Resource标签注射大多数的通过服务对象和JNDI对象。下面的例子显示了如何将JNDI提供的服务器缺省数据源对象注射给一个POJO的一个字段。DefaultDS是这个数据源的JNDI名字。myDb变量在第一次被使用前就自动被赋予了正确的值。

public class FooDao {

@Resource (name="DefaultDS")

DataSource myDb;

// Use myDb to get JDBC connection to the database

}

在EJB 3.0中，注释@Resource不仅可以直接注射给属性变量，它也可以通过setter方法来完成注射。下面的例子将一个session上下文对象通过setter方法注射给使用者。应用程序不用显示的调用setter方法，在任何其他方法被调用前容器将调用setter方法完成注射。

@Resource 

public void setSessionContext (SessionContext ctx) { 

sessionCtx = ctx; 

}

对于更复杂的服务对象，还有一些特殊的注射注解。例如，@EJB 注解被用来注射EJB stubs，@PersistenceContext注解被用来注射实体管理器对象，这些对象负责处理EJB 3.0实体Bean的数据访问操作。下面的例子给出如何将一个实体管理器注射到一个有状态Session Bean中。@PersistenceContext注解的类型属性描述了被注射的的实体管理器有一个扩展的事务容器：它不会随着JTA事务管理器自动提交事务，因此它可以应用在当session中有多次操作的应用事务管理时。

@Stateful

public class FooBean implements Foo, Serializable {

@PersistenceContext(

type=PersistenceContextType.EXTENDED

)

protected EntityManager em;

public Foo getFoo (Integer id) {

return (Foo) em.find(Foo.class, id);

}

}

EJB 3.0 规范定义了可以通过注解来被注射使用的服务器资源。但是，它不支持用户自定义的POJO类之间的相互注射。

在Spring中，为了将服务对象注射到你的POJO类中，你首先需要定义一个setter方法(或有参数的构造函数) 。下面的例子演示了POJO类中一个Hibernate session 工厂的属性。

public class FooDao {

HibernateTemplate hibernateTemplate;

public void setHibernateTemplate (HibernateTemplate ht) {

hibernateTemplate = ht;

}

// Use hibernateTemplate to access data via Hibernate

public Foo getFoo (Integer id) {

return (Foo) hibernateTemplate.load (Foo.class, id);

}

}

因此，你可以指定容器如何得到这个服务，并且在运行时通过配置文件中XML元素的连接关系把它提供给POJO。下面的例子显示了连接一个数据源到一个Hibernate session 工厂、session 工厂到Hibernate模板对象、模板对象最后到应用程序POJO类，整个过程的XML配置。

Spring 代码复杂性的部分原因是，我们需要手工的去注射Hibernate相关类，然而，EJB 3.0 实体管理器被服务器自动管理和配置。但是，这使我们返回到了这样的讨论：Spring 不象EJB 3.0 一样，它不同服务紧密整合在一起。




     
     
class="org.springframework.jndi.JndiObjectFactoryBean">


     
     
      
      

      
      

      
      java:comp/env/jdbc/MyDataSource
      
      

      
      

     
     




     
     
class="org.springframework.orm.hibernate.LocalSessionFactoryBean">


     
     
      
      

      
      

      
      
      
      

      
      

     
     




     
     
class="org.springframework.orm.hibernate.HibernateTemplate">

尽管Spring中基于XML的注射依赖比较复杂，但是它非常强大。你可以注射任何POJO到另外的POJO中，包括程序中自定义的。

如果你确实想在EJB 3.0应用中使用Spring的注射依赖功能，你可以将一个Spring Bean工厂类通过JNDI注射到一个EJB中。在某些EJB 3.0 应用服务器中，厂商可能会定义一些非标准的API用来注射任意的POJO类。一个很好的例子是JBoss MicroContainer，它处理了AOP依赖性，因此它是甚至比Spring 更加通用。

结论

尽管Spring 和EJB 3.0的目标都是提供企业服务，使得POJO可以松耦合，但是它们实现的方式非常不同。在两个框架中注射依赖模式都有大量的应用。

通过EJB 3.0的标准方式、大量应用的注解、还有同应用服务器紧密整合性，这些提供了更高的厂商无关性和开发人员工作效率。Spring的以XML为中心的配置文件和注射依赖的连贯使用，允许开发人员去构造更加灵活的应用系统，并且可以同时与多个应用服务提供者同时工作。