InfoQ 有一個討論串，總結了對 SpringSource 應用程式平台發布的反應。Michael Burke 在該討論串中提出了一個很好的問題，可以轉述為「忘記圍繞 OSGi 的炒作，如果我將目前封裝為 EAR 的應用程式移植到 OSGi 捆綁包，我期望看到什麼好處？」。

我開始在 InfoQ 討論串上回答這個問題，但我的答案對於評論來說太長了，所以我在這裡解決它。

這個問題很好。基於 OSGi 的應用程式與傳統的基於 JEE EAR 的應用程式的主要區別在於模組化程度的提高。因此，問題變為，這種改進的模組化是否給我帶來任何好處，如果有的話，它們是什麼？書「設計規則，模組化的力量」對這個問題進行了非常透徹的處理。這是一個很好的背景，但我感覺 Michael 可能正在尋找比您在書中找到的更少一些理論的東西……

SpringSource 應用程式平台的主要優勢之一是其按需配置相依性的能力。這樣做的好處有兩個：它確保平台的記憶體佔用空間盡可能小，並且允許部署應用程式，而無需將其所有相依性封裝在單一的部署單元中，例如 WAR 檔案。為了利用這些功能，您需要了解平台的配置儲存庫，而這個部落格旨在提供這些資訊。

配置儲存庫在哪裡，它是如何運作的？

• ext 包含平台提供的但不是平台本身一部分的外部相依性。
• subsystems 包含構成平台的所有子系統。
• usr 最初是空的，旨在包含使用者新增的相依性，即您的應用程式所依賴的但平台尚未提供的任何內容。

執行階段配置

當平台啟動已部署的應用程式時，它的…

很高興聽到這麼多關於SpringSource 應用程式平台的討論，無論是在線上還是在 JavaOne 的現場。其中一個最有見地的評論來自 WebSphere 交易架構師 Ian Robinson

這會影響 WebSphere 嗎？好吧，核心 Spring Framework 中沒有任何改變。無論 SpringSource 應用程式平台的未來如何，核心 Spring Framework 專案仍然是 WebSphere 的補充。就像炸魚薯條一樣。

SpringSource 應用程式平台由 OSGi 捆綁包建構而成，並支援也由 OSGi 捆綁包建構的應用程式。平台支援 OSGi 的標準功能，但它也支援一些額外的 manifest header。有人問 為什麼 SpringSource 要新增專有 header？ 和 新 header 的語意是什麼？，因此本文解釋了 Import-Library 和 Import-Bundle 的背景動機和語意。

標準 OSGi 捆綁包支援

因此，精通 OSGi 的開發人員可以使用該平台作為標準 OSGi 容器，並受益於平台功能，例如

• 能夠使用管理控制台或透過將捆綁包放在平台的 pickup 目錄中來部署捆綁包，
• 診斷，例如解析失敗診斷、應用程式特定追蹤和自動死鎖偵測，
• 與 Spring 和 Spring Dynamic Modules 的強大整合，適用於想要使用這些框架的開發人員，以及
• 從儲存庫自動配置相依性。

企業應用程式的其他要求

嗯，流程中的某些步驟相對容易，特別是如果遵循了良好的軟體工程實務，並且代碼已組織成服務、網域和基礎結構元件。這些元件可以轉換為捆綁包，並且它們之間的相依性可以使用 META-INF/MANIFEST.MF 中的標準 OSGi Import-Package 和 Export-Package header 來表達。

一個更困難的步驟是表達對企業框架（例如 Spring 和 Hibernate）的相依性。完全可以使用標準 OSGi Import-Package 和 Require-Bundle header 來表達這些相依性，如果您想要建立將在其他 OSGi 容器中運行的 OSGi 捆綁包，這正是您應該做的事情，但這種方法有一些隱藏的成本。

首先，開發人員必須準確地決定哪些套件構成給定的框架。僅僅匯入應用程式代碼使用的套件是不夠的，因為當應用程式載入時，一些企業框架會將更多相依性編織到應用程式的位元組碼中。開發人員必須發現（可能透過反覆試驗）要匯入哪些額外的實作套件，以確保編織應用程式的正確行為。

