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

有幾個常見問題被提出，我想在本文中立即解決。在那之後，我將描述另外兩個令人興奮的公告，它們補充了 SpringSource 應用平台本身，但昨天並未成為頭條新聞：SpringSource Enterprise Bundle Repository 和適用於 Eclipse 的應用平台工具。它們共同完整地敘述了關於使用 Spring 進行基於 OSGi 的企業應用程式開發的故事。

在過去 24 小時內，我聽過好幾次的問題是：OSGi 有什麼問題？為什麼我們不能只使用標準的 OSGi 服務平台（例如 Equinox、Felix 或 Knopflerfish）來代替 SpringSource 應用平台？

OSGi 絕對沒有任何問題。

OSGi 是一個很棒的基礎和服務平台 - 這就是為什麼我們和許多其他人選擇在其基礎上構建的原因。它在 廣泛的產業和應用中得到驗證，並且是 Eclipse 和 IBM 的 WebSphere 等應用程式以及其他幾家供應商的中介軟體堆疊的基礎。

直接針對 OSGi 規範 API 進行程式設計，缺少我們對企業應用程式所期望的一些品質 - 例如使用依賴注入和創建易於在容器外部進行單元和整合測試的應用程式的能力。直接針對 OSGi 規範 API 進行程式設計，也迫使您以相對較低的層級處理 OSGi 平台的動態 - 當您依賴的模組和服務在運行時停止、啟動、安裝和更新時，您會怎麼做？但是，這裡沒有我們無法使用 Spring Dynamic Modules 專案克服的根本障礙。使用 Spring Dynamic Modules 構建的應用程式可以在任何標準 OSGi 服務平台上運行，並且我們針對 Equinox、Felix 和 Knopflerfish 測試我們所有的建置版本。我們致力於確保 Spring Dynamic Modules 和基於 Spring 的程式設計模型保持運行時中立。這種立場不會隨著 SpringSource 應用平台的引入而改變。

現有的企業函式庫也絕對沒有任何問題。

好吧，還可以。在某些情況下，可能還有一些不足之處，但總體而言，我們知道如何使它們滿足企業應用程式開發的需求。

那麼問題出在哪裡？

如果 OSGi 運作良好，並且現有的企業函式庫也滿足我們的需求，那麼問題出在哪裡？當您嘗試將 OSGi 服務平台與一組並非為 OSGi 設計的現有企業函式庫結合時，就會出現困難。這不是 OSGi 的錯，它有一個很棒的模型，可以提供出色的模組化、版本控制和操作控制。這也不是企業函式庫的錯 - 它們並非為在 OSGi 下運行而編寫。但是，使 OSGi 如此吸引人的事物，卻打破了這些企業函式庫開發人員所做的假設。例如，OSGi 的模組化模型阻止您看到其他人的 Bundle 的私有部分。這正是您想要的，直到您意識到您的企業函式庫再也看不到您的應用程式類型。許多事情可能會崩潰：從 commons logging 到 jsps，從標籤函式庫到資料來源，從載入時期織入到元件掃描，從資源載入到 orm 映射。列表還在繼續...（是的，當您將應用程式程式碼及其所需的所有函式庫打包到單個 Bundle 中時，您可以使許多這些東西正常工作，但這在很大程度上沒有抓住重點！）。

這就是為什麼您看到很多人在 OSGi 之上構建，但很少有將 OSGi 優勢傳遞到應用程式程式設計模型中的案例（Eclipse RCP 是一個罕見的例外）。當您在 OSGi 之上構建，但不一定將該模型暴露給終端使用者應用程式開發時，您可以針對 OSGi 模型構建並使事情正常運作。當您需要提供一個平台，可以在該平台上使用大量現有的企業函式庫時，這是一個不同的遊戲。如果我們可以拋棄所有這些，並從頭開始使用專門為 OSGi 編寫的函式庫，我們就會沒事。例如，我們已確保 Spring Framework 完全能夠在 OSGi 服務平台內部運行。但這不是一個現實的提議。或者，我們可以等待現有函式庫的開發人員將它們全部轉換為在 OSGi 下開箱即用地運行（就像我們對 Spring 所做的那樣）。但是，除非其他所有人也這樣做，否則他們這樣做的動機是什麼？因此，我們似乎陷入了雞生蛋蛋生雞的困境。OSGi Enterprise Expert Group 在過去一年中花費了大量時間討論這個問題。這就是 SpringSource 應用平台解決的問題：- 它透過使具有標準 OSGi 語義的標準 OSGi Bundle 與現有的企業應用程式函式庫一起運作，從而引導企業應用程式開發進入 OSGi 的世界。

我也想再次強調，該平台不僅僅是關於 OSGi：OSGi 支援是我們最興奮的功能之一，但 SpringSource 應用平台也是一個出色的伺服器平台，用於部署標準 war 檔案。我們將在後續文章中描述該平台在此類情境中提供的優勢。

