SpringSource 新应用服务器发布 摒弃 Java EE

从获得一千万美元风投开始算起刚满一年，如今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 支持。这种变化对于未来有何影响？你怎么看？

查看英文原文： SpringSource Launches New Application Server without Java EE