鬆散耦合的整合方案 • 企業整合模式

要透過整合方案連接兩套系統，得發生一連串事情。這些事情組成的東西，就是我們所謂的中介軟體（middleware）——夾在應用程式之間的那些東西。

基本元素：通道與訊息#

無論如何，總得有資料從一個應用程式搬到下一個。這份資料可能是一筆待複寫的地址紀錄、一次遠端服務呼叫，或一段要送進入口網站顯示的 HTML。不論內容為何，它都必須被兩端理解，並且（通常）跨網路傳輸。

提供這項基本功能的有兩個元素：

通道（channel）——把資訊從一個應用程式搬到另一個的通訊路徑。它可以是一串 TCP/IP 連線、一個共享檔案、一個共享資料庫，甚至是一片被人從這台電腦拿到那台電腦的磁片（惡名昭彰的「球鞋網路」）。
訊息（message）——放在通道裡的一小段資料，其意義是待整合的兩個應用程式都同意的。它可以很小（某位客戶剛改掉的一組電話號碼），也可以很大（全部客戶與其地址的完整清單）。

有了通道與訊息，就能建立最基本的整合。但「簡單整合」是矛盾修辭，所以我們來看還缺什麼。

整合方案通常無法控制它所整合的應用程式，包括它們的內部資料格式：

因為應用程式的內部資料格式往往改不動，中介軟體就必須提供把一方格式轉成另一方格式的機制——這一步稱為翻譯（translation）。

現在能送資料、也能容納格式差異了。但若整合的系統超過兩套呢？資料該搬去哪裡？

一種作法是要求每個應用程式自己指定目標系統。例如客服系統裡的客戶地址一改，就由客服系統負責把資料送到所有存有客戶地址副本的系統。

隨著系統數量增加，這會變得極度繁瑣，而且要求送件系統知道所有其他系統的存在——每新增一套系統，客服系統就得跟著改。

如果中介軟體能負責把訊息送到正確的地方，事情會輕鬆得多。這正是路由元件（例如訊息中介者，message broker）的職責。

整合方案很快就會變複雜，因為它同時處理多套應用程式、多種資料格式、通道、路由與轉換，而這些元素還可能散落在多個作業平台與地理位置。

要對系統內部發生的事有任何掌握，就需要一個**系統管理（systems management）**功能：監控資料流動、確保所有應用程式與元件都可用，並把錯誤狀況回報到一個集中的地方。

到這裡，我們能搬資料、容納格式差異、把資料路由到需要的系統，也能監控方案的運作狀況了。

但前面一直假設「應用程式會把資料當成訊息送進通道」。事實上，多數套裝與遺留應用程式、以及許多自製應用程式，根本沒有準備好參與整合方案。因此我們需要訊息端點（message endpoint），把系統明確地接上整合方案。

端點可以是一段特製的程式碼，也可以是整合軟體廠商提供的通道轉接器（Channel Adapter）。