然後還有從一個框架版本遷移到下一個版本的繁瑣工作，其中構成框架的確切套件集已更改。編織所需的其他套件通常不由公共合約定義，因此可能會更改。

此外，產生的套件匯入不能正確地捕獲設計意圖，這使得將來維護或擴展應用程式更加困難。

我們真的不想將這些負擔強加給我們的使用者，因此我們建立了一些額外的 SpringSource 應用程式平台特定的 manifest header、Import-Library 和 Import-Bundle，作為表達對企業框架的相依性的便捷方式。正如您將在下面看到的，這些 header 實際上只是 語法糖，以標準 OSGi 套件匯入的形式表達。

Import-Library

    Import-Library: <librarySymbolicName>;version=<versionRange>

如果您不熟悉 OSGi 版本範圍表示法，則最常用的形式是最小版本範圍，例如 2，表示 版本 2 或更高版本，以及 半開 範圍，例如 [2.2.1,2.2.2)，表示介於 2.2.1（含）和 2.2.2（不含）之間的任何版本。如果省略了 version=<versionRange> 以及分號分隔符，則預設範圍包括所有版本。

對於每個程式庫匯入，平台會選取具有指定符號名稱，且版本在指定版本範圍內，且位於平台儲存庫中之最高版本的程式庫。然後，平台會將程式庫匯入替換為一組套件匯入，這些套件匯入符合程式庫套件組所匯出的所有套件。平台會偵測到一個套件組匯入兩個或多個匯出共同套件的程式庫的情況，發出適當的日誌訊息，並且無法安裝匯入套件組。

因此，舉例來說，以下標頭匯入 2.5.4（含）到 2.5.5（不含）之間某個版本的 Spring Framework 程式庫。

    Import-Library: org.springframework.spring;version="[2.5.4,2.5.5)"

可選的程式庫匯入

    Import-Library: <librarySymbolicName>;version=<versionRange>;resolution:=optional

如果未指定 resolution，或指定為 mandatory，則如果沒有具有指定符號名稱且版本在指定範圍內的程式庫，則包含匯入程式庫標頭的套件組將無法安裝。但是，如果指定了 resolution:=optional，則如果沒有合適的程式庫可用，則將忽略程式庫匯入。

因此，舉例來說，以下標頭匯入從 2.5 開始的 Spring Framework 程式庫的某個版本，但如果沒有合適的程式庫可用，則會被忽略。

    Import-Library: org.springframework.spring;version="2.5";resolution:=optional

匯入多個程式庫

    Import-Library: org.foo.p;version="[1,2)",org.bar.q;version="[2,3)"

Import-Bundle（匯入套件組）

正如您所期望的那樣，對於每個匯入的套件組，平台會選取具有指定符號名稱，且版本在指定版本範圍內，且位於平台儲存庫中之最高版本的套件組。然後，平台會將套件組匯入替換為一組套件匯入，這些套件匯入符合套件組所匯出的套件。

因此，舉例來說，以下標頭匯入 Hibernate 物件關係對應器套件組。

    Import-Bundle: com.springsource.org.hibernate;version="[3.2.6,3.2.7)"

為什麼不重載 Require-Bundle？

好吧，我們希望 Require-Bundle 保留其標準語意，包括將分割套件的各個部分結合在一起的能力。但是我們希望 Import-Library 和 Import-Bundle 具有與 Import-Package 相同的底層語意，從而避免分割套件的複雜性。

我們也預期，隨著平台隨時間的推移而發展，我們需要向 Import-Library 和 Import-Bundle 添加更多指令，這些指令不適合添加到 Require-Bundle。

下一步是什麼？

對於想要利用平台標頭，但需要產生可在其他 OSGi 容器上運行的套件組的使用者，我們計劃製作一個工具，該工具將替換 Import-Library 和 Import-Bundle…

自從我們上週三發布 SpringSource 應用程式平台以來，許多開發人員已經下載了 1.0.0 beta 版，並開始對平台進行測試。因此，人們開始問：“我如何在平台上部署我的應用程式，以及我有什麼樣的部署和封裝選項？”此外，開發人員迫切要求看到可運作的範例。作為回應，S2AP 團隊將在未來幾週發布幾個範例應用程式，展示這些功能等等，但在您親自體驗這些範例之前，我想先給您一個概括性的…

