在我關於 Spring Integration 的演講之後，我收到了很多關於澄清和示例的問題。為了滿足需求，我將開始一個小系列，介紹如何使用 Spring Integration 實現不同的整合模式。第一篇文章將重點介紹基礎知識。它將向您展示如何啟動並執行，並帶您瞭解其中一個示例。

如果您之前從未聽說過 Spring Integration，最好閱讀Mark Fisher 關於它的介紹性部落格或瀏覽專案網站來熟悉它。一般來說

讓我先說一個免責宣告：...

InfoQ 有一個討論帖總結了對 SpringSource Application Platform 公告的反應。Michael Burke 在該帖中提出了一個很棒的問題，可以轉述為“拋開圍繞 OSGi 的炒作，如果我將當前打包為 EAR 的應用程式移植到 OSGi 捆綁包，我能期望看到哪些好處？”。

我開始在 InfoQ 的討論帖中回答這個問題，但我的回答太長不適合作為評論，所以我將在這裡解答。

這個問題提得很好。基於 OSGi 的應用程式與傳統的基於 JEE EAR 的應用程式之間的主要區別在於模組化得到了改進。所以問題就變成了，這種改進的模組化是否能帶來任何好處，如果能，是什麼好處？《設計規則，模組化的力量》一書對這個問題進行了非常詳盡的處理。這是一個很好的背景，但我感覺 Michael 可能在尋找比那本書中更少理論性的東西……

SpringSource Application Platform 的主要優勢之一是它能夠按需提供依賴項。這樣做的好處有兩個方面：它確保平臺的記憶體佔用儘可能小，並且允許部署應用程式，而無需將其所有依賴項封裝在單一的部署單元中，例如 WAR 檔案。要利用這些功能，您需要了解平臺的 Provisioning 倉庫，這篇部落格旨在提供這方面的知識。

Provisioning 倉庫在哪裡，它是如何工作的？

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

執行時 Provisioning

當平臺啟動已部署的應用程式時，它的...

很高興聽到關於SpringSource Application Platform的如此多的討論，無論是在線上還是在 JavaOne 會場。其中一個最有見地的評論來自 WebSphere 事務架構師 Ian Robinson

這些是否會影響 WebSphere？嗯，核心 Spring 框架沒有任何改變。無論 SpringSource Application Platform 未來如何，核心 Spring 框架專案仍然與 WebSphere 相輔相成。就像炸魚薯條一樣。

SpringSource Application Platform 由 OSGi 捆綁包構建，並支援同樣由 OSGi 捆綁包構建的應用程式。該平臺支援 OSGi 的標準特性，但也支援一些額外的 manifest 頭資訊。有些人問過為什麼 SpringSource 添加了專有頭資訊？和新頭資訊的語義是什麼？，所以這篇博文解釋了 Import-Library 和 Import-Bundle 的背景動機和語義。

標準 OSGi 捆綁包支援

因此，熟悉 OSGi 的開發者可以將平臺用作標準的 OSGi 容器，並受益於平臺的以下特性：

• 能夠使用 Admin Console 或將捆綁包放入平臺的 pickup 目錄來部署捆綁包，
• 診斷，例如解析失敗診斷、應用程式特定跟蹤和自動死鎖檢測，
• 與 Spring 和 Spring Dynamic Modules 的強大整合，適用於希望使用這些框架的開發者，以及
• 從倉庫自動 Provisioning 依賴項。

企業應用程式的額外要求

嗯，過程中的一些步驟相對容易，特別是如果遵循了良好的軟體工程實踐並且程式碼已組織成服務、領域和基礎設施元件。這些元件可以轉換為捆綁包，它們之間的依賴關係可以使用 META-INF/MANIFEST.MF 中的標準 OSGi Import-Package 和 Export-Package 頭資訊來表達。

更困難的一步是表達對 Spring 和 Hibernate 等企業框架的依賴。使用標準的 OSGi Import-Package 和 Require-Bundle 頭資訊完全可以表達這些依賴關係，如果您的目標是建立可以在其他 OSGi 容器中執行的 OSGi 捆綁包，這正是您應該做的，但這種方法有一些隱藏的成本。

