本書刻意把「整合」定義得很寬——它指的就是把電腦系統、公司或人連起來。這個寬鬆定義帶來的便利是，任何我們覺得有趣的東西都能塞進書裡；但仔細看看最常見的幾種整合情境仍然有幫助。

作者在協助客戶設計與實作整合方案的過程中，反覆遇到以下六類整合專案：

• 資訊入口（Information Portal）
• 資料複寫（Data Replication）
• 共享商業功能（Shared Business Function）
• 服務導向架構（Service-Oriented Architecture）
• 分散式商業流程（Distributed Business Process）
• 企業對企業整合（Business-to-Business Integration）

這份清單絕不是整合世界的完整分類法，但它足以說明整合架構師實際在建造什麼樣的東西。許多整合專案是多種類型的組合——例如為了把應用程式串進單一分散式商業流程，往往得先做參考資料的複寫。

資訊入口#

許多業務使用者為了回答一個問題或完成一項業務功能，得存取不只一套系統。例如要確認訂單狀態，客服人員可能得存取主機上的訂單管理系統，還要另外登入處理網路訂單的系統。

資訊入口把多個來源的資訊匯總到單一畫面，讓使用者不必四處奔波：

• 簡單的入口把畫面切成多個區塊，各自顯示不同系統的資訊。
• 進階的入口提供區塊之間有限的互動——例如在 A 區選了一筆項目，B 區就刷新顯示該項目的細節。
• 更進階的入口提供更複雜的使用者互動，此時「入口」與「整合後的應用程式」界線已經模糊。

資料複寫#

許多業務系統需要存取同一份資料。以客戶地址為例：客服系統（客戶打來改地址時）、會計系統（計算銷售稅）、出貨系統（列印貨運標籤）與帳務系統（寄發票）都會用到，而且這些系統多半各有自己的資料儲存。客戶一改地址，所有系統都得更新自己那份副本——這就得靠以資料複寫為基礎的整合策略。

實作方式很多：有些資料庫廠商把複寫功能做進資料庫；也可以匯出成檔案再匯入另一套系統；或用訊息導向中介軟體，把資料紀錄裝進訊息裡搬運。

共享商業功能#

商業應用不只常有重複的資料，也常有重複的功能。多套系統可能都要檢查社會安全號碼是否有效、地址是否與郵遞區號相符、某項商品是否有庫存。把這些功能實作一次、以服務形式開放給其他系統使用，在商業上很合理。

共享商業功能與資料複寫可以解決部分相同的需求。例如可以實作一個「取得客戶地址」的商業功能，讓其他系統需要時再來要，而不是永遠存一份多餘的副本。兩者如何取捨，取決於幾項判準：

• 對系統的控制程度——呼叫共享函式通常比把資料塞進資料庫更具侵入性。
• 變動頻率——地址可能被頻繁讀取，卻很少改變。

服務導向架構#

共享商業功能常被稱作服務（service）：一個定義良好、普遍可用、回應「服務消費者」請求的功能。

當企業累積出一批有用的服務後，管理服務就成了重要工作：

1. 應用程式需要某種服務目錄——一份集中的可用服務清單。
2. 每個服務都要描述自己的介面，讓應用程式能與它「協商」出一份通訊契約。

SOA 讓「整合」與「分散式應用」的界線變模糊：新應用程式可以直接用其他應用程式提供的既有遠端服務來開發，因此呼叫一個服務可以視為兩套應用之間的整合；但另一方面，SOA 通常也提供工具，讓呼叫外部服務幾乎和呼叫本地方法一樣簡單（先撇開效能考量）。因為所有服務都以一致的方式提供，SOA 有時也被稱作「服務匯流排架構」。

分散式商業流程#

推動整合最關鍵的原因之一是：一筆商業交易往往橫跨許多不同系統。前面提過，「下訂單」這樣一個簡單功能，就輕易碰到六、七套系統。

多數情況下，所有相關功能其實都已經在既有應用程式裡了，缺的是應用程式之間的協調。因此我們可以加入一個商業流程管理元件，來管理某項商業功能跨多套既有系統的執行。

SOA 與分散式商業流程之間的界線同樣可能模糊——例如你可以把所有相關商業功能都開放成服務，再把商業流程編碼在一個透過 SOA 存取這些服務的應用程式裡。

企業對企業整合#

以上主要談企業內部應用程式與商業功能的互動。但很多時候，商業功能來自外部供應商或商業夥伴：貨運公司可能提供計算運費或追蹤貨件的服務；企業也可能用外部供應商計算銷售稅率。夥伴之間的整合也很常見——客戶向零售商詢問某項商品的價格與供應狀況，零售商轉而向供應商查詢那批缺貨商品的到貨狀態。

上述考量多半同樣適用於 B2B 整合，但跨網際網路或其他外部網路溝通時，通常會多出傳輸協定與安全性的新議題。

由於可能有許多商業夥伴共同參與一場電子「對話」，標準化的資料格式在這個情境中至關重要。