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 的人舉辦一個“編碼訓練營”。