首先，開發者必須精確決定給定框架包含哪些包。僅僅匯入應用程式程式碼使用的包是不夠的，因為當應用程式載入時，一些企業框架會將更多依賴項織入應用程式的位元組碼中。開發者必須透過嘗試和錯誤來發現需要匯入哪些額外的實現包，以確保織入的應用程式能夠正確執行。

然後是框架版本升級的繁瑣工作，因為構成框架的精確包集合可能會發生變化。織入所需的額外包通常不是由公共契約定義的，因此容易發生變化。

此外，由此產生的包匯入並不能正確體現設計意圖，這使得將來維護或擴充套件應用程式更加困難。

我們真的不想將這些負擔強加給使用者，因此我們建立了一些額外的 SpringSource Application Platform 特定的 manifest 頭資訊，Import-Library 和 Import-Bundle，作為表達對企業框架依賴關係的便捷方式。正如您將在下面看到的，這些頭資訊實際上只是語法糖，它們最終被轉換為標準的 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>（當然也包括分號分隔符），則預設範圍包含所有版本。

對於每個庫匯入，平臺會選擇具有給定符號名稱且在給定版本範圍內、並且在平臺倉庫中可用的最高版本庫。然後，平臺將庫匯入替換為一組包匯入，這些包匯入與該庫的捆綁包匯出的所有包匹配。平臺會檢測到一個捆綁包匯入了兩個或多個匯出共同包的庫的情況，併發出相應的日誌訊息，然後導致匯入該捆綁包失敗。

所以，例如，以下頭資訊匯入了 Spring Framework 庫 的某個版本，該版本在 2.5.4（包含）到 2.5.5（不包含）之間

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

可選的庫匯入

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

如果未指定 resolution，或指定為 mandatory，如果不存在具有給定符號名稱且在給定版本範圍內的庫，則包含 import library 頭資訊的捆綁包將無法安裝。但如果指定了 resolution:=optional，則在沒有合適的庫可用時，該庫匯入將被忽略。

所以，例如，以下頭資訊匯入了 Spring Framework 庫的 2.5 版本或更高版本，但在沒有合適的庫可用時將被忽略

    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 Application Platform 以來，許多開發者下載了 1.0.0 beta 版本並開始試用該平臺。因此，人們開始詢問：“如何將我的應用程式部署到平臺上，以及我有哪些部署和打包選項？”此外，開發者們熱切地要求看到可執行的示例。作為回應，S2AP 團隊將在未來幾周釋出幾個示例應用程式，演示這些功能及更多內容，但在您獲得這些示例之前，我想先為您提供一個高層概覽...

許多人一直在問，除了 OSGi 和 Spring Dynamic Modules 本身提供的功能之外，SpringSource Application Platform 究竟為 Spring 應用程式做了什麼，使它們能夠在 OSGi 下良好執行。Adrian 昨天的博文強調了一些常見問題，現在讓我們看看一些細節。

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

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

其餘但不太重要的問題包括：JSP 支援、TLD 掃描、註解匹配和資源查詢。總的來說，為了使應用程式順利部署，需要解決相當數量的問題。

載入時織入

載入時織入 (Load-time weaving, LTW) 是最難以可靠支援的功能之一。在基本層面，它需要鉤入 Equinox 的 ClassLoader，以便在 defineClass 呼叫期間可以附加和使用標準的 ClassFileTransformers。除此之外，許多 LTW 的使用需要訪問一個臨時 ClassLoader，該載入器可用於檢查型別以決定在織入期間需要發生什麼，而不會影響真實的 ClassLoader。

實現這種基本級別的支援實際上是相當簡單的。困難在於當織入由一個捆綁包中的類驅動，但需要織入另一個捆綁包中的類時。這在企業應用程式中非常常見，例如一個捆綁包包含領域實體，而另一個捆綁包包含使用 JPA EntityManager 的型別。平臺透過確保應用程式中的所有捆綁包都可以使用適當的 ClassFileTransformers 進行織入來處理這種複雜性。

當你開始將織入傳播到其他捆綁包時，你確實需要知道何時停止。如果你只是簡單地將織入應用於所有捆綁包，那麼應用程式之間會相互干擾。平臺透過顯式地設定織入的作用域，使其僅應用於應用程式中的模組來防止這種情況發生。

