从获得一千万美元风投开始算起刚满一年，如今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还将提供应用服务器的商业版本，包括支持、保障、管理和监控的功能。