OSGi联盟已发布服务平台规范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定义）并在OSGi服务注册表中以SomeInterface接口公开它。

“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 Application Platform目前为希望利用其OSGi功能的用户提供基于Spring DM的编程模型，当然会更新以包含RI，从而为基于OSGi的企业应用程序提供基于标准的编程和配置模型。

企业专家组的下一次会议将在几周后举行，届时我们将继续完善规范。今年晚些时候将安排一个“编码营”，供那些致力于规范配套RI的人员参加。