LTW 的另一個問題是它使重新整理變得複雜。當一個捆綁包被重新整理時，OSGi 會重新整理所有依賴於它的捆綁包。這意味著，在我上面給出的示例中，重新整理域捆綁包將導致 EntityManager 捆綁包被重新整理。然而，重新整理 EntityManager 不會重新整理域捆綁包，這意味著織入可能不同步。平臺透過將重新整理傳播到受織入影響的其他捆綁包來處理這個問題。

類路徑掃描

對於類路徑掃描，主要問題是 Equinox 不會暴露標準的 jar: 和 file: 資源。平臺在中間放置了一個介面卡，以便庫能看到它們期望的資源協議。這有一個很好的附帶效果，使得很多第三方庫能夠正常工作——這不僅僅是類路徑掃描的一個修復。

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

許多第三方庫使用執行緒上下文 ClassLoader 來訪問應用程式型別和資源。OSGi 中的每個捆綁包都有自己的 ClassLoader，因此，在任何時候只有一個捆綁包可以作為執行緒上下文 ClassLoader 暴露出來。這意味著如果第三方庫需要看到分佈在多個捆綁包中的型別，它將無法按預期工作。

平臺透過建立一個 ClassLoader 來解決這個問題，該載入器匯入了您的應用程式中每個模組的所有匯出包。然後將這個 ClassLoader 作為執行緒上下文 ClassLoader 暴露出來，使第三方庫能夠看到應用程式中所有匯出的型別。

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

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

人們提出了一些常見問題，我想在這篇博文中立即予以解答。之後，我將介紹另外兩個令人振奮的公告，它們與 SpringSource Application Platform 本身相輔相成，但昨天並未成為頭條新聞：...

經過數月的緊張編碼，我很高興地宣佈 SpringSource Application Platform 1.0 的 Beta 版本釋出了。

2007 年初，我們開始討論單體式和重量級應用伺服器的可能替代方案，而企業級 Java 已經與這些伺服器聯絡在一起。客戶正在尋找一個輕量級、模組化且足夠靈活的平臺，以滿足他們的開發和部署需求。

Spring 和 Tomcat 的結合證明了開發者和運維人員可以在生產環境成功使用輕量級平臺。儘管這種組合取得了成功，但缺乏模組化和對非 Web 應用程式的明確支援限制了其適用性和靈活性。

我們著手構建 SpringSource Application Platform，以滿足這些需求並消除這些限制。

平臺的核心是動態模組核心 (Dynamic Module Kernel, DMK)。DMK 是一個基於 OSGi 的核心，它充分利用了 OSGi 平臺的模組化和版本控制特性。DMK 基於 Equinox 構建，並擴充套件了其在 Provisioning 和庫管理方面的能力，同時為平臺提供了核心功能。

為了保持最小的執行時記憶體佔用，OSGi 捆綁包由 DMK Provisioning 子系統按需安裝。這使得應用程式可以安裝到執行中的平臺中，並且其依賴項可以從外部倉庫滿足。這不僅消除了手動安裝應用程式所有依賴項的需要（這很繁瑣），而且將記憶體使用量保持在最低水平。

DMK 本身只需要最少的捆綁包即可執行，並且配置了一個profile 來精確控制載入的額外模組集合。例如，DMK 不需要 Tomcat 存在，但預設的平臺 profile 包含 Tomcat 以允許部署 Web 應用程式。如果您想在沒有 Tomcat 的情況下執行平臺，您只需編輯 profile，它將不會被安裝。（如果您嘗試這樣做 - 請記住移除 Web 支援意味著 Web 模組將不再能部署，因此請刪除 pickup 目錄中的內容，這樣平臺在啟動時就不會嘗試安裝 Admin 和啟動屏應用程式。）安裝了 admin console 的預設平臺配置僅佔用 15MB 記憶體。

我對企業級 Java 一直感到沮喪的一點是，應用程式經常被硬塞進人為劃分的孤島中，並且缺乏對不同應用程式型別的明確支援。考慮一個線上商店的應用程式。該應用程式有一個 Web 前端、一個訊息驅動的訂單處理模組、一個批處理驅動的庫存重新排序模組以及一個 B2B Web 服務模組。如今，許多這樣的應用程式都會被打包成 WAR 或 EAR 檔案，並且這些模組看起來非常相似，對模組型別的差異幾乎沒有支援。有趣的是，許多人會將此類應用程式稱為 Web 應用程式，而不是一個包含 Web 模組的應用程式。

