** 5月2日更新，包含案例研究：- 詳見此帖子底部 ** 我相信閱讀本部落格的大多數人昨天都看到了 SpringSource 應用平臺的釋出公告。如果沒有，請務必檢視 Rob 的部落格文章，其中描述了一些動機、程式設計模型和路線圖。

本文將首先解決幾個常見問題。然後我將介紹另外兩個激動人心的公告，它們是 SpringSource Application Platform 的補充，但昨天並未成為頭條新聞：SpringSource 企業捆綁包儲存庫和 Eclipse 的 Application Platform 工具。它們共同完善了基於 OSGi 的企業應用程式開發的完整故事。

過去 24 小時內我多次聽到的問題是：OSGi 有什麼問題？為什麼我們不能直接使用普通的 OSGi 服務平臺（例如 Equinox、Felix 或 Knopflerfish）而不是 SpringSource Application Platform？

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 Application Platform 的引入，這一立場不會改變。

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

好吧，好的。有些情況仍有待改進，但總的來說，我們知道如何讓它們滿足企業應用程式開發的需求。

那問題出在哪裡？

如果 OSGi 執行良好，並且現有的企業庫能夠滿足我們的需求，那麼問題出在哪裡？困難在於當您嘗試將 OSGi 服務平臺與一套未考慮 OSGi 而編寫的現有企業庫結合使用時。這不是 OSGi 的錯，它有一個出色的模型，提供了卓越的模組化、版本控制和操作控制。也不是企業庫的錯——它們不是為在 OSGi 下執行而編寫的。但正是使 OSGi 如此吸引人的那些特性打破了這些企業庫開發人員所做的假設。例如，OSGi 的模組化模型阻止您檢視其他捆綁包的私有部分。這正是您想要的，直到您意識到您的企業庫無法再看到您的應用程式型別。許多事情都可能出錯：從通用日誌記錄到 JSP，從標籤庫到資料來源，從載入時織入到元件掃描，從資源載入到 ORM 對映。這個列表還在繼續……（是的，當您將應用程式程式碼及其所需的所有庫打包到一個捆綁包中時，您可以讓其中許多東西正常工作，但這非常偏離了重點！）。

這就是為什麼你會看到很多人在 OSGi 之上構建，但很少有將 OSGi 的好處傳遞到應用程式程式設計模型中的案例（Eclipse RCP 是一個罕見的例外）。當你在 OSGi 之上構建，但不一定將該模型暴露給終端使用者應用程式開發時，你可以按照 OSGi 模型構建並使其工作。當你需要提供一個平臺，讓大量現有的企業庫能夠在其上使用時，情況就不同了。如果我們可以拋棄所有這些，從頭開始使用專門為 OSGi 編寫的庫，那會很好。例如，我們已經確保 Spring Framework 能夠完全在 OSGi 服務平臺中執行。但這並不是一個現實的提議。或者我們可以等待現有庫的開發人員將它們全部轉換為在 OSGi 下開箱即用（就像我們對 Spring 所做的那樣）。但除非其他人也這樣做，否則他們這樣做的動機是什麼？所以我們似乎陷入了一個先有雞還是先有蛋的困境。這是 OSGi 企業專家組在過去一年中花費大量時間討論的問題。這就是 SpringSource Application Platform 解決的問題：它透過使具有標準 OSGi 語義的標準 OSGi 捆綁包與現有企業應用程式庫協同工作，從而將企業應用程式開發引導到 OSGi 的世界。

我還想再次強調，該平臺不僅僅與 OSGi 相關：OSGi 支援是我們最興奮的特性之一，但 SpringSource Application Platform 也是一個出色的伺服器平臺，用於部署標準 war 檔案。我們將在後續文章中描述該平臺在此類場景中提供的優勢。

希望這篇帖子能夠幫助消除圍繞 SpringSource Application Platform 與 OSGi 之間關係的困惑。如果您一直關注到這裡，您可能已經發現了另一個潛在的問題：讓現有的企業庫在 OSGi 下工作固然很好，但是您是否需要將它們所有的 jar 檔案都轉換為 OSGi 捆綁包才能部署它們呢？是的，您確實需要。事實證明，如果您想正確地版本化所有匯入和匯出，並確保擁有正確的符號名稱等，那將是大量的工作。好訊息是，對於數百個常用企業應用程式庫，我們已經為您完成了艱苦的工作，並在 SpringSource Enterprise Bundle Repository 中提供了 OSGi 就緒版本...

SpringSource 企業捆綁包儲存庫

SpringSource 企業捆綁包儲存庫既是一個可用於 Ivy 和 Maven 的儲存庫，也是一個可線上搜尋的企業庫資料庫。您可以在 www.springsource.com/repository 找到它。您可以按名稱瀏覽捆綁包，或者直接輸入搜尋詞以查詢名稱、匯出包、類或資源匹配的捆綁包。您還可以檢視任何捆綁包的最小（僅滿足所需依賴項）和最大（儘可能滿足可選依賴項）傳遞依賴項。

