OSGi Alliance 发布了 服务平台规范 4.2 版的早期草案。 SpringSource 员工是联盟内核心平台专家组 (CPEG) 和企业专家组 (EEG) 的积极成员。我个人主要参与 EEG，特别是 RFC 124“OSGi 的组件模型”。

RFC 124 是 Spring Dynamic Modules 核心思想的标准化。如果你查看配置模式，你会发现它与 Spring Dynamic Modules (DM) 提供的“osgi”命名空间非常相似。RFC 124 汇集了我们在过去几年开发 Spring DM 的经验，并结合了核心和企业专家组其他成员的一些关键见解，从而产生了一个既基于真实世界经验又与 OSGi 服务平台本身紧密集成的规范。非常感谢 Spring DM 开发团队：- Costin Leau、Oracle 的 Hal Hildebrand 和 BEA（现为 Oracle）的 Andy Piper，感谢他们在帮助开发和测试 Spring DM 以及随后帮助我们推动该模型作为 OSGi 服务平台标准化基础方面所做的辛勤工作。

试图标准化 Spring DM 会带来一个有趣的难题。在 Spring DM 中，定义组件并将其作为服务公开到服务注册表中很容易。例如

<bean id="myBean" class="com.xyz.SomeClass">

<osgi:service ref="myBean" interface="org.xyz.SomeInterface"/>

定义了一个名为“myBean”的 bean（只是一个普通的 Spring bean 定义），并将其在 SomeInterface 接口下的 OSGi 服务注册表中公开。

“osgi:service”元素来自 Spring DM，但“bean”元素来自核心 Spring Beans 模式。一个基于 Spring DM 命名空间元素但无法定义它们所引用组件的标准将毫无用处。因此，RFC 124 是一个基于 Spring DM 命名空间元素和语义以及 Spring 本身核心（即 bean 模式及其语义）的标准。在 RFC 124 中，组件是使用“component”元素定义的，但除了将 bean 改名为 component 之外，你会发现属性和语义都非常熟悉。

以下是基于 RFC 124 的相同组件和服务注册的标准化定义

<component id="myComponent" class="com.xyz.SomeClass">

<service ref="myComponent" interface="org.xyz.SomeInterface"/>

这对 Spring DM 意味着什么？随着标准尘埃落定（某些领域仍有工作要做），我们将在 Spring DM 中实现 RFC 124 的 RI（就 Spring 和 Spring DM 而言，它“只是另一个命名空间”，我们可以轻松地将其映射到现有功能）。SpringSource 应用程序平台目前支持基于 Spring DM 的编程模型，供那些希望利用其 OSGi 功能的人使用，当然也会更新以包含 RI，为基于 OSGi 的企业应用程序提供基于标准的编程和配置模型。

企业专家组的下一次会议将在几周后举行，届时我们将继续完善该规范。为规范提供 RI 的“编码训练营”计划于今年晚些时候举行。