簡介

上週，Mark Fisher 向各位介紹了經過重新架構和簡化的新 Spring Integration 範例，這些範例隨著 Spring Integration 1.0.3 新版本的發佈而推出，到目前為止，回饋非常正面。除了重新架構和簡化現有的範例之外，我們還推出了一些新的範例，目的是展示在 OSGi 平台上執行 Spring Integration 的一些優點。在本部落格中，我們將使用一個非常簡單但功能強大的範例，來探討 Spring Integration 和 OSGi 共同用於解決當今企業動態特性的一些優點。

Spring Integration 是一個基於 POJO 的輕量級、可嵌入式訊息傳遞框架，具有鬆散耦合的程式設計模型，旨在簡化基於 企業整合模式 的異質系統整合，而無需單獨的 ESB 類型的引擎或專有的開發和部署環境。另一方面，OSGi 是一種範例，允許人們從稱為 OSGi 捆綁包的獨立模組中組合鬆散耦合的系統。從一組獨立開發的模組組合系統可能不是一個新的範例，我們（希望）已經這樣做了很多年。話雖如此，OSGi 模組化的真正好處將不是來自其靜態封裝模型，而是來自理解其部署和執行階段的動態特性，以及它在多大程度上能夠解決當今業務流程的動態性。

因此，讓我們透過簡單的範例，了解基於訊息交換和 OSGi 動態性的整合如何相互補充，從而實現非常強大且動態的系統。

Spring Integration 範例隨 Spring Integration 的發行版一起提供。您也可以從此處獨立下載它們。為了簡單起見，這些範例是作為 SpringSource Tool Suite (STS) 專案開發的，同時利用 dm Server 工具與 SpringSource dm Server（一個基於 OSGi 和 Spring 的企業 Java 平台）快速整合。然而，作為基於 OSGi 相容性的專案，這些範例將在任何正確配置的 OSGi 平台上充分執行。

環境

首先，讓我們確保我們有一個正確配置的開發/部署環境。

若要設定 STS/dm Server 環境，請依照下列步驟操作

從 此處 下載並解壓縮 STS 從 此處 下載並解壓縮 SpringSource dm Server

Spring Source Tool Suite v2.1.x 將預先配置 SpringSource dm Server，但是了解如何手動配置它仍然有幫助。

開啟 STS 並配置 dm Server： 開啟伺服器檢視 -> 在伺服器檢視中的空白處按一下滑鼠右鍵 -> 新增 -> 伺服器

選取 SpringSource -> SpringSource dm Server v1.0 -> 下一步

指向您安裝伺服器的根目錄

按一下完成

您現在已在 STS 環境中配置了 SpringSource dm Server。啟動 dm Server 並確保它成功啟動且沒有錯誤。

假設您已經下載了 Spring Integration 範例，因此讓我們使用 STS/Eclipse 提供的將現有專案匯入工作區精靈將兩個範例專案匯入工作區。檔案 -> 匯入 -> 一般 -> 將現有專案匯入工作區 -> 下一步 瀏覽至範例目錄的位置並選取 osgi-inbound 和 osgi-outbound 專案

按一下完成 您應該會看到兩個有錯誤的專案。

這些錯誤是預期的，因為我們的專案不知道 dm Server 目標執行時期，而我們的 dm Server 目標執行時期不知道 Spring Integration 捆綁包。讓我們一次解決一個問題。首先，讓我們透過將 Spring Integration 和相依的捆綁包部署到 dm Server 的儲存庫中，讓 dm Server 知道 Spring Integration。這是一個非常簡單的過程。將 org.springframework.integration-1.0.3.RELEASE.jar 和 org.springframework.integration.file-1.0.3.RELEASE.jar （我們的範例所依賴的兩個捆綁包）複製到 dm Server 的 repository/bundles/usr 目錄中。然後在 STS 的伺服器檢視中，按兩下 dm Server 的執行個體 -> 按一下儲存庫標籤，在右上角您會找到一個重新整理按鈕。按一下它，您應該會看到這兩個捆綁包在 dm Server 的儲存庫中可用。

現在我們需要讓我們的捆綁包專案知道我們新的目標執行時期。在每個專案上按一下滑鼠右鍵 -> 內容 -> 目標執行時期 -> SpringSource dm Server (Runtime) v1.0

現在所有錯誤都應該消失。您已準備好測試這些範例

範例

這兩個範例建立在非常簡單且熟悉的生產者/消費者概念之上。第一個捆綁包 osgi-inbound 是一個生產者，它將允許您產生一個訊息，該訊息將被傳送到訊息通道。第二個捆綁包 osgi-outbound 是一個消費者，它將消費 osgi-inbound 捆綁包放置在通道上的訊息，並將訊息寫入檔案。

透過在伺服器執行個體上按一下滑鼠右鍵來啟動 dm Server -> 啟動

透過簡單地將 osgi-inbound 專案拖放到 dm Server 執行個體上來部署 osgi-inbound 。在幾秒鐘內，您應該會看到成功啟動訊息

[2009-07-27 21:56:49.040] onnection(5)-172.16.12.1 <SPDE0010I> Deployment of 'org.springframework.integration.samples.osgi.inbound'
version '1.0.3' completed.

然後對 osgi-outbound 捆綁包執行相同的操作

[2009-07-27 21:58:45.220] onnection(8)-172.16.12.1 <SPDE0010I> Deployment of 'org.springframework.integration.samples.osgi.outbound'
version '1.0.3' completed.