在 SpringSource Application Platform 中，應用程式是模組化的，每個模組都有一個描述其型別的 personality：Web、批處理、Web 服務等。平臺以特定於 personality 的方式部署每種 personality 的模組。例如，Web 模組在 Tomcat 中配置有 Web 上下文。應用程式中的每個模組都可以獨立於其他模組進行更新，同時保持作為大型應用程式一部分的身份。無論您構建何種型別的應用程式，程式設計模型都保持標準的 Spring 和 Spring DM。

在 1.0 平臺釋出中，我們支援 web 和 bundle personality，這使您能夠構建複雜的 Web 應用程式。未來的版本將包含對更多 personality 的支援，詳情將在稍後介紹。

構建應用程式

平臺支援三種打包形式的應用程式

1. Java EE WAR
2. 原始 OSGi 捆綁包
3. 平臺歸檔檔案 (PAR)

平臺直接支援標準的 WAR 檔案。部署時，WAR 檔案會被轉換成一個 OSGi 捆綁包並安裝到 Tomcat 中。所有標準的 WAR 契約都被遵守，您現有的 WAR 檔案應該可以直接放入並部署，無需更改。

任何符合 OSGi 規範的捆綁包都可以直接部署到平臺中，並且可以充分利用針對 Import-Package 和 Require-Bundle 引用的任何依賴項進行的即時 Provisioning。

PAR 格式是平臺應用程式打包和部署的推薦方法。PAR 簡單來說就是將 OSGi 捆綁包（模組）集合在一起的標準 JAR 檔案，並附帶一個唯一標識應用程式的名稱和版本。PAR 檔案作為一個單一單元部署到平臺中。平臺將從 PAR 中提取所有模組並安裝它們。第三方依賴項將按需即時安裝。

PAR 格式相對於直接將捆綁包部署到平臺有三個主要優點。首先，它更簡單。一箇中等規模的企業應用程式可能包含 12 個或更多捆綁包——手動部署這些捆綁包將過於繁瑣。其次，PAR 檔案在應用程式中的所有捆綁包周圍形成一個顯式的作用域，這可以防止使用重疊型別或服務的應用程式相互衝突。這個作用域也被一些高階功能（如載入時織入）用來確保一個應用程式的織入不會干擾另一個應用程式的織入。最後，PAR 形成了一個邏輯分組，用於定義哪些模組是一個應用程式的一部分，以及應用程式有哪些第三方依賴項。管理工具使用這個分組來提供應用程式的詳細檢視。一個典型的 PAR 應用程式看起來像這樣

應用程式中模組之間的依賴關係通常使用 Import-Package 和 Export-Package 來表達。對第三方庫的依賴也可以用同樣的方式表達，但對於許多庫來說，這可能會出錯且耗時。在使用 Hibernate 等庫時，您通常需要匯入比您最初預期的更多的包。為了解決這個問題，您可以使用 Require-Bundle，但這有一些語義上的粗糙之處，例如拆分包（split packages），其中一個邏輯包被分割到兩個或多個類載入器中，導致執行時出現問題。平臺引入了兩種新的機制來引用第三方依賴項：Import-Bundle 和 Import-Libary。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 語義一致。

平臺理解模組的 personality，並由此推斷如何配置模組的執行環境。部署 Web 模組時，典型 Spring MVC 應用程式所需的所有 Servlet 基礎設施都會自動建立，從而消除了在應用程式之間重新建立這些樣板程式碼的需要。在 1.0 最終版本中，將為 Web 模組 personality 新增更多智慧，以支援 Spring Web Flow 等其他技術。

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

可服務性

可服務性是整個工程團隊的關鍵考量。我們花費了大量時間關注日誌訊息的格式和堆疊跟蹤的大小，以確保診斷應用程式問題儘可能簡單。每當我們發現一項重複且耗時的任務時，我們都會尋找一種方法來將其自動化或完全移除。

為了幫助診斷問題，平臺在日誌訊息和跟蹤訊息之間有清晰的區分。日誌訊息旨在供終端使用者使用，讓您無需翻閱海量跟蹤內容即可訪問最重要的故障資訊。所有應用程式故障都會在日誌輸出中顯示並編碼 - 程式碼是訪問知識庫或支援內容的便捷方式。要理解這為何如此有用，請考慮平臺啟動時的以下輸出：

[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…