经过数月紧张的编码，我很高兴地宣布 SpringSource Application Platform 1.0 的 beta 版本发布。

2007 年初，我们开始讨论替代单体式、重量级应用程序服务器的可能方案，企业 Java 已与这些服务器形影不离。客户正在寻找一个轻量级、模块化且足够灵活的平台，以满足其开发和部署需求。

Spring 和 Tomcat 的组合表明，开发人员和运维人员可以在生产环境中成功使用一个轻量级的平台。尽管这种组合取得了成功，但缺乏模块化和对非 Web 应用程序的显式支持限制了其适用性和灵活性。

我们着手构建 SpringSource Application Platform 以满足这些需求并消除这些限制。

Platform 的核心是 Dynamic Module Kernel (DMK)。DMK 是一个基于 OSGi 的内核，充分利用了 OSGi 平台的模块化和版本控制功能。DMK 基于 Equinox 并扩展了其在配置和库管理方面的功能，同时为 Platform 提供了核心功能。

为了保持最小的运行时占用空间，OSGi bundle 由 DMK 配置子系统按需安装。这使得应用程序可以安装到运行中的 Platform 中，并且其依赖项可以从外部存储库中满足。这不仅消除了手动安装所有应用程序依赖项的繁琐工作，而且最大限度地减少了内存使用。

DMK 本身需要一套最小的 bundle 来运行，并通过一个 **profile** 进行配置，以精确控制加载的附加模块集。例如，DMK 不需要 Tomcat，但默认的 Platform profile 包含 Tomcat 以允许部署 Web 应用程序。如果您想在没有 Tomcat 的情况下运行 Platform，只需编辑 profile 即可，它就不会被安装。（如果您尝试这样做，请记住，删除 Web 支持意味着 Web 模块将不再部署，因此请删除 pickup 目录中的内容，以免 Platform 在启动时尝试安装 Admin 和 splash 屏幕应用程序。）默认的 Platform 配置（安装了管理控制台）仅占用 15MB 内存。

我对企业 Java 的一个长期不满是，应用程序经常被塞进牵强的孤岛，并且缺乏对不同应用程序类型的显式支持。考虑一个在线商店的应用程序。该应用程序有一个 Web 前端、一个消息驱动的订单处理模块、一个批处理驱动的库存重新排序模块和一个 B2B Web 服务模块。如今，许多此类应用程序将被打包成 WAR 或 EAR，并且模块将非常相似，对模块类型差异的支持很少。有趣的是，许多人会将此称为 Web 应用程序，而不是带有 Web 模块的应用程序。

在 SpringSource Application Platform 中，应用程序是模块化的，每个模块都有一个 **personality**，用于描述它是什么类型的模块：Web、批处理、Web 服务等。Platform 以特定于 personality 的方式部署每个 personality 的模块。例如，Web 模块在 Tomcat 中使用 Web 上下文进行配置。应用程序中的每个模块都可以独立于其他模块进行更新，同时保持作为大型应用程序一部分的身份。无论您构建哪种类型的应用程序，编程模型仍然是标准的 Spring 和 Spring DM。

在 1.0 Platform 版本中，我们支持 **web** 和 **bundle** personality，这使您能够构建复杂的 Web 应用程序。未来的版本将根据后续详述包含对更多 personality 的支持。

构建应用程序

Platform 支持三种形式的应用程序打包

1. Java EE WAR
2. 原始 OSGi bundle
3. 平台归档 (PAR)

Platform 直接支持标准的 WAR 文件。在部署时，WAR 文件将被转换为 OSGi bundle 并安装到 Tomcat 中。所有标准的 WAR 合约都得到遵守，您现有的 WAR 文件应该可以直接部署而无需更改。

任何符合 OSGi 标准的 bundle 都可以直接部署到 Platform 中，并可以充分利用对 `Import-Package` 和 `Require-Bundle` 所引用的任何依赖项进行的即时配置。

