经过数月的紧张编码，我很高兴地宣布 SpringSource 应用平台 1.0 的 Beta 版发布。

在 2007 年初，我们开始讨论企业 Java 已成为同义词的单片和重量级应用服务器的可能替代方案。客户正在寻找一个轻量级、模块化且灵活的平台，以满足他们的开发和部署需求。

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

我们着手构建 SpringSource 应用平台来满足这些需求并消除这些限制。

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

为了保持最小的运行时占用空间，OSGi 捆绑包由 DMK 配置子系统按需安装。这允许将应用程序安装到正在运行的平台中，并从外部存储库中满足其依赖项。这不仅消除了手动安装所有应用程序依赖项的需要（这将非常繁琐），而且还将内存使用量保持在最低限度。

DMK 本身需要一组最小的捆绑包才能运行，并使用 **配置文件** 进行配置，以精确控制加载的其他模块集。例如，DMK 不需要 Tomcat 存在，但默认平台配置文件包含 Tomcat 以允许部署 Web 应用。如果要运行没有 Tomcat 的平台，只需编辑配置文件，它就不会被安装。（如果您尝试这样做 - 请记住，删除 Web 支持意味着 Web 模块将不再部署，因此请删除 pickup 目录的内容，以便平台在启动时不会尝试安装 Admin 和启动画面应用程序。）安装了管理控制台的默认平台配置仅占用 15MB 的内存。

我一直对企业 Java 感到沮丧的一件事是，应用程序通常被塞进人为构建的孤岛中，并且缺乏对不同应用程序类型的明确支持。考虑一个在线商店的应用程序。此应用程序具有 Web 前端、消息驱动的订单处理模块、批处理驱动的库存重新排序模块和 B2B Web 服务模块。如今，许多这样的应用程序将被打包成 WAR 或 EAR，并且模块看起来非常相似，对模块类型之间的差异支持很少。有趣的是，许多人会将其称为 Web 应用程序，而不是具有 Web 模块的应用程序。

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

在 1.0 平台版本中，我们支持 **Web** 和 **Bundle** 个性，使您能够构建复杂的 Web 应用。以后的版本将包括对更多个性的支持，如下所述。

构建应用程序

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

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

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

任何符合 OSGi 标准的捆绑包都可以直接部署到平台中，并且可以充分利用对 Import-Package 和 Require-Bundle 引用的任何依赖项的即时配置。

PAR 格式是为平台打包和部署应用程序的推荐方法。PAR 只是一个标准 JAR 文件中组合在一起的 OSGi 捆绑包（模块）的集合，以及唯一标识应用程序的名称和版本。PAR 文件作为单个单元部署到平台中。平台将从 PAR 中提取所有模块并安装它们。第三方依赖项将根据需要即时安装。

与直接将捆绑包部署到平台相比，PAR 格式具有三个主要优点。首先，它更简单。一个中等规模的企业应用程序可能包含 12 个或更多捆绑包 - 手动部署这些捆绑包将过于繁琐。其次，PAR 文件在应用程序中的所有捆绑包周围形成一个明确的范围，从而防止使用重叠类型或服务的应用程序相互冲突。此范围还被一些高级功能（如加载时编织）使用，以确保一个应用程序的编织不会干扰另一个应用程序的编织。最后，PAR 形成一个逻辑分组，以定义哪些模块是应用程序的一部分以及应用程序具有哪些第三方依赖项。管理工具使用此分组来提供应用程序的详细视图。一个典型的 PAR 应用程序如下所示

应用程序中模块之间的依赖关系通常使用 Import-Package 和 Export-Package 表示。对第三方库的依赖关系可以用相同的方式表示，但对于许多库来说，这可能容易出错且耗时。当使用 Hibernate 等库时，您通常需要导入比最初预期的更多包。为了解决这个问题，您可以使用 Require-Bundle，但这有一些语义上的粗糙边缘，例如拆分包，其中逻辑包跨两个或多个类加载器拆分，导致运行时出现问题。平台引入了两种新的机制来引用第三方依赖项：Import-Bundle 和 Import-Libary。Import-Bundle 类似于 Require-Bundle，但它可以防止拆分包以及 Require-Bundle 的其他问题。Import-Library 提供了一种机制来引用一组捆绑包导出的所有包，例如 Spring 框架中的所有捆绑包，在一个声明中

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 捆绑包和 Spring 框架库。Spring 框架库包含在应用程序中使用 Spring 所需的所有捆绑包。

Import-Library 和 Import-Bundle 在底层扩展为 Import-Package，因此与标准 OSGi 语义一致。

平台了解模块的个性，并据此可以推断如何配置模块的执行环境。在部署 Web 模块时，为典型的 Spring MVC 应用程序创建所有所需的 servlet 基础结构，从而无需跨应用程序重新创建此样板代码。在 1.0 正式版中，将向 Web 模块个性添加更多智能，以支持 Spring Web Flow 等其他技术。

无论选择哪种打包格式，编程模型都只是 Spring 框架和 Spring 动态模块，其他 Spring 产品组合产品在其之上运行。

可服务性

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

为了帮助进行问题诊断，平台在日志和跟踪消息之间有很强的分离。日志消息旨在供最终用户使用，并允许您访问最重要的故障信息，而无需浏览数 GB 的跟踪内容。所有应用程序故障都将在日志输出中显示并编码 - 这些代码可以用作访问知识库或支持内容的便捷方式。为了理解为什么这如此有用，请考虑以下来自平台启动的输出

[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'

启动调用链中每个类型的内部工作细节的页面和页面输出消失了。相反，您得到的邮件确实有意义。当然，这并不意味着您无法了解每种类型在做什么：我们仍然维护一个广泛的跟踪。实际上，因为我们将最重要的日志消息与跟踪分离，所以我们的跟踪可以更详细，因为它打算阅读的频率较低。

平台中的严重故障会生成一个服务转储，可以将其传递给支持人员以帮助诊断过程。此转储包含来自平台中所有主要子系统的状态，并通过 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 实例 这里。