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