很多人都在問，SpringSource 應用程式平台究竟為 Spring 應用程式做了什麼，使其在 OSGi 下運作良好，遠遠超出您可以使用 OSGi 和 Spring Dynamic Modules 開箱即用的功能。Adrian 昨天的文章強調了一些總體問題，現在讓我們看看一些細節。

在 OSGi 上執行 Spring 應用程式的三個最具挑戰性的方面是

• 載入時織入
• 類別路徑掃描
• 執行緒上下文類別載入器管理

剩餘的但不太有趣的問題包括：JSP 支援、TLD 掃描、註解匹配和資源查找。總體而言，需要解決一組相當大的問題才能使應用程式順利部署。

載入時織入

載入時織入是在穩健的方式下支援的最有問題的功能之一。在基本層面上，它需要掛鉤到 Equinox ClassLoader，以便可以在 defineClass 呼叫期間附加和使用標準 ClassFileTransformers。在此之上，LTW 的許多用途需要存取一個拋棄型的 ClassLoader，該 ClassLoader 可用於檢查類型以確定在織入期間需要發生什麼，而不會影響真正的 ClassLoader。

這種基本層面的支援實際上相當簡單。困難之處在於織入是由一個套件組中的類別驅動，但另一個套件組中的類別需要被織入。這在企業應用程式中非常常見，其中一個套件組包含網域實體，另一個套件組包含使用 JPA EntityManager 的類型。平台透過確保應用程式中的所有套件組都可以使用適當的 ClassFileTransformers 進行織入來處理此複雜性。

當您開始將織入傳播到其他套件組時，您真的需要知道何時停止。如果您只是將織入應用於所有套件組，那麼應用程式將相互干擾。平台透過明確限制織入的範圍，使其僅適用於應用程式中的模組，從而避免了這種情況。

LTW 的另一個問題是它使刷新變得複雜。當一個套件組被刷新時，OSGi 將刷新所有依賴於它的套件組。這意味著，在我上面給出的例子中，刷新網域套件組將導致 EntityManager 套件組被刷新。但是，刷新 EntityManager 不會刷新網域套件組，這意味著織入可能不同步。平台透過將刷新傳播到受織入影響的其他套件組來處理此問題。

類別路徑掃描

對於類別路徑掃描，主要問題是 Equinox 不公開標準 jar: 和 file: 資源。平台在中間放置一個適配器，以便程式庫看到它們期望的資源協定。這有一個很好的副作用，就是使許多第三方程式庫能夠正常工作 - 這不僅僅是一個用於類別路徑掃描的修復程式。

執行緒上下文類別載入器管理

許多第三方程式庫使用執行緒上下文 ClassLoader 來存取應用程式類型和資源。OSGi 中的每個套件組都有自己的 ClassLoader，因此，在任何時候只能將一個套件組公開為執行緒上下文 ClassLoader。這意味著，如果第三方程式庫需要看到分佈在多個套件組中的類型，它將無法按預期工作。

平台透過創建一個 ClassLoader 來解決此問題，該 ClassLoader 匯入您的應用程式中每個模組的所有匯出套件。然後，將此 ClassLoader 公開為執行緒上下文 ClassLoader，使第三方程式庫能夠看到您的應用程式中的所有匯出類型。

這只是平台解決的一小部分問題，但希望它能讓您了解平台對 Spring Framework 使用者意味著什麼。

** 於 5 月 2 日更新了案例研究：- 請參閱本文底部的詳細資訊** 我相信大多數閱讀此部落格的人都已經看到了昨天 SpringSource 應用程式平台的公告。如果沒有，請務必查看 Rob 的部落格文章，其中描述了一些動機、程式設計模型和路線圖。

有人提出了一些常見問題，我想在本文中立即解決。在那之後，我將描述另外兩個令人興奮的公告，這些公告補充了 SpringSource 應用程式平台本身，但昨天沒有成為頭條新聞：…