PAR 格式是为 Platform 打包和部署应用程序的推荐方法。PAR 只是一个 OSGi bundle（模块）的集合，这些 bundle 被分组到一个标准的 JAR 文件中，并带有一个唯一标识应用程序的名称和版本。PAR 文件作为单个单元部署到 Platform。Platform 将提取 PAR 中的所有模块并进行安装。第三方依赖项将根据需要即时安装。

与直接将 bundle 部署到 Platform 相比，PAR 格式有三个主要优势。首先，它更简单。一个中等规模的企业应用程序可能包含 12 个以上的 bundle - 手动部署这些 bundle 将非常繁琐。其次，PAR 文件为应用程序中的所有 bundle 形成了一个显式的范围，防止使用重叠类型或服务的应用程序之间发生冲突。此范围还用于一些高级功能，例如加载时织入，以确保一个应用程序的织入不会干扰另一个应用程序的织入。最后，PAR 形成了一个逻辑分组，用于定义哪些模块是应用程序的一部分以及应用程序有哪些第三方依赖项。此分组由管理工具用于提供应用程序的详细视图。典型的 PAR 应用程序如下所示：

应用程序中模块之间的依赖关系通常使用 Import-Package 和 Export-Package 来表示。对第三方库的依赖关系也可以用同样的方式来表达，但对于许多库来说，这可能既容易出错又耗时。在使用 Hibernate 等库时，您通常需要导入比最初预期的更多的包。为了解决这个问题，您可以使用 Require-Bundle，但它存在一些语义上的不足之处，例如拆分包，即一个逻辑包被拆分到两个或多个类加载器中，这会在运行时导致问题。该平台引入了两种新的机制来引用第三方依赖项：Import-Bundle 和 Import-Libary。 Import-Bundle 类似于 Require-Bundle，但它能避免拆分包以及 Require-Bundle 的其他问题。Import-Library 提供了一种机制，可以在单个声明中引用一组包所导出的所有包，例如 Spring Framework 中的所有包。

Bundle-SymbolicName: com.myapp.dao.jdbc
Bundle-Version: 1.0.0
Import-Bundle: org.apache.commons.dbcp;version="1.2.2.osgi"
Import-Library: org.springframework.spring;version="2.5.4.A"

在这里，我有一个依赖于 Commons DBCP bundle 和 Spring Framework 库的模块 bundle。Spring Framework 库包含使用 Spring 在应用程序中所需的所有 bundle。

`Import-Library` 和 `Import-Bundle` 在后台会展开为 `Import-Package`，因此与标准的 OSGi 语义一致。

Platform 理解模块的 personality，并能从中推断出如何配置模块的执行环境。在部署 Web 模块时，典型的 Spring MVC 应用程序所需的所有 Servlet 基础设施都会自动创建，从而无需在应用程序中重新创建这些样板代码。在 1.0 最终发布版中，将为 Web 模块 personality 添加更多智能功能，以支持 Spring Web Flow 等其他技术。

无论您选择哪种打包格式，编程模型都只是 Spring Framework 和 Spring Dynamic Modules，其他 Spring Portfolio 产品运行在其之上。

可服务性

可服务性是整个工程团队的关键考虑因素。我们花费了大量时间来研究日志消息的格式和堆栈跟踪的大小，以确保诊断应用程序问题尽可能容易。每当发现一项重复且耗时的任务时，我们都会寻找一种方法来自动化它或完全消除它。

为了帮助诊断问题，Platform 在日志和跟踪消息之间进行了严格的划分。日志消息旨在供最终用户使用，让您无需筛选大量跟踪内容即可获取最重要的失败信息。所有应用程序故障都会显示并编码在日志输出中 - 代码可方便地用于访问知识库或支持内容。为了理解这一点为何如此有用，请考虑以下 Platform 启动输出：

