OSGi 联盟已经发布了 Service Platform 规范 Release 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"/>

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

“osgi:service”元素来自 Spring DM，但 “bean” 元素来自核心 Spring Beans 模式。 如果没有定义组件的能力，那么基于 Spring DM 命名空间元素的标准几乎没有用处。 因此，RFC 124 是基于 Spring DM 命名空间元素和语义，以及 Spring 本身的核心：- beans 模式及其语义的标准。 在 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 Application Platform 目前支持基于 Spring DM 的编程模型，适用于那些希望利用其 OSGi 功能的人，当然会更新以包含 RI，从而为基于 OSGi 的企业应用程序提供基于标准的编程和配置模型。

企业专家组的下一次会议将在几周后举行，届时我们将继续完善规范。 计划在今年晚些时候为那些从事伴随规范的 RI 的人举办一个“编码训练营”。