經過幾個月的瘋狂編碼，我很高興地宣布 SpringSource 應用程式平台 1.0 的 beta 版本發布。

在 2007 年初，我們開始討論可能的替代方案，以取代企業 Java 已經成為代名詞的單片和重量級應用程式伺服器。客戶正在尋找一個輕量級、模組化且足夠靈活的平台，以滿足他們的開發和部署需求。

Spring 和 Tomcat 的配對表明開發人員和運營商可以成功地在生產中使用輕量級平台。儘管這種組合取得了成功，但缺乏模組化和對非網路應用程式的顯式支援限制了其適用性和靈活性。

我們開始建構 SpringSource 應用程式平台，以滿足這些需求並消除這些限制。

該平台的核心是動態模組核心 (DMK)。DMK 是一個基於 OSGi 的核心，它充分利用了 OSGi 平台的模組化和版本控制功能。DMK 建立在 Equinox 之上，並擴展了其在配置和程式庫管理方面的功能，以及為平台提供核心功能。

為了保持最小的執行時佔用空間，DMK 配置子系統會根據需要安裝 OSGi 套件組。這允許將應用程式安裝到正在運行的平台中，並從外部儲存庫滿足其依賴項。這不僅消除了手動安裝所有應用程式依賴項的需要，這將是繁瑣的，而且還使記憶體使用量保持在最低限度。

DMK 本身只需要一組最小的套件組才能運行，並且配置了設定檔，以控制要載入的附加模組的確切集合。例如，DMK 不需要 Tomcat 存在，但預設的平台設定檔包含 Tomcat 以允許部署網路應用程式。如果您想在沒有 Tomcat 的情況下運行平台，您可以簡單地編輯設定檔，它將不會被安裝。（如果您嘗試這樣做 - 請記住，刪除網路支援意味著網路模組將不再部署，因此請刪除 pickup 目錄的內容，以便平台在啟動時不會嘗試安裝 Admin 和啟動畫面應用程式。）安裝了管理控制台的預設平台配置僅佔用 15MB 的記憶體。

我一直以來對企業級 Java 的一個挫折感是，應用程式常常被硬塞進人為設計的孤島中，並且缺乏對不同應用程式類型的明確支援。考慮一個線上商店的應用程式。這個應用程式有一個網頁前端、一個訊息驅動的訂單處理模組、一個批次驅動的庫存重新排序模組和一個 B2B 網頁服務模組。現今，許多像這樣的應用程式會被打包成 WAR 或 EAR，而這些模組看起來會非常相似，對於模組類型上的差異幾乎沒有提供支援。有趣的是，很多人會將其稱為網頁應用程式，而不是一個具有網頁模組的應用程式。

在 SpringSource Application Platform 中，應用程式是模組化的，每個模組都有一個特性 (personality)，描述它是哪種類型的模組：網頁、批次、網頁服務等等。這個平台會以特定於特性的方式部署每個特性的模組。例如，網頁模組會在 Tomcat 中使用網頁環境進行配置。應用程式中的每個模組都可以獨立於其他模組進行更新，同時保持作為更大應用程式一部分的身分。無論您正在構建何種類型的應用程式，程式設計模型都保持標準的 Spring 和 Spring DM。

在 1.0 Platform 版本中，我們支援 web (網頁) 和 bundle (套件) 特性，這使您能夠構建複雜的網頁應用程式。未來的版本將包括對更多特性的支援，詳情稍後介紹。

構建應用程式

這個平台支援以三種形式打包的應用程式：

1. Java EE WAR
2. 原始 OSGi 套件
3. Platform Archive (PAR)

標準 WAR 檔案在平台上直接支援。在部署時，WAR 檔案會被轉換為 OSGi 套件並安裝到 Tomcat 中。所有標準的 WAR 契約都會被遵守，並且您現有的 WAR 檔案應該可以直接放入並部署，無需修改。

任何符合 OSGi 標準的套件都可以直接部署到平台上，並且可以充分利用對 Import-Package 和 Require-Bundle 所引用之任何依賴項的即時配置。