[2008-04-29 12:12:01.124] main                     <SPKB0001I> Platform starting.
[2008-04-29 12:12:04.037] main                     <SPKE0000I> Boot subsystems installed.
[2008-04-29 12:12:06.013] main                     <SPKE0001I> Base subsystems installed.
[2008-04-29 12:12:07.396] platform-dm-1            <SPPM0000I> Installing profile 'web'.
[2008-04-29 12:12:07.674] platform-dm-1            <SPPM0001I> Installed profile 'web'.
[2008-04-29 12:12:07.721] platform-dm-14           <SPSC0000I> Creating ServletContainer on port 8080
[2008-04-29 12:12:08.036] platform-dm-10           <SPPM0002I> Platform open for business with profile 'web'.
[2008-04-29 12:12:09.405] fs-watcher               <SPSC1000I> Creating web application '/admin'
[2008-04-29 12:12:09.652] async-delivery-thread-1  <SPSC1001I> Deploying web application '/admin'

用于详细说明启动调用链中每个类型内部工作原理的冗长输出页面已成为过去。取而代之的是，您将收到真正有意义的消息。当然，这并不意味着您无法了解每个类型的作用：我们仍然维护着一个详尽的跟踪。事实上，由于我们将最重要的日志消息从跟踪中分离出来，我们的跟踪可以更详细，因为它intended to be read less often（阅读频率较低）。

平台中的严重故障会生成一个服务转储，可以将其提供给支持人员以协助诊断过程。此转储包含平台中所有主要子系统aneous的状态，并通过 AspectJ 进行钩接，以确保我们捕获到可以引发未检查异常的每一个可能的站点。

平台还会主动监控 JVM 中的问题并触发转储。在 1.0 版本中，这仅限于死锁监控，但在未来的版本中将包含内存、锁争用和 CPU 争用。

路线图

此 Beta 版仅是 SpringSource Application Platform 的起点。我们已初步确定了 2.0 版本的路线图，重点关注五个主要领域：管理控制台、中间件集成、附加功能、集群和 DMK 2.0。

通过管理控制台，我们希望充分利用平台所拥有的所有应用程序知识，并将其提供给最终用户。管理控制台将允许从模块级别一直到 Bean 级别对应用程序进行详细检查。应用程序将与其依赖的库和捆绑包相关联，管理控制台将能够动态升级这些库。通过理解应用程序所包含的不同类型的 Bean，管理控制台将提供对应用程序内部的详细洞察，并允许对某些应用程序组件进行动态重新配置。

为了支持典型的企业部署场景，2.0 版的平台将为 Oracle、TIBCO EMS 和 IBM MQSeries 等常见的企业中间件组件提供显式支持。与管理控制台的集成将允许在几分钟内而不是几小时或几天内建立与这些中间件提供商的连接。应用程序将能够使用 OSGi 服务注册表和 Spring DM 的 <osgi:reference> 来访问这些连接。

2.0 版本将引入额外的功能来覆盖批处理、Web 服务和 SOA 应用程序。

集群是 2.0 版本的重要功能，其中集群范围的单一系统映像 (SSI) 是关键部分，负载平衡和集群缓存也在路线图上。通过 SSI 支持，管理和部署操作将传播到整个集群。最终，我们希望支持跨集群的每个模块更新，如果升级破坏了已部署的应用程序，则进行完整的集群回滚。

DMK 2.0 将改进并发子系统，以支持大量频繁更改的捆绑包，并支持更多具有更复杂相互依赖关系的模块。还将包括对供应子系统的更新以及内存、线程、IO 和 CPU 的集成资源管理和监控。

下一步是什么？

请下载该平台并试用。我们非常希望听到您在构建新应用程序和部署现有应用程序方面的经验。欢迎所有反馈，无论积极还是消极。我们特别希望听听如何让构建和部署应用程序的过程变得更轻松、更愉快。

二进制版本和论坛可以在此处找到。用户指南和程序员指南都可以在线获取。我们已在此处设置了 JIRA 实例。