脈絡：許多企業用訊息傳遞來整合多套彼此迥異的應用程式。

為什麼多數應用程式接不上來#

多數應用程式當初不是為了搭配訊息基礎設施而設計的，原因很多：

• 許多應用程式被開發成自我完備、獨立運作的方案，卻含有其他系統用得上的資料或功能。例如許多主機應用程式被設計成一應俱全、不需要與其他系統介接。
• 許多訊息導向中介軟體暴露的是專有 API，因此開發者或廠商得為同一個訊息介面提供多套實作。
• 應用程式若需要與別人交換資料，往往被設計成使用較通用的介面機制——例如檔案交換或資料庫表格。讀寫檔案是基本的作業系統功能，不依賴廠商專屬 API；而多數商業應用本來就把資料存進資料庫，因此把要給別的系統的資料存進一張表，額外成本很低。或者應用程式也可能把內部功能開放成通用 API，供任何整合策略（包含訊息傳遞）使用。
• 有些應用程式能以 HTTP 或 TCP/IP 這類簡單協定溝通，但這些協定提供不了 Message Channel 那樣的可靠性，而且應用程式使用的資料格式通常是它自己專屬的，與共通的訊息方案不相容。

對自製應用程式，我們可以在裡面加程式碼來收送訊息，但這會替應用程式引入額外複雜度，還得小心別造成非預期的副作用；而且這需要同時精通應用邏輯與訊息 API 的開發者。若面對的是向第三方買來的套裝應用，我們甚至沒有修改程式碼的選項。

解法#

配接器對訊息系統而言扮演訊息客戶端的角色，同時透過應用程式提供的介面喚起應用程式功能。如此一來，只要有適當的 Channel Adapter，任何應用程式都能連上訊息系統並與其他應用程式整合。

可以接在應用程式的哪一層#

Channel Adapter 可以接到應用程式架構的不同層次，取決於架構本身與訊息系統需要存取的資料。

使用者介面配接器#

有時被貶稱為「screen scraping」，但在許多情境下非常有效：

• 應用程式可能跑在訊息系統不支援的平台上；或應用程式的擁有者對支援整合興趣缺缺——這兩種情況都排除了「在應用程式平台上跑 Channel Adapter」的選項。但使用者介面通常可以從其他機器與平台存取（例如 3270 終端機）。
• Web 式瘦客戶端架構的興起也讓使用者介面整合復甦——HTML 介面讓「發一個 HTTP 請求、剖析結果」變得非常容易。
• 另一個好處是不需要直接存取應用程式內部。有時候把系統的內部功能暴露給整合方案是不被允許或不可行的；用 UI 配接器時，其他應用程式對該系統的存取權與一般使用者完全相同。

缺點是脆弱且慢。應用程式得剖析「使用者」輸入、算繪出一個畫面，只為了讓 Channel Adapter 再把畫面剖析回原始資料——這過程包含大量不必要的步驟。而且使用者介面的變動通常比核心應用邏輯頻繁，介面一改，配接器多半也得跟著改。

業務邏輯配接器#

多數商業應用把核心功能開放成 API——可能是一組元件（EJB、COM 物件、CORBA 元件）或直接的程式介面（C++、C#、Java 函式庫）。

因為軟體廠商（或開發者）是刻意為了讓其他應用程式存取而開放這些 API，它們通常比使用者介面穩定，存取效率也更高。

一般而言，若應用程式有定義良好的 API，這類 Channel Adapter 多半是最佳選擇。

資料庫配接器#

多數商業應用把資料持久化在關聯式資料庫中。既然資訊已經在資料庫裡，Channel Adapter 就能直接從資料庫萃取資訊，而應用程式毫無察覺，非常非侵入式。配接器甚至能在相關表格加上觸發器，資料一變動就送出訊息。

這類配接器效率高且相當通用——關聯式資料庫市場由兩三家廠商主導，這讓我們能用一個相對通用的配接器連上許多應用程式。

缺點是我們在應用程式內部深處東翻西找。單純讀資料的風險或許還好，但直接對資料庫做更新可能非常危險。而且許多應用廠商把資料庫 schema 視為「未公開」，保留隨時更改的權利——這會讓資料庫配接器方案變得脆弱。

重要限制：訊息格式被綁架#

Channel Adapter 能把訊息轉換成應用程式功能，但它要求訊息格式高度貼近被配接元件的實作。例如資料庫配接器通常要求進站訊息的欄位名稱，必須與應用程式資料庫中的表格與欄位名稱相同。

這種訊息格式完全由應用程式的內部結構驅動，不是與其他應用程式整合時該用的好格式。因此多數 Channel Adapter 必須搭配 Message Translator，把應用程式專屬訊息轉成符合 Canonical Data Model 的格式。

部署與方向性#

Channel Adapter 常常可以跑在與應用程式或資料庫不同的電腦上，透過 HTTP、ODBC 之類的協定連到應用邏輯或資料庫。

這種配置讓我們免於在應用程式或資料庫伺服器上安裝額外軟體，但這些協定提供不了訊息通道那樣的服務品質（例如保證送達）。

有些 Channel Adapter 是單向的。例如透過 HTTP 連接應用程式的配接器，可能只能消費訊息並喚起應用程式功能，卻無法偵測應用程式資料的變化。

變體#

• Metadata Adapter（中介資料配接器），有時稱 Design-Time Adapter——它不喚起應用程式功能，而是萃取中介資料，也就是描述應用程式內部資料格式的資料。這些中介資料可用來設定 Message Translator，或偵測應用程式資料格式的變化。許多應用程式介面支援中介資料萃取：多數商業資料庫提供描述應用表格的系統表；多數元件框架（J2EE、.NET）提供「反射」功能，讓一個元件能列舉另一個元件提供的方法。
• Messaging Bridge——Channel Adapter 的一種特殊形式，它連接的是另一套訊息系統而非特定應用程式。

Channel Adapter 通常被實作成 Transactional Client，以確保它做的每一件工作在訊息系統與被配接的另一個系統中都成功。