PAR 格式是推薦用於打包和部署應用程式到平台上的方法。PAR 實際上只是一個 OSGi 套件（模組）的集合，它們被組合在一個標準的 JAR 檔案中，並帶有一個名稱和版本，以唯一地識別該應用程式。PAR 檔案作為一個單一單元部署到平台上。平台將會從 PAR 中提取所有模組並安裝它們。第三方依賴項將會根據需要即時安裝。

與直接將套件部署到平台相比，PAR 格式有三個主要優點。首先，它更容易。一個平均規模的企業應用程式可能包含 12 個以上的套件 - 手動部署這些套件會非常麻煩。其次，PAR 檔案在應用程式中的所有套件周圍形成一個明確的範圍，這可以防止使用重疊類型或服務的應用程式彼此衝突。這個範圍也被一些高級功能（例如載入時織入）使用，以確保一個應用程式的織入不會干擾另一個應用程式的織入。最後，PAR 形成一個邏輯分組，以定義哪些模組是應用程式的一部分，以及應用程式有哪些第三方依賴項。管理工具使用這個分組來提供應用程式的詳細視圖。一個典型的 PAR 應用程式看起來像這樣：

應用程式中模組之間的依賴關係通常使用 Import-Package 和 Export-Package 來表示。對第三方庫的依賴關係也可以用相同的方式表示，但對於許多庫來說，這可能容易出錯並且耗時。當使用像 Hibernate 這樣的庫時，您通常需要導入比您最初預期的更多的包。為了規避這個問題，您可以使用 Require-Bundle，但這有一些語義上的粗糙邊緣，例如分割套件 (split packages)，其中一個邏輯套件被分割在兩個或更多類別載入器中，導致執行時出現問題。平台引入了兩種新的機制來引用第三方依賴項：Import-Bundle 和 Import-Library。Import-Bundle 類似於 Require-Bundle，但它可以防止分割套件和 Require-Bundle 的其他問題。Import-Library 提供了一種機制，可以引用一組套件導出的所有套件，例如 Spring Framework 中的所有套件，只需一個聲明。

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 Framework 庫。Spring Framework 庫包含在您的應用程式中使用 Spring 所需的所有套件。

Import-Library 和 Import-Bundle 在底層會擴展成 Import-Package，因此與標準的 OSGi 語義一致。

平台理解模組的特性，並可以從中推斷出如何配置模組的執行環境。當部署一個網頁模組時，典型的 Spring MVC 應用程式所需的所有 servlet 基礎結構都會自動創建，從而無需跨應用程式重新創建這個樣板代碼。在 1.0 最終版本中，將會向網頁模組特性添加更多的智慧功能，以支援其他技術，例如 Spring Web Flow。

無論您選擇哪種打包格式，程式設計模型都只是 Spring Framework 和 Spring Dynamic Modules，以及運行在其之上的其他 Spring Portfolio 產品。

可維護性

可維護性是整個工程團隊的一個關鍵考慮因素。我們花費了大量的時間來擔心日誌消息的格式和堆疊追蹤的大小，以確保盡可能輕鬆地診斷您的應用程式的問題。任何時候，如果我們發現一項任務是重複且耗時的，我們都會尋找一種自動化它或完全刪除它的方法。

為了幫助進行問題診斷，平台在日誌消息和追蹤消息之間有著很強的分隔。日誌消息旨在供最終使用者消費，並允許您訪問最重要的故障信息，而無需遍歷數 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…

自從 Spring Dynamic Modules 的第一個里程碑開始，就開始收到在 OSGi 中執行網頁應用程式的請求。這可能是最受歡迎的功能之一，也難怪，一旦 1.0 最終版本發布，網頁支援就成為 1.1 分支的主要重點。我很高興地報告，在剛剛發布的 M2 中，正如 Juergen 暗示的那樣，Spring-DM 不僅支援 vanilla wars（自 1.1.0 M1 起可用），還支援在 OSGi 內部運行的 Spring-MVC 應用程式。在這篇文章中，我想簡要討論典型的 OSGi 網頁場景和 Spring-DM 的方法。但首先：

為什麼要在 OSGi 中部署 WAR？

為什麼 OSGi 中的網頁應用程式有問題？

…