現在您已準備好測試這些捆綁包提供的功能。為了使其更有趣，我們透過 OSGi 主控台啟用了命令列介面 (CLI)，這允許您透過提供命令、訊息和您想要將訊息寫入的檔案名稱與 osgi-inbound 捆綁包互動。您可以透過以下方式連線到 OSGi 主控台

telnet localhost 2401

或者您可以使用伺服器檢視的伺服器主控台標籤並輸入

siSend "Hello World" hello.txt

然後按一下執行

您將看到以下內容

前往並驗證您的訊息是否已寫入檔案。

這個非常簡單且微不足道的概念示範了兩個系統之間基於 Spring Integration 提供的訊息傳遞模型的鬆散耦合整合。然而，在現實世界中，當我們嘗試整合兩個系統時，我們必須面對的問題之一是這些系統的獨立生命週期，其中其行為的變更、新增系統和/或舊系統的生命週期結束是一種正常現象。通常，此類變更不僅需要程式碼變更，還需要重新部署整個單體式（例如，EAR、WAR）應用程式，並在完成伺服器重新啟動後進行。Spring Integration 的 POJO 程式設計模型非常適合解決這些系統的鬆散耦合特性，其中對一個系統的變更很少影響另一個系統。但是它的生命週期動態性呢？讓我們假設（在我們的小範例範圍內）關於檔案必須寫入的位置或方式的要求已變更。「位置」和「方式」都是 osgi-outbound 捆綁包的責任。在正常情況下，對 osgi-outbound 捆綁包功能的任何變更都需要完全重新整理系統（即，重新部署整個系統和伺服器重新啟動）。當您的系統僅由兩個捆綁包組成時，這可能不是一個大問題。但是，如果超過兩個呢？您是否準備好僅僅因為必須寫入訊息的目錄已變更，或者引入了應該記錄每個傳入訊息的新子系統而重建和重新部署整個系統（封裝為 WAR 或 EAR）？

這就是 OSGi 及其服務層，以及最重要的 OSGi 服務動態性提供巨大幫助的地方。因此，讓我們採用上述範例要求，看看如何根據擴展目前的範例來實現這些要求。首先，讓我們檢閱 osgi-inbound 捆綁包的應用程式內容配置

<osgi:service id="inboundService" ref="inboundChannel"
interface="org.springframework.integration.channel.SubscribableChannel"/>

<integration:publish-subscribe-channel id="inboundChannel"/>

<integration:gateway id="inboundGateway"
service-interface="org.springframework.integration.samples.osgi.inbound.InboundGateway"
default-request-channel="inboundChannel"/>

如您所見，一個非常簡單的配置，它定義了一個閘道代理，允許以 POJO 方式傳送將被放入配置為發佈-訂閱通道的輸入通道的訊息。然而，更令人感興趣的是，此通道已透過 <osgi:service/> 元素作為服務匯出到 OSGi 服務登錄檔，從而在目前和未來的捆綁包之間實現更鬆散耦合但動態的協作模型。

讓我們也檢閱 osgi-outbound 捆綁包的應用程式內容配置。

<osgi:reference id="filesIn"
interface="org.springframework.integration.channel.SubscribableChannel"/>

<file:outbound-gateway id="filesOut"
request-channel="filesIn"
directory="${java.io.tmpdir}/spring-integration-samples/output"
delete-source-files="true"/>

此捆綁包的目標是在 osgi-inbound 捆綁包啟動後立即動態訂閱由其宣傳的通道，並將訊息寫入由 <osgi:service/> 元素配置的目錄中的檔案，從而考慮到 OSGi 服務層提供的動態性。正如您在此配置中看到的，由 osgi-inbound 捆綁包匯出的 'inboundChannel' OSGi 服務現在透過 <osgi:reference/> 元素匯入。現在，由 OSGi 服務作為前端的輸入通道已準備好在執行階段動態接受和/或失去訂閱者。由於 OSGi 服務動態性，我們也可以更新配置或完全重新設計/重新實作 osgi-outbound 捆綁包，而不會影響系統的生產部分 (osgi-inbound)。因此，讓我們繼續並變更將寫入檔案的目錄（確保 dm Server 仍在執行中...實際上，在本部落格的持續時間內忘記停止它）

開啟 osgi-outbound 專案 -> src -> META-INF -> spring -> osgi-outbound.xml 並將子目錄新增至 'directory' 配置（在本例中為 'foo'） 儲存檔案。在幾秒鐘內，您將看到您的 osgi-outbound 捆綁包已重新部署 開啟 OSGi 或伺服器主控台，並像之前一樣傳送另一個訊息，看看新檔案是否已寫入您剛才指定的目錄。希望它是 ;)

結論

請記住，雖然在這個微不足道的範例中，我們只處理兩個捆綁包，但這些類型的生產者/消費者捆綁包本身可能是您系統其他部分的閘道，而這些部分自然是動態的。例如，讓我們假設您想要接收關於檔案已寫入的電子郵件通知。使用 SI 和 OSGi，您唯一需要做的是建立另一個捆綁包，以將您子系統的該部分表示為 osgi-inbound 捆綁包宣傳的通道服務的消費者，當您不需要它時 - 取消訂閱，透過停止或取消部署此消費者，而不會影響系統的其餘部分。實際上，繼續並嘗試開發另一個捆綁包作為 osgi-inbound 的消費者，或發揮您的想像力並開發另一個捆綁包，該捆綁包將對 osgi-outbound 捆綁包寫入的檔案執行某些操作。

如需更多想法和更複雜的範例，您也可以閱讀 Spring Integration 團隊成員 Iwein Fuld 的 這篇文章

最重要的是 - 整合愉快！！！