从获得一千万美元风投开始算起刚满一年，如今SpringSource（Spring框架背后的公司）摇身一变，成为应用服务器提供商，并且举着SpringSource应用平台（SpringSource Application Platform）的黄钺白旄对现有的Java EE服务器阵营发起挑战。SpringSource应用平台是构建在Spring、OSGi和Apache Tomcat之上的应用服务器，这个新的应用服务器摒弃了原有的Java EE服务器标准，自然而然地将Spring编程模型展现其中，随之而来的还有一套基于OSGi内核构建的全新部署和打包系统。今天是该项目在SpringSource评估许可下Beta发布版发布的重要里程碑。在随后一个月内会有基于开源许可（GPLv3）版本和订阅版本的通用发布版（General Availability，GA）放出。

SpringSource应用平台不是Java EE应用服务器。尽管对于WAR部署它提供了支持，但EAR部署和其它EE的规范，如EJB等，都不在支持范围之列。SpringSource应用平台被重新设计，并把关注点直接放在对被开源项目所广泛使用的Spring组合的支持上。特别地，这个应用服务器是基于Spring组合编程模型构建的，利用Spring Dynamic Module实现基于OSGi的部署。SpringSource在Eclipse基金会的Equinox OSGi运行时环境的基础上创建了一个具备日志、跟踪、启动、类加载、管理和其它特性的“内核”，Tomcat被作为一个包（bundle）纳入到平台当中，从而实现对Web功能的支持。

InfoQ借此机会对Spring框架的共同创始人兼SpringSource的CEO Rod Johnson进行一次采访，对这个新的应用服务器展开探讨。在阐释这个新平台的必要性时，Rod一针见血地指向目前开发和生产环境的许多痛处，比如跨配置文件出现的元数据重复现象，还有本质上在项目中常常在服务器上再部署服务器（即在部署应用时，在同一个部署单元附带部署许多工具和框架），而与此同时这些部件却主要只使用它们应用服务器中的Web容器部分的事实。因此，SpringSource希望在当今的开发需要的基础上提供一个更为简单的平台。

在谈到这个新应用服务器的优点时，Johnson强调了模块化：对于服务器本身以及提供给开发人员的打包和部署模式来说，这是个两全之策。通过利用OSGi，以及OSGi包之间依赖关系相互作用的性质，运行的应用服务器只会激活在它上面运行的应用所需要的特性，从而削减服务器的内存占用和启动时间。这个依赖关系支持的功能还允许依赖类库的多个版本共存，以支持不同应用；因而应用服务器的某些部分就可以很容易地更新和重启，而无需重启整个服务器。从开发的角度看，服务器的模块化也使得在代码变化时，可以很快地进行极其细粒度的重部署。

Johnson在言及OSGi和SpringSource对Eclipse Equinox OSGi的使用时，高度评价了OSGi规范的运行时实现所带来的基础平台，但也表示OSGi在日常的应用开发上属于比较底层的地位。Johnson阐述到，SpringSource希望帮助开发人员在企业环境中轻松获得价值。在新的编程模式的构造背后，这个新的应用服务器将OSGi的许多复杂性抽象了出来。Johnson接着说，应用服务器将会支持PAR，一套新的可部署单元，简化企业应用在使用OSGi上的复杂性（下文会详细说明）。

当被问到对于没有对OSGi提供原生支持的遗留类库的支持时，Johnson回应到，他们已经在上面花费了很大心血，使得应用服务器环境和类加载功能能够以兼容的方式和遗留类库协作。

当被问到对不提供OSGi原生支持的类库的遗留支持时，Johnson回答说他们已经在这方面投入了大量精力，保证应用服务器环境和类加载功能可以和遗留类库兼容工作。SpringSource还会为他们在如Tomcat之类的项目上所做的任何变更给这些项目提交补丁，使这些类库可以和OSGi包兼容。

Johnson解释到，应用服务器的主题代码将在GPL v3的许可证下发布。开发人员在服务器、编程模式和部署单元上要接触到的所有部分都会以开源的形式提供。SpringSource还将提供应用服务器的商业版本，包括支持、保障、管理和监控的功能。

谈到Spring应用平台发布之后对Spring组合继续支持JavaEE有什么影响，Johnson回答说：

……我们从根本上说并不打算把Spring用户社区驱赶到任何方向。我们仅仅是给用户另一种选择。Spring的哲学是用户总是正确的。用户是聪明的，他们完全明白自己的需要。不管用户是否选择SpringSource应用平台，我们觉得用户总会欢迎多一点选择的……

Johnson保证SpringSource一定会继续确保Spring组合以及其他SpringSource产品兼容于其它应用平台。接着Johnson还评论了即将到来的Java EE 6规范：