希望這篇文章有助於釐清圍繞 SpringSource 應用平台與 OSGi 之間的確切關係的一些困惑。如果您一直關注到目前為止，您可能已經注意到另一個潛在的問題：使現有的企業函式庫在 OSGi 下工作固然很好，但是您是否需要將它們的所有 jar 檔案轉換為 OSGi Bundle 才能部署它們？是的，您需要。而且事實證明，如果您想正確地對所有匯入和匯出進行版本控制，並確保您擁有正確的符號名稱等，這將是一項大量的工作。好消息是，對於數百個常用的企業應用程式函式庫，我們已經為您完成了繁重的工作，並在 SpringSource Enterprise Bundle Repository 中提供了 OSGi 就緒版本...

SpringSource Enterprise Bundle Repository

SpringSource Enterprise Bundle Repository 既是一個可以從 Ivy 和 Maven 使用的儲存庫，也是一個企業函式庫的線上可搜尋資料庫。您可以在 www.springsource.com/repository 找到它。您可以按名稱瀏覽 Bundle，或只是輸入搜尋詞以查找具有匹配名稱、匯出套件、類別或資源的 Bundle。您還可以查看任何 Bundle 的最小（僅滿足所需的依賴項）和最大（滿足盡可能多的可選依賴項）的傳遞依賴項。

來自常見問題解答

“SpringSource Enterprise Bundle Repository 是常用於使用 Spring Framework 開發企業 Java 應用程式的開放原始碼函式庫的集合。該儲存庫包含 jar 檔案 (Bundle) 和函式庫定義 (".libd") 檔案。函式庫定義了通常一起用於某些目的的 Bundle 的集合（例如“Spring Framework”函式庫）。儲存庫中包含數百個 Bundle。” 該儲存庫符合以下標準

• 儲存庫中的每個 jar 檔案都是有效的 OSGi Bundle。您可以將從儲存庫下載的任何 jar 檔案按原樣部署到 OSGi 服務平台和 SpringSource 應用平台中。它也可以在 OSGi 之外用作常規 jar 檔案。
• 每個 Bundle 和函式庫都具有與之關聯的完整版本資訊。Bundle 的套件匯出資訊包含版本資訊，而 Bundle 的套件匯入資訊包含完整的版本範圍相容性資訊。
• 儲存庫是傳遞完整的。保證儲存庫中也包含任何 Bundle 的強制性依賴項。儲存庫中任何 Bundle 的大多數可選依賴項也將存在。保證儲存庫中包含任何函式庫定義中列出的 Bundle。
• 儲存庫是自我一致的。在將任何工件上傳到儲存庫之前，我們會驗證它是否可以與儲存庫中的所有其他 Bundle 一起安裝、解析並在 OSGi 服務平台（使用與 SpringSource 應用平台相同的配置檔案）中啟動。
• 可以從基於 Ivy 和 Maven 的建置中使用儲存庫。

為了維護這些保證，我們已經圍繞工件發佈到儲存庫制定了治理模型。有一個 JIRA 實例，您可以在其中提出請求，要求包含更多函式庫，並報告與現有已發佈工件有關的任何問題（與 OSGi Manifest 等相關）。

應用程式開發工具

到目前為止，我們已經討論了用於開發作為 OSGi Bundle 的應用程式的基於 Spring 的程式設計模型、用於部署到 OSGi 服務平台的企業函式庫的可用性，以及使這些舊式函式庫在 OSGi 運行時中工作的運行時（SpringSource 應用平台）。拼圖中缺少的部分是使創建基於 OSGi 的應用程式變得容易的開發人員工具。

Eclipse 已經內建了 OSGi 開發工具。由於每個 Eclipse 外掛程式也是一個 OSGi Bundle，因此 Eclipse PDE 工具（外掛程式開發環境工具）可以用於 OSGi 應用程式開發。但是，這些工具主要為 Eclipse 外掛程式的開發而設計的事實顯而易見，並且在將它們用於 OSGi 應用程式開發時，存在一些常見的挫敗感。其中之一是 META-INF/MANIFEST.MF 檔案只能放置在專案的根目錄中 - 這對於 Ivy 和 Maven 等建置工具來說效果不佳，另一個是您被限制為整個工作區的單個目標平台（要針對其開發的 Bundle 的集合）。PDE 工具真正出色且您真正需要的是，它們從 OSGi Manifest 建立專案的編譯類別路徑 - 因此您在編譯、測試和運行時之間不會在類別路徑和類別可見性方面存在差異。

除了 SpringSource 應用平台之外，我們還發佈了一組 Eclipse 外掛程式（可從 SpringSource 應用平台下載頁面獲得），這些外掛程式使 OSGi 應用程式的開發更加容易，尤其是針對 SpringSource 應用平台的應用程式。您的 META-INF/MANIFEST.MF 檔案可以位於任何來源目錄中，並且這些工具從 Manifest 條目建立編譯類別路徑。但是，您可以使用定義給 Eclipse 的 SpringSource 應用平台伺服器（使用 WTP 功能）將您的專案與之關聯，而不是單個目標平台。然後，您的專案的類別路徑從您的 Manifest 中的匯入語句中派生出來，並針對工作區中的其他 Bundle 專案和安裝在關聯伺服器中的 Bundle 進行解析。您在編譯時獲得的類別路徑和依賴項的解釋與在運行時完全相同。當然，正常的“部署到伺服器”選項也適用。

