POJO应用框架：Spring Vs. EJB 3.0

核心提示：爱因斯坦曾经说：“任何事情都应该越简单越好，而不是比较简单，POJO应用框架：Spring Vs. EJB 3.0，”实际上，科学真理的目的就是在假设的前提下去简化一个理论，相反，这些服务被服务容器（如EJB 3.0和Spring）以不可见的方式在运行时提供给应用程序，这样，人们可以去关注真正重要的问题

　　爱因斯坦曾经说：“任何事情都应该越简单越好，而不是比较简单。”实际上，科学真理的目的就是在假设的前提下去简化一个理论，这样，人们可以去关注真正重要的问题。在企业软件开发中，道理是一样的。
　　
　　简化企业软件开发的一个要害是，提供一个这样的应用框架：它可以使开发人员不用关注于很多复杂的问题，比如事务处理、安全和持久化等。一个设计良好的框架将提升代码的可复用性，提高开发者的效率，并得到更高质量的软件。然而，目前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与EJB2.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）以不可见的方式在运行时提供给应用程序。开发人员（或系统治理员）通过配置来告诉容器什么时候，以怎样的方式来