Java EE 6重点在模块性，这个方向是正确的。很可能SpringSource应用服务器会在一定程度上符合Java EE 6。Java EE 6分成A、B、C三种规格（profile）。我们几乎肯定会实现A和B规格，C规格里面我非常确定将实现Entity Beans 1.1模型以及一些遗留技术。我还不能说是100%确定，因为Java EE 6规范还没有定案。

最后，InfoQ和Johnson讨论到了SpringSource应用平台的大局方面。对于转换到OSGi，他的回答是：

传统的应用服务器模型正逐渐过时。BEA和IBM正在用OSGi逐步重新实现他们的应用服务器。 SpringSource现在就提供OSGi支持。从统计数字上看，大多数人都不会部署到完整的平台上，他们部署到Tomcat。他们选择了Spring 编程模型而非Java EE。市场已经作出了选择，问题只是开发者还要和服务器斗争多长时间。

Johnson解释说他对SpringSource应用平台成功的自信来自三个原因：

• 它是第一个建立在现代技术基础上的产品。符合Java EE规范已经不是至高无上的目标。干净的代码基础是我们的一项竞争优势。我们在设计和实现中满足的是现今的需求，而不是10年前的需求。
• POJO编程是现在行业的方向所在。过去POJO编程是被强行嫁接到其它产品上的。在我们的产品中，POJO编程是设计的前提。
• SpringSource应用平台采用的OSGi技术是下一代技术的基础。

除了Rod Johnson，InfoQ还与SpringSource的Rob Harrop探讨了新应用服务器的一些技术细节。对于与传统Java EE应用服务器相比有何增减，他说：

……JPA和JMS都支持，但我们没有包含任何特定实现。对于JPA，我们支持Hibernate、 OpenJPA和Toplink。我们在OSGi环境中增加了对加载时织入的支持，而且会尊重应用的边界，因此不会意外污染应用间共享的库。不包括 JNDI，我们用OSGi Service Registry来取代它。Servlets是通过内嵌的Tomcat来支持的。JEE中有而SpringSource应用平台没有的东西包括 Entity Beans等等。

接下来InfoQ问到Spring Dynamic Modules。Spring DM成为公开项目已经有一段时间了。对于模块化部署，我们向Harrop询问Spring DM是否增加了什么新东西：

这个平台引入了应用的概念，应用由一个或多个Bundle组成。应用中的包有明确的作用域，可以防止发生应用间的冲突。在应用把服务发布到OSGi service registry的情况下，防止冲突尤其重要，谁也不想见到服务之间发生冲突。

我们引入了Import-Library语句，因此在应用中使用第三方库变得更加简单。你不需要再写一大串不直观的 Import-Package声明，Import-Library可以自动为指定的库引入所有必需的package。像Hibernate JPA这样的库还可以跨多个Bundle，可见Import-Library确实物有所值。

至于为了让Spring DM在平台中运行而进行的扩展，为数不多。

Harrop接下来说明了新的PAR格式：

Spring DM掌控下的Bundle（Spring DM powered bundles）是包含META-INF/spring/*.xml文件的普通OSG Bundle。Bundle启动的时候META-INF/spring/*.xml文件会自动成为该Bundle的 ApplicationContext。Spring DM提供了一种机制让各Bundle通过Spring NamespaceHandler导入和导出服务。

一个PAR（Platform ARchive）本质上是一组OSGi Bundle，通常其中有一部分是在Spring DM掌控下的。这些Bundle共同组成了一个逻辑上的应用。编程的时候完全是纯粹的OSGi、Spring和Spring DM——PAR没有改变什么。

以前一般用Buddy Classloaders之类的技术来解决遗留/非OSGi库的问题，SpringSource这次是怎么做的呢？Rob回答说：

简单来说我们避免做这样的事。Buddy类装载、动态import、require-bundle，这些我们都明确回避，因为维持一致的类空间太困难了。我们也不会提供任何专有的替代机制。

相反，我们给Equinox增加了一些低级的钩子，以实现典型的场景下的资源装载。我们扩展了类装载来支持加载时织入，并且把装载语义丢到一边。我们操纵context classloader，让第三方一如既往地看到类。PAR是其中的核心角色，因为它定义了上下文类装载以及加载时织入的可见范围。

对于一些最糟糕的情况，我们会提供修补版的库，让它们能在OSGi中工作。修补版的库可以通过SpringSource Enterprise Bundle Repository获得，我们的修改也会提交回相应的项目。

最后Harrrop着重强调了这个应用服务器在模块化上的优势，应用服务器因此可以维持最低的内存占用。平台在运行中才设置依赖项，因此只有确实用到的依赖项才会被装载。

最近几年中有过许多关于Java EE标准是否已经死亡的讨论，而今天我们看到一个可能很重要的应用服务器不带Java EE支持。这种变化对于未来有何影响？你怎么看？