以下是伺服器在 Eclipse 內部運行時的外觀：

此螢幕截圖顯示了如何使用“Bundle Dependencies”類別路徑容器管理類別路徑。請注意，您未在 Manifest 檔案中匯入的套件會變灰，以指示您目前無法存取它們。

更好的是我們如何能夠利用 OSGi 的模組化。一組專案（每個 Bundle 一個）組成了您的應用程式。當您在專案中更改任何內容時，一個額外的增量建置器會分析資源差異，並對 SpringSource 應用平台中運行的 Bundle 進行即時更新 - 因此您始終使用最新的程式碼運行：每次、始終如此。這是一個巨大的生產力提升和出色的開發體驗。

案例研究

Matt Raible 發表了一篇 部落格文章，講述了他嘗試在不使用 SpringSource 應用平台的情況下，使用 Freemarker 使 Spring Web 應用程式在 OSGi 下運行的冒險經歷。這似乎是一個很好的挑戰應用程式，可以測試我上面所說的關於使現有企業函式庫正常運作的說法。好消息是，此應用程式在 SpringSource 應用平台上非常順利地運行。以下是我使其運作的步驟（總時間約 10 分鐘）

• 從 Matt 的部落格下載 zip 檔案
• 運行 'mvn'
• 將 target/mpapp.war 複製到平台的 pickup 目錄
• 啟動平台：bin/startup.sh。

我在控制台中得到以下輸出

com.springsource.platform.deployer.core.DeploymentException: Unable to satisfy constraints of 'myapp' version '0.0.0':

Cannot resolve: myapp  Unsatisfied leaf constraints:

Bundle: myapp_0.0.0 - Import-Package: org.springframework.osgi.web.context.support; version="0.0.0"

Did you mean: 'org.springframework.osgi.context.support'?

Bundle: myapp_0.0.0 - Import-Package: freemarker.ext.servlet; version="0.0.0"

Did you mean: 'javax.servlet'?

Bundle: myapp_0.0.0 - Import-Package: freemarker.core; version="0.0.0"

Did you mean: 'org.hamcrest.core'?

Bundle: myapp_0.0.0 - Import-Package: freemarker.template; version="0.0.0"

Did you mean: 'org.antlr.tool'?

Bundle: myapp_0.0.0 - Import-Package: freemarker.cache; version="0.0.0"

Did you mean: 'org.apache'?

這些是預期的訊息，因為我的平台中沒有安裝 freemarker 或 osgi.web.context 支援 Bundle。

• 前往 http://www.springsource.com/repository。在搜尋框中輸入“freemarker”，找到一個匹配的條目，然後點擊連結下載它。將下載的 Bundle 複製到 repository/bundles/usr
• 簡化 Manifest 以指向平台上的新 Bundle 和函式庫。原始 Manifest 看起來像這樣

Import-Package: javax.servlet,javax.servlet.http,javax.servlet.resources,javax.swing.tree,

javax.naming,org.w3c.dom,org.apache.commons.logging,javax.xml.parsers;resolution:=optional,

org.xml.sax;resolution:=optional,org.xml.sax.helpers;resolution:=optional,

org.springframework.osgi.web.context.support, org.springframework.context.support,

org.springframework.web.context, org.springframework.web.context.support,

org.springframework.web.servlet, org.springframework.web.servlet.mvc,

org.springframework.web.servlet.mvc.support, org.springframework.web.servlet.view,

org.springframework.ui, org.springframework.web.servlet.view.

freemarker, freemarker.cache,freemarker.core,freemarker.template,freemarker.ext.servlet

我將其簡化為

Import-Package: org.apache.commons.logging

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

Import-Bundle: com.springsource.freemarker;version="2.3.12"

當我們知道您正在部署 Web 應用程式時，常用的必要匯入會在部署時自動新增。Import-Library 和 Import-Bundle 允許您在單個語句中方便地引用函式庫和 Bundle。我也刪除了“Bundle-Classpath”條目，因為應用平台將自動偵測 WEB-INF/lib 中的函式庫並將它們新增到 Bundle 類別路徑。

• 我編輯了 web.xml 並註解掉了 context-param 宣告，因為這裡不需要使用自訂應用程式上下文類型
• 再次運行 'mvn'，然後將 myapp.war 複製到 pickup 目錄。
• 應用平台自動重新部署了應用程式
• 將瀏覽器指向 https://127.0.0.1:8080/myapp/ .... 成功！

我認為這很好地示範了該平台在簡化企業函式庫在 OSGi 下運作的路徑方面的價值主張。