通过Spring与Java的对比，我看到Spring好于Java EE的一个强有力理由。如果Java EE被认为是用“方法”在Java平台上开发所有东西，那他们已经失败了。开发人员仍然在支持HibernateJPA容器中使用Hibernate注释,因为他们想要的特性并不是给他们提供Java持久化API(JPA)。或者说，并不是每个人都专注于编写JavaServer Faces(JSF)应用程序。新技术,如单页面的Javascript Web应用程序，将比Java EE（或者甚至是Spring）API发展得更快。

　　简而言之，开发人员必须愿意适应不断变化的特性、API和协议，并且他们不得被迫使用一个有限的工具集来编写，不管他们是否遵守官方Java EE社区路线。
 
　　答案对于是否使用一个特定的API或平台必须基于价值和开发人员所面临的情况。公平地说，在Spring第一部分中谈到的从Spring到Java EE的迁移，作者作出了同样的评论。我意识到偏见影响了我的选择，并拼命辩论所有选项的优点。

　　我们在设计未做过的应用程序或者升级已经存在的系统时都不能忘记这一点。然可以自行选择新建应用程序选项,使用或者不使用Java,通常这些选择都是由组成的开发团队和现有应用程序直接确定，而公司介于保守,坚持技术选择和处于前沿之间。

　　它会明智的保留由SpringBean创建的Spring模型-视图-控制器用户接口，从而在现有的应用程序上转移到Java EE的JSF和EJB上吗？直到迁移的影响安定下来，新设计会如何不稳定?在某些情况下，开发人员做出保留现有平台的选择,因为费用和应用程序稳定性风险不能弥补改变的风险。另一方面,当现有的平台过于臃肿而无法处理时，更激进的行动可能是必需的,那么我们也只能那么做了。

　　关于创新和选择

　　关于选择开源开发。它是关于创新的精英管理，而不是遵循一个公司的某种方式。如果有人使用一个比Spring更好，更灵活，更容易测试、配置和部署的Java EE平台，我希望能看到它。并且我可能使用它。

　　但当我看到Spring 和Java的对比时，有三个事实依然存在：Spring是不可或缺的，因为它提供了可以在任何Java平台上运行的代码，它将商业逻辑从企业平台抽象出来，并且不施加可怕数量级的复杂性给开发人员。

　　Spring社区不受限于多个供应商社区的流程，所以它能迅速转移并尝试新事物。有些时候这些尝试失败了：目击者试图建立一个基于OSGI的应用程序服务器。SpringSource dm 服务器是高度创新的,但是,在内部它是一个商业的失败品。Rod Johnson 谈到这个时公开承认，他们要么早点，要么赌一把,因为它还没有为市场做好准备。然而,这并未阻止SpringSource的尝试。事实上,公司捐赠dm 服务器代码库给Eclipse基金会,使它成为Eclipse处女项目,它到今天仍然还在开发。

　　SpringSource的另一个产品，到现在越来越流行，它就是tc服务器。这个服务器是大致和dm同时开发的。它已经成为VMware公司vFabric产品线的一个关键部分。

　　非java EE创新

　　SpringSource还构建了更进一步,抽象更复杂过程的API。他们的Spring集成API拥有构建模块,来构建企业服务总线或集成项目。组件是基于Gregor Hohpe的企业集成模式,并且可以配置在Java、Scala或XML中。

　　由SpringSource创建的另一个集成工具是Spring Batch，它试图处理分块数据的加载过程。批处理可以处理各种不同来源的数据，并且使用大量API来写那些数据。

　　SpringSource还购买了一个基于AMQP API、RabbitMQ和NoSQL数据库的非JMS队列工具，Redis。SpringSource开发人员正在构建一组数据管理的抽象，Spring Data API,来处理各种NoSQL和SQL数据库API,甚至实现NoSQL REST Data项目来处理RESTful网站，就好像是一个数据库一样。

　　所有这些API后面都不需要付费。它们全部都不需要开发者购买支持。开发团队可以自由下载它们,架设起来并在公司服务器上运行而不受任何惩罚。如果管理层想要支持，他们可以购买它。如果他们宁愿内部支持这些应用程序，团队仍然有完全访问源代码的权限。

　　相关文章：
　　Spring摘要：Spring框架仍然有重大作用
　　Java EE对比Spring：两者并非完全等效
　　Java新特性将使JDBC API更接近Spring