摘自常見問題解答

“SpringSource 企業捆綁包儲存庫是用於使用 Spring Framework 開發企業 Java 應用程式的常用開源庫的集合。該儲存庫包含 jar 檔案（捆綁包）和庫定義（“.libd”）檔案。庫定義了一組通常用於特定目的（例如“Spring Framework”庫）的捆綁包。儲存庫中包含數百個捆綁包。”該儲存庫滿足以下標準

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

為了保持這些保證，我們為向儲存庫釋出工件制定了治理模型。有一個 JIRA 例項，您可以針對它提出包含其他庫的請求，並報告現有已釋出工件的任何問題（與 OSGi 清單等相關）。

應用程式開發工具

到目前為止，我們已經討論了用於將應用程式開發為 OSGi 捆綁包的基於 Spring 的程式設計模型、可部署到 OSGi 服務平臺的企業庫的可用性，以及使這些傳統庫能夠在 OSGi 執行時中工作的執行時（SpringSource Application Platform）。缺少的部分是使基於 OSGi 的應用程式建立變得容易的開發人員工具。

Eclipse 已經內建了 OSGi 開發工具。由於每個 Eclipse 外掛也是一個 OSGi 捆綁包，因此 Eclipse PDE 工具（外掛開發環境工具）可用於 OSGi 應用程式開發。然而，這些工具主要是為 Eclipse 外掛開發而設計的，這在使用它們進行 OSGi 應用程式開發時會帶來一些常見的挫敗感。一是 META-INF/MANIFEST.MF 檔案只能放在專案的根目錄下——這與 Ivy 和 Maven 等構建工具配合不佳；另一個是您在整個工作區中受限於單個目標平臺（要開發針對的捆綁包集合）。PDE 工具的優點，也是您真正需要的，是它們根據 OSGi 清單為您的專案構建編譯類路徑——這樣您在編譯、測試和執行時之間就不會出現類路徑和類可見性的差異。

除了 SpringSource Application Platform，我們還發布了一套 Eclipse 外掛（可從 SpringSource Application Platform 下載頁面獲取），使 OSGi 應用程式的開發更容易，特別是針對 SpringSource Application Platform 的應用程式。您的 META-INF/MANIFEST.MF 檔案可以放在任何源目錄中，工具會根據清單條目構建編譯類路徑。但是，您不再受限於單個目標平臺，而是可以將您的專案與定義到 Eclipse 的 SpringSource Application Platform 伺服器關聯起來（使用 WTP 功能）。然後，您的專案的類路徑將根據清單中的匯入語句，針對工作區中的其他捆綁包專案和關聯伺服器中安裝的捆綁包進行解析。您在編譯時和執行時對類路徑和依賴項的解釋完全相同。當然，正常的“部署到伺服器”選項也適用。

伺服器在 Eclipse 中執行時的樣子：

此螢幕截圖顯示瞭如何使用“捆綁包依賴項”類路徑容器管理類路徑。請注意，清單檔案中未匯入的包被置灰，表示您當前無法訪問它們。

更好的是我們如何利用 OSGi 的模組化。一組專案（每個捆綁包一個）構成您的應用程式。當您更改專案中的任何內容時，一個額外的增量構建器會分析資源增量，並對 SpringSource Application Platform 中正在執行的捆綁包進行即時更新——因此您始終執行著最新的程式碼：每一次，一直如此。這是一個巨大的生產力提升，也是一個很棒的開發體驗。

案例研究

Matt Raible 釋出了一篇部落格文章，講述了他嘗試在 OSGi 下使用 Freemarker 執行 Spring Web 應用程式的經歷——沒有使用 SpringSource Application Platform。這似乎是一個很好的挑戰應用程式，可以測試我上面關於使現有企業庫工作所說的話。好訊息是，這個應用程式在 SpringSource Application Platform 上執行得非常愉快。以下是我使其工作的步驟（總耗時約 10 分鐘）

• 從 Matt 的部落格下載 zip 檔案
• 執行 'mvn'
• 將 target/mpapp.war 複製到 Platform 的 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 支援捆綁包，因此這些是預期的訊息。

• 前往 http://www.springsource.com/repository。在搜尋框中鍵入“freemarker”，找到匹配的條目並單擊連結下載。將下載的捆綁包複製到 repository/bundles/usr
• 簡化清單以指向平臺上的新捆綁包和庫。原始清單如下所示

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-Classpath”條目，因為應用程式平臺會自動檢測 WEB-INF/lib 中的庫並將其新增到捆綁包類路徑中。

• 我編輯了 web.xml 並註釋掉了 context-param 宣告，因為這裡不需要使用自定義應用程式上下文型別
• 再次執行 'mvn'，並將 myapp.war 複製到 pickup 目錄中。
• 應用程式平臺自動重新部署了應用程式
• 用瀏覽器訪問 https://:8080/myapp/ .... 成功！

我認為這是一個很好的演示，展示了平臺在簡化企業庫在 OSGi 下工作方面所體現的價值主張。