隨著 IT 產業日益成熟，我們將目睹越來越多成功的面向服務的體系結構（Service-Oriented Architecture，SOA）的設計和實現的出現。我們同樣也將面對以微妙不同的形式重復出現、但從根本上來說卻具有相同的基本問題的挑戰。我們也傾向于重復使用解決方案的稍有不同的變體。為了達到這一目的，在涉及面向服務的體系結構和面向服務的集成（Service-Oriented Integration，SOI）的項目環境中引出了下面的模式。這些項目專注于面向服務的體系結構的遷移、建模、設計和實現，以及通過服務支持的松耦合集成，這稱為面向服務的集成。在這個系列中，我們將分享這些模式以及使用它們的經驗。我們將就如何結合使用它們以便幫助解決在 SOA 和 SOI 的遷移、建模、設計和實現過程中通常會遇到的問題提供指導。
引言：SOA 采用和 SOA 方法
單一的 SOA 解決方案很少恰好合適，理解這一點變得日益重要。相反，應該根據組織的方法和成熟度來量身定做 SOA 解決方案，以便確保一條更平坦的采用和成功之路。SOA 的采用分四個層次，正如下面的表 1 中所確定和解釋的。
在采用和結合面向服務的體系結構 (SOA) 方面，企業可能處于不同的成熟度。一些企業僅僅是剛剛開始探索 SOA 的世界，使用其技術范例：Web 服務。它們將遺留功能包裝起來，再向第三方、客戶和業務伙伴公開以供調用。這就把它們帶入了這場游戲：逐漸建立起開發團隊，開始改變企業文化以便更好地支持 SOA 的流程，并且在探索新技術和可能受到影響的業務能力方面邁出第一步。這是第一個層次。
SOA 采用的第二個層次是在成功地通過 Web 服務的最初測試后，現在這個組織開始使用服務來集成系統和應用程序。這一步超出了企業應用程序集成（Enterprise Application Integration，EAI）。隨著專有協議、粘接代碼 (glue code)、更加開放的點到點連接、基于標準的協議和基于每個系統外化的服務描述的交互的出現，我們步入了面向服務的集成的領域。在這一領域中，企業服務總線占據最重要的位置：在不必考慮目標服務的提供者的情況下協調、路由和轉換服務調用的機制。它有助于克服與點到點連接有關的許多缺點。
表 1. SOA 采用的層次
|
采用層次
|
名稱
|
描述
|
| 1 |
實現單獨的 Web 服務 |
由新的或現有的應用程序中所包含的任務來創建服務 |
| 2 |
業務功能的面向服務的集成 |
通過跨企業內外的多個應用程序集成服務來實現業務目標 |
| 3 |
整個企業范圍的 IT 轉換 |
支持跨整個企業的業務功能的集成的體系結構實現 |
| 4 |
隨需應變的業務轉換 |
現有業務模型的廣泛轉換或者新的業務模型的部署 |
創建 SOA 的六種方法
據說在駕駛飛機時，起飛和降落是最困難的兩件事情。您可以使用各種各樣的方法模式在飛機跑道上降落，這取決于由天氣、交通密度、風速等等因素決定的空中交通控制指導。成功地創建 SOA 同樣也有至少六種方法。
一些客戶希望從他們的業務流程開始，然后繼續開發支持這些流程所需的服務。而其他一些客戶在遺留系統中擁有現有的功能，他們希望將其公開給客戶、合作伙伴以及服務生態系統。后一種方法的一個重要的變體是，功能是嵌入式的而不能容易地訪問，所以需要完成相當數量的遺留轉換和組件化，以便將功能提取出來并將其作為服務公開——而它是否將是一個良好的服務則是另外一回事。我們將在另一篇文章“Service Litmus Test”中解決這個問題，并且提出確定是否確實應該公開某些內容的標準。處理 SOA 的另外一種自頂向下的方法是借助模型驅動的體系結構（Model-driven architecture，MDA）工具，以便定義可以生成代碼的模型來構建服務。到目前為止，我們已經考慮了兩種自頂向下和兩種自底向上的方法。
其他項目需要提供對數據及與該數據相關聯的狀態的訪問。這是 SOA 的信息體系結構或者數據體系結構方法。然而，一些項目試圖去集成系統，它們更關心的是如何通過消息傳遞而不是其他什么方式來集成系統和應用程序；沒有崇高的業務驅動的理想和合作伙伴對內部流程的訪問，只有通過消息傳遞進行的系統集成的定義。
表 2. SOA 的六種方法
|
方法
|
描述（典型的項目所有者的特性描述）
|
限制條件
|
| 業務流程驅動 |
我的業務流程需要接進資源，而且每個活動都需要調用 IT 功能；我希望該功能能夠以一種靈活的、可替代的方式使用。 |
自頂向下 |
| 基于工具的 MDA |
我希望定義一個模型（業務模型），然后由工具為我生成具體細節。 |
自頂向下 |
| 包裝遺留 |
我擁有已經進行了大規模投資的現有系統，但是它們不具有可伸縮性。我想要快速地添加新的功能，但是這些系統是分離的。它們就像個地窖，功能封閉在其中。 |
自底向上 |
| 組件化遺留 |
使用基于編譯器的工具將整個龐大的遺留系統分解成模塊。 |
自底向上 |
| 數據驅動 |
使用服務來提供對信息的訪問，而不必在提供者端公開 Schema 或者實現決策。 |
專注于數據 |
| 消息驅動 |
“僅僅希望這些系統通過標準的、非專有的協議進行集成、通信。” |
應用程序和系統的面向服務的集成 |
模式語言背景
概述
隨著一個組織在朝更靈活和健壯的體系結構（伴隨著快速變更的業務需求）邁進的道路上逐漸成熟，它將做兩件事：a）選擇專注于一組核心的差異化計劃，這些計劃以核心競爭力為中心，b）朝級別越來越高的人員、合作伙伴、流程以及數據的松耦合和可動態重組集成的方向前進。請注意，由現有的服務構建復合應用程序來動態重組是關鍵。通過這種方法，可以在企業內部和外部以可重用的方式公開服務。
當組織開始轉向 SOA 時，采用的主要方法之一或者進入 SOA 世界的入口就是通過面向服務的集成 (SOI)。提議這樣做的重要價值之一是利用 IT 系統中現有的投資，而不是重新改寫/重新編寫新的。實際上，服務集成比企業應用程序集成更進一步，將使用最少的“粘接代碼”，通過非專有的協議來定義和利用松耦合的服務集。這種方法的關鍵在于兩點，一是將服務作為關鍵啟動程序進行訪問，二是生態系統中多個系統甚至業務伙伴之間的數據和處理的交互。
為了使這種 SOI 方法獲得成功，而且為了從 IT 系統方面的實際觀點出發并逐漸朝著企業中服務演化的方向前進，我們需要克服一些主要障礙或者說挑戰。這些問題的涵蓋范圍看起來非常廣泛，從簡單的、幾乎瑣碎的問題，到日益復雜的問題，隨著我們在使用和實現 SOA 并獲得相應的業務和 IT 好處方面更加成熟，我們將遇到這些必須解決的問題。這里所概述的模式有助于解決這些挑戰；每種挑戰一個模式。隨著我們的研究逐漸深入，我們發現一種趨勢——我們正使用更細粒度的模式來構建日益復雜的解決方案，以便解決更加復雜的問題。例如，不是從第一天就立即擁有 ESB，我們可能發現，從一個服務策略開始，創建一些服務適配器和代理，轉到虛擬提供者，接著到服務集成器，然后才是 ESB，這樣更明智。這些模式的使用將依賴于對項目的實際考慮，您將在不同的項目中有區別地使用它們，正如 Alexander 所說的，“不要以相同的方式做同一件事兩次”。
通常，最初的挑戰是具體確定在項目、業務部門或者組織內部提議使用 SOA 的價值。這涉及到在實現服務的實際服務提供者的服務質量下降或者他們不能提供所需要的功能時改變實際服務提供者的靈活性和能力。這種靈活性是 SOA 的首要價值，而這種挑戰可以通過了解借助遠程服務策略獲得靈活性的步驟來克服。我們還將描述另外兩種挑戰，并使用這里提出的模式加以克服。
這些模式構成了模式語言的核心，當您達到 SOA 采用的成熟度的較高級別時，將涉及各種圍繞 SOA 和 SOI 產生的問題（如下面的圖 1 所示）。通過增加服務集成度的增量采用來遷移到 SOA 的組織一般從具有專有接口和粘接代碼的強耦合系統開始，遷移到部分公開的服務之間的點到點連接，而這些服務通常僅僅包裝現有的功能并使其可訪問。這兩點代表了實現 SOA 全部潛能的過程中的前兩個步驟。每個步驟都代表更高的成熟度以及在商業價值和 IT 利益方面相應的增加。例如，為了迅速地支持對現有功能的訪問，難以訪問的嵌入式功能的點到點公開 (Point-to-Point Exposure) 是邁出硬編碼地窖的重要一步。這些地窖包含嵌入式并且通常難以訪問的功能。組織常常借助于創建在其他環境中本身難以訪問的冗余功能，而不是費力地訪問難以訪問的嵌入式功能。在通常情況下，應用程序組合（換句話說就是，減少）可以通過確定不同系統中的共同功能，提取、隔離并封裝最有希望的功能，然后提供單一訪問點 (Single Point of Access) 來實現，以便簡化維護、降低成本并支持合并和采購期間的快速合并等。
下面的表 3 中提到的模式是從各種項目中“挖掘”出來的 SOA 和 SOI 模式的一部分：
表 3. 模式及其相應的好處
|
環境
|
模式
|
適用性
|
| 封閉；集中的功能 |
硬編碼的（不是模式，而是時間狀態的一點） |
時間點；低風險；少變化、高性能系統 |
| 分布式的；多點訪問 |
點到點公開 |
迅速公開現有的功能；快速釋放價值；訪問嵌入式功能 |
| 包裝遺留的功能，使其可以通過 Web 服務來訪問 |
服務適配器 |
用戶需要訪問不支持服務的功能（通過服務調用訪問遺留系統，例如——Web 服務） |
| 如果您不能直接訪問服務提供者的服務描述并且不能直接調用服務，那么使用它的代理來訪問服務 |
服務代理 |
向使用者提供 SOA 接口 |
| 提供選擇服務提供者的靈活性 |
遠程服務策略 |
提供根據服務質量或者功能考慮事項改變服務提供者的靈活性。這使得在合并應用程序組合時加速合并和采購以及靈活地改變提供者成為可能。 |
| 消除冗余的功能；重構和合并或者在某些情況下替換現有的系統 |
單一訪問點 |
給功能的許多潛在變體提供一個訪問點。一種服務策略通常需要一個單一訪問點。 |
| 某一時刻，一個項目或業務部門依賴于其他項目或業務部門的某些尚未作為服務公開的功能 |
虛擬提供者 |
不存在的提供者；提高服務的關鍵部分 |
| 單一訪問點 |
服務集成器 |
路由、轉換 |
| 常規企業集成方法 |
企業服務總線 |
中介；路由；轉換、策略、規則、事件；在生態系統/價值網中的組織內部或者合作伙伴之間 |
| SOA 的涅磐 (Nirvana of SOA)；通過依賴于業務領域特定的功能的環境識別服務進行動態重新配置 |
集成的服務生態系統 |
向一組語義相關的行業特定的業務合作伙伴提供動態配置功能，這些合作伙伴利用并重組生態系統的功能來給自己以及作為一個整體的生態系統提供更大的價值 |
對于給定的情況，下表中的每個點都可能是合理的或適當的，向圖譜的右側移動并不總是要做的正確事情或者要采用的解決方案。級數表示逐漸增加的成熟度以及需要更多的成熟來處理不斷增加的復雜性和克服 IT 所經受的新的、更加令人生畏的業務挑戰。
圖 1. 邁向集成的服務生態系統的 SOA 和 SOI 的模式圖譜上的點
下面的部分將介紹一些構成 SOA/SOI 的模式語言基礎的基本模式。“基本的”的意思是指客戶往往首先碰到與這些模式有關的問題，需要解決它們，以便在 SOA 的方向上繼續前進。SOA 是一個漸進的、小的轉換旅程，逐漸將服務描述從由多個服務提供者所提供的服務實現中分離開來。下面的解決方案描述了這些問題是如何循環地解決的，并且可以作為模式用于下一個項目，以助您一臂之力。就像任何其他模式一樣，這些模式同樣也需要調整以適合環境和形成您個人的問題空間的強制要求：項目的利弊和需要考慮的事項，無論它們是組織上的還是技術上的，都非常重要，而且您可以決定是否需要跳過從一個模式到另一個模式的步驟，或者部分地實現該模式。
模式的討論和模式的環境
大部分組織都有多種異構后端遺留系統，而只支持投資其中的一些來參與 SOA。通常，組織分為多個業務部門，其中每個業務部門都可能擁有整套系統的一部分，并且不能控制支持單一業務流程的一組水平應用程序。因此，業務流程可能跨越多個業務部門，涉及不同的系統所有者。每個系統將支持（用來更新或者創建）業務流程的一部分。在這個端到端流程中，并不是每個參與者都有機會獲得資助，或者同意進行 SOA 遷移，或者適時地這樣做。因此，一個組織單位決定將其功能遷移到 SOA 并不意味著其他提供依賴功能的業務部門或合作伙伴同意這樣做，注意到這一點非常重要。
因此，在初始階段，向 SOA 遷移的努力包括組織必須克服的學習和集成曲線。例如，SOI 模式虛擬提供者有助于為此搭橋鋪路。企業可以利用、更改或者加強現有的基礎設施、系統、管理和策略，以增量的方式遷移到 SOA，從而克服這些問題。服務提供者可能依賴于一組由生態系統中其他業務部門或組織提供的外部服務。這些服務在特定時刻可能并未準備就緒，或者不滿足服務質量要求。虛擬提供者模式可以幫助解決這個問題，它允許期望的提供者在服務使用者端創建 SOA 以及在服務提供者端創建服務的虛擬提供者。它所依賴的任何一個系統都有可能還沒有準備好就完全地遷移到 SOA。在過渡時期，服務使用者可以使用虛擬提供者來前進、構建 SOA，并且一旦提供者的服務的實際 SOA 實現開始工作，就可以通過服務策略鏈接到提供者的服務。虛擬提供者就緒后，在 SOA 中創建集成層就變得更加容易了。接著您就可以應用服務集成器來更好地充實這個層次。集成層的完備和好處是伴隨企業服務總線的創建而獲得的。
[遠程]服務策略可以單獨使用，也可以與其他兩個主要的模式一起使用。這個模式從本質上來說模仿了多態的概念，將其用于服務，并且具體化了策略設計模式（但不是從面向對象的角度）。實際上，它適用于遠程調用的面向服務的領域，在這個領域中，需要允許靈活地重新分配和遷移到新的端點，從服務使用者角度來看，這可以以一種更經濟、可伸縮、可兼容且一致的方式提供服務。因此，當使用者需要更改非功能性需求時，或者當當前的提供者偏離了想要的交付功能性或非功能性需求的方法時，可以使用服務策略重新分配其他的服務提供者作為服務端點，這種方式對應用程序和基礎設施的改變最少。本質上，您從一組更保守的不成熟的 Web 服務轉移到一個具有單一訪問點的更成熟的 SOA，從而消除了冗余，提供了一致性的注冊中心、儲存庫和代理。請注意，我們并沒有選擇術語“網關 (Gateway)”，雖然它可能是一個更合適的詞，但這里的意思是指在這個領域開發的產品，例如 Web Service Gateway 產品。在這里，我們專注于業務功能的統一訪問點的功能性方面。
所以，如果您問，“為了通過服務集成到達 SOA 的最終狀態，究竟什么才是基于服務總線增量遷移到立體集成（層）體系結構的跳板呢？”第一種模式從靈活性的角度討論了 SOA 的價值。第二種模式是關于創建關鍵部分來啟動您的 SOA 并使其在企業中運行。而第三種模式是關于將虛擬提供者帶到下一層，作為服務集成器。您遲早都會希望將實現再向前推進一步，即 ESB。
這里我們描述了為了實現這個目標您可能需要采取的步驟。請注意，在某些情況下，如果組織的文化和工具、技術以及中間件都就緒，那么您可能直接就到了 ESB。對于組織中更成熟的部分這可能也是可行的，而應用程序的某些部分則需要您手動操作，通過這里所描述的模式小心翼翼地將其逐步遷移到其他選定的部分。
模式 1：遠程服務策略
環境和問題：這是策略設計模式的變體，可以在 SOA 的體系結構環境中應用。它處理與松耦合有關的問題，并在我們希望根據例如輸入環境或者不同服務提供者能夠提供的服務質量特征靈活地改變服務實現時使用。純粹的面向對象的策略模式主要依賴于基于繼承的多態來創建根據環境交換的可互換算法系列。在 SOA 環境中，我們需要的不是擁有一個對象層次結構，而是能夠改變服務提供者，同時將對使用者的服務感知的影響降到最低程度或者根本沒有影響，從而改變服務描述的實際實現者。在大部分情況下，實現者可以是內部網或 Internet 上某處的遠程功能單元的提供者。因此，例如，可能需要改變 OrderEntry 應用程序中的 VerifyAddress 服務的服務提供者，因為出于更大的交易量或者安全約束的原因，我們的服務質量需求發生了改變。或者，提供者已經決定將我們過去所依賴的同一基本服務的價格提高一倍。現在，我們希望能夠在 IT 和業務不受損害的情況下靈活地改變服務提供者，這就意味著將對 IT 系統的改變降到最低程度并且不對業務或者客戶的在線購物體驗造成影響。
圖 2. SOA 提供的靈活性
在許多情況下，服務提供者是遠程的，而綁定到實際實現者是通過 Web 服務綁定（WSDL 接口的 SOAP 調用，可能發現或預設為一個給定的 URI）來實現的。
解決方案：不是將訪問和通信機制硬編碼到服務提供者，而是創建一個服務層將您所需要的服務接口從可能的服務實現者層——例如企業組件層 (Enterprise Component Layer)——分離出來。這就提供了改變實現服務接口的服務提供者的靈活性，同時又不必對 IT 系統的代碼做大的改變。“重新配置”，而不是硬編碼的自定義，是這個策略的名稱：提供靈活性的可動態重新配置的體系結構樣式正是提議 SOA 的關鍵價值之一。
圖 3. 顯示遠程服務的可選策略
結果和變體：實現這個模式有不同的程度。您可以從更高的耦合度開始，然后遷移到較低的耦合度。URI 沒有硬編碼到現有服務提供者的 WSDL，這就可以通過創建提供者的服務注冊中心和動態改變提供者（UDDI 和 LDAP 等等）來獲得改變提供者的能力。如果需要更進一步的動態程度，那么發現和協商流程就會出現在注冊中心，它并不受您的控制，而是由外部服務代理提供，這個服務代理將為您找到“最合適的”或者“最匹配的”的服務。
請注意，這里需要標準化的語義，以便方便地改變服務提供者。幸運地是，在多個行業的不同業務領域中出現了一套標準，它們可以構成在更復雜的場景中改變提供者所需要的語義的基礎。
模式 2：服務適配器
（也稱為服務包裝器）
環境和問題：服務適配器的目標是提供使非面向服務的系統能夠參與到面向服務的體系結構之中的機制
這樣的服務通常都是不能提供 SOA 所指定的清晰定義的、大粒度的接口類型的遺留系統或打包的應用程序。這常常是一個反復出現的問題，因為現在許多核心業務流程都是由長期建立的系統來支持的，它們可能使用并不屬于 SOA 的主流的技術，并且可能非常復雜，因此不容易改變。所以，雖然它們可能是 SOA 中重用的好的候選者，但是需要做一些工作來向其提供基于服務的訪問。在某些情況下，供應商提供服務適配器，這就使工作更容易了（例如，用于 CICS 的 Web 服務）。
為了向遺留系統提供包裝器服務，需要某種形式的適配器技術或者“服務適配器”。這項技術的目標是與非 SOA 的系統集成，并應用所需要的任何數據或協議轉換來公開表示遺留功能的清晰的服務接口。這個接口是作為“包裝器服務”發布的。然后，服務使用者就可以通過該適配器綁定到包裝器服務了。
圖 4. 服務適配器
隨著我們需要從適配器獲得更多的智能和功能，我們開始需要這個語言中的其他模式。所以，有時僅僅編寫包裝器就足夠了。而有時就需要更多的變體和智能來將一項功能引入 SOA，這取決于我們是否確實擁有它、它的性能特征是什么，等等。
結果：可以更改應用程序或者遺留代碼，以提供清晰的接口。當代碼的容器（例如，CICS）支持適當的技術（例如，CICS SOAP 支持或者支持 XML 和消息傳遞技術）時，這種模式可能特別合適。
應該考慮的其他事項：
- 顯式適配器的使用，是定制的還是打包的（例如，Java 2 Connector 或 WebSphere Business Integration Adaptor）。
- 更通用的中間件的使用。例如，EAI 技術，比如代理，可以提供更集中的能力來執行用于多個應用程序或者遺留系統的適配器功能。
- ESB 的使用。如果使用 ESB，并且 ESB 具有類似于 EAI 的集成能力以及協調服務請求的能力，那么它就可以執行用于多個應用程序或者遺留系統的適配器功能。
模式 3：服務代理
環境和問題：使用者并不具備直接支持服務或者使用 WSDL 調用服務的能力。然而，您需要給他們提供使用與某個將來的提供者提供的特定服務相關聯的功能和服務質量的機會。請記住，或許現在這個提供者并沒有將這項功能作為 Web 服務來提供，而是以遺留的形式提供，并計劃將來進行遷移。服務的提供者可能還不具備公開服務的能力。
強制要求：如果候選提供者提供的服務功能還沒有充分地準備好，那么您可能仍需要提供服務的句柄，即使實際的 WSDL 和支持 Web 服務的技術還沒有就緒。
解決方案：為了對使用者屏蔽使用服務接口訪問功能所需要的復雜性，作為跳板，您可以選擇向客戶機提供服務代理，作為將來支持 SOA 功能的代理。
這個模式可以與服務適配器一起使用來支持虛擬提供者。
模式 4：虛擬提供者
您可能準備好了一個（或多個）服務適配器和服務代理。現在，您可以開始構建您的虛擬提供者了。
環境和問題：您與依賴您提供服務的服務使用者處于一個生態系統中。同樣地，您也依賴于服務提供者所提供的服務。然而，在現實世界中，這個生態系統是逐漸發展的——并不是所有您需要的服務都可以作為 Web 服務或者通過服務規范使用。您需要開發服務的關鍵部分來支持您的業務部門、企業或者生態系統。
圖 5. SOA 生態系統
強制要求：您希望以服務而不是 API 調用的方式獲得您所依賴的現有提供者的功能；但是它們還不能作為服務公開。您需要與潛在的提供者進行協商，以獲得所需要的服務，不只是功能上的，還有必需的服務水平協議或非功能性的需求，所有這些都是基于您所提供的服務規范或描述（另外，或許還有服務策略）。您可能會面臨挑戰，因為提供者可能沒有按照您要求的方式提供服務。最終，您可能要面對這樣的問題：a）提供者可能沒有及時地提供服務來滿足您急切的要求，b）他們提供了與您的粒度不匹配的其他功能，或者 c）他們沒有提供您所需要的非功能性需求。
您希望有人向您提供服務，但卻還沒有人做好準備。
解決方案：通過指定您所需要的服務并假定該服務已被提供的方式來創建虛擬提供者。使用代理與遺留系統通信，同時使用適配器將所使用的協議轉換為在服務描述/協定中指定的您所希望/需要/擁有的協議，自己創建服務提供者。將代理和適配器封裝在虛包 (facade) 中，因為適配器的數量將根據以后需要轉換的新系統和新協議隨機增長。因此，可以使用虛包封裝這組適配器來與現有的 API 進行通信。
圖 6. 虛擬提供者 SOA 模式組合虛包、服務代理、服務適配器和規則對象模式來啟用支持使用者的服務中的關鍵部分，即使在生態系統還沒有準備好提供所需要的全部服務時
結果：現在您有了以一種適當的遞增方式遷移到 SOA 的方法，即使生態系統還未完全做好準備。一旦提供者的服務得以實際創建、發布和提供，并且能夠使用，您就可以直接插入到這些服務。但是您不必編寫任何新的代碼，只需為源自現有的提供者 API 的新協議準備新的適配器即可。
相關模式：即后面提到的企業服務總線，如果中介、路由、轉換和策略的規則對象都添加到虛擬提供者的話。
虛擬提供者包括虛包、代理和一個或多個用于目標系統連接類型的適配器。一旦在虛擬提供者中添加了用于路由和策略管理的規則對象，它就成為了服務總線。
需要準備好一些模式來實現虛擬提供者，這涉及到管理。匹配提供的模式表明，中心組織將公平地在兩個組織單位之間分配資金，以便資助它們支持和創建各自所需要的服務，而這些服務又不在它們自己的資金預算之內，因為這“僅僅”使其他業務部門受益。請注意，隨著組織內中心訪問點變得更加普遍，這些問題就逐漸消失了。
模式 5：服務集成器
環境和問題：您正應用虛擬提供者并可能采用遠程服務策略來滿足業務需求的需要。然而，通過與冗余的后端功能相集成，封閉的遺留系統（自定義應用程序和打包的應用程序）仍是一個挑戰。您需要有一個到后端功能的單一訪問點，以便能夠在新的組合中重組該功能的各個部分，同時需要監視和管理這些新服務。
我們處于服務提供者的生態系統，其中的現有功能通常是脆弱的和特別開發的：連接常常是“一次性的”。集成是專有的和特別的；沒有單一訪問點來合成服務。
強制要求：當前的系統沒有提供具有合適粒度級別的接口。當沒有通過服務粒度與業務目標和 IT 系統一致的機制（例如，在 SOMA 方法[1]中的目標服務建模）進行服務建模和識別時，就會發生這種情況。另一種情況就是，服務沒有以合適的方式重構，并且沒有以無連接的（無狀態的）方式公開。因此，集成保留點到點的狀態，實現每個新的改變都將引起粘接代碼的膨脹。您需要有一個同樣也可以利用虛擬提供者和服務策略的健壯且靈活的單一訪問點。
解決方案：因此，可以將一個特定的集成層引入服務集成的體系結構中，并通過服務集成器來管理這一層。服務集成器向其他的冗余服務提供單一訪問點。
為了簡單起見，在實現端的虛擬提供者的環境中，將變體外化為遠程服務策略。按照這種方式開始構建從緊耦合的脆弱體系結構到更加松耦合的、可動態重新配置的體系結構的適當轉換的基礎。
圖 7. 專注于由服務集成器管理的集成層
服務集成器負責管理多個集成層，如圖 3 所示（層 6）。在服務計算生態系統中，服務集成器允許生態系統的單點集成、監視和管理。這個生態系統在本質上是分形的：這個組織可以在其體系結構的不同領域找到。它從項目層上的組織內開始，再轉到業務部門，并涵蓋企業體系結構中跨業務部門的各種現有應用程序。這就允許在生態系統中集成兩個或多個企業體系結構進行協作。
為了進一步發展通過應用虛擬提供者和遠程服務策略模式“啟動”的生態系統，現在我們需要合并來自跨多個后端系統和源的功能和服務，并將它們重組為一組內聚功能的內聚單一訪問點，以便減少或裁減我們的應用程序組合。通常，這種合并基于多個業務流程合成（編排）。而很多時候，這種編排可能也不是采用松耦合的、外化的技術（如 BPEL）來實現的，因為非功能性需求的成本可能太高了。為了減輕非功能性（操作）的影響，這種合成甚至可能是硬編碼的。由于服務合成通過服務集成器接進多個應用程序源，再合并、重組，然后在表示層作為門戶提交，因此減少了模式選擇/權衡的影響。
圖 8. 服務集成器在使用者和提供者之間進行協調
請注意，如果將虛擬提供者作為服務集成器使用，同時我們又在虛擬提供者（服務集成器）中添加了用于路由和策略管理的規則對象，那么它就變成了服務總線。
圖 9. 服務集成器 SOI 模式
結果：現在，無論在企業內部還是在企業外部的生態系統中，您都可以監視、管理和遷移功能和服務。您可以集成和重組接進其他外部服務提供者的應用程序、打包的應用程序和其他遺留功能，并為新的服務組合提供單一訪問和合成點，它們可能提交到 SOA 的使用者層（例如，表示層）內的門戶。
討論：那么，這與企業服務總線 (ESB) 有什么不同呢？簡單地說，我們正在討論的是可以支持成功地、漸進地遷移到 ESB 之前的狀態的跳板。在那以后，就可以創建和利用 ESB 來提供增強的服務功能了。因此，通常我們會看到客戶機從硬連接 (hard-wired) 集成開始，然后轉到點到點服務集成。虛擬服務提供者和之后的服務集成器提供了向 ESB 增量轉換的圖譜中的其他兩個步驟。
模式 6：ESB
環境和問題：本文所描述的模式闡釋了一些常用的技術，以現實的、可遞增實現的方式來實際交付一些由 SOA 帶來的靈活性的元素。然而，隨著組織越來越多地采用跨應用程序、遺留系統、通道技術等等的面向服務的體系結構，支持服務所需要的中間件以及用于支持它們的服務和技術的管理就成為復雜的問題。管理這種復雜性的解決方案的一個重要部分就是提供一個用于服務通信、協調、轉換和集成的基礎設施。這個基礎設施同樣也可以作為控制點，將服務管理、安全、監視和規范應用于面向服務的體系結構。這種公共的基礎設施是由企業服務總線描述的。
強制要求：擁有大量服務的組織將日益需要公共管理和操作模型來進行功能控制，以便：
- 以可管理的方式支持大量的服務交互
- 提供對高級交互功能（例如，事務、存儲轉發、基礎設施服務、安全以及服務質量）的支持
- 支持多種交互方式，例如同步請求/響應、消息傳遞、發布/訂閱以及事件
- 提供與 SOA 原則相一致的健壯的、可管理的、分布式集成基礎設施
- 支持服務路由和替換、協議轉換以及其他的消息處理
- 同時支持 Web 服務及傳統的 EAI 通信標準和技術
解決方案：創建企業服務總線來提供整個組織內的中間件功能，以便支持服務交互。ESB 應該支持這些服務所要求的通信、協調、轉換和集成技術，并且應該能夠使用公共管理模型來支持地理上分布的部署。下面的圖 11 摘自 IBM 紅皮書“Patterns: Implementing a SOA using an Enterprise Service Bus”，它闡釋了 ESB 的關鍵特性，其中包括：
- 它作為一個或多個“集線器”組件部署。每個集線器都提供本地化的但又可伸縮的功能來執行路由、轉換、安全以及其他功能，常稱為“中介”功能。
- 它有名稱空間目錄和管理服務，用于管理它支持訪問的服務。在地理上部署的 ESB 中，管理服務跨協同操作的集線器來維護一致的配置。
- 它有許多入站端口。每個入站端口都配置為使用某個特定的協議（例如 SOAP/HTTP 或 WebSphere MQ）來接收一組地址的服務請求
- 它有許多出站端口。每個出站端口都配置為使用某個特定的協議轉發服務請求和接收來自一組地址的響應。
這種配置使 ESB 能夠以公共的方式支持跨企業的任意數量的服務的虛擬服務提供者模式和遠程接收策略。另外，ESB 可以提供服務請求者和提供者之間的各種安全、數據格式或事務模型的轉換。這樣，ESB 就成為企業環境中不可避免會遇到的復雜性和異構性的控制及封裝點。
圖 10. ESB 模式
請參考下面的參考資料中列出的 ESB 紅皮書，以獲得關于 ESB 模式更多信息。
圖 11. 可選視圖：作為服務代理的服務總線
可以使用各種技術和產品實現 ESB 模式——特定的實現選擇依賴于特定組織的需求。參考資料中引用的 IBM 紅皮書包括對 ESB 模式更詳細的分析以及使用各種 IBM 軟件技術進行實現的指導。ESB 的公共實現技術包括 EAI 中間件（例如，WebSphere BI Message Broker）、Web 服務路由器（例如，WebSphere Web Services Gateway）或者更多使用 CORBA 技術或經由 HTTP 協議的基本 XML 的自定義實現。
討論：請注意，不僅基礎設施必須至少處于任何使用者和提供者所要求的最高級別，而且使用者或提供者本身也必須處于所需的級別。例如，安全和其他非功能的需求是將影響 SOA 的服務質量的點到點的概念。ESB 可以幫助管理服務，但是“管理服務”是更復雜的概念，例如，從 Web 服務的角度來看，管理服務可能不僅僅意味著添加或者刪除 JAX-RPC 處理程序，而且還意味著啟動/停止、管理服務的名稱空間（注冊中心）等等。
結束語
可以結合使用這些模式來解決遷移到 SOA 的相關問題。同樣在許多情況下，客戶需要轉到面向服務的集成模型，將其作為在他們的組織中實現更大規模的 SOA 的跳板。使用這些模式可以為客戶提供以下幾方面的幫助：
- 可以在對現有功能進行最小程度的改變的情況下順利地遷移到 SOA，同時越來越多地獲得日益成熟的 SOA 所帶來的好處。
- 支持將他們的包裝工作合并到新的 SOA 開發中的功能。
- 使用漸進遷移的策略，沒有棄用他們當前運行的系統，因此，不會對向業務客戶交付價值和處理他們的需求造成影響。
虛擬提供者通過支持創建服務范式的一流構造來幫助創建服務的生態系統（我將就此單獨寫一篇文章）。項目的粒度非常重要：較小的項目應該使用服務適配器和服務代理來連接遺留的功能或者不支持 SOA 的功能。如果組織中的某個業務部門決定標準化 SOA，那么它應該考慮創建虛擬提供者。或者，如果在企業層有一個項目跨多個業務部門（如付款處理服務或定價服務），那么創建虛擬提供者作為邁向創建服務總線的第一步是恰當的（這包括構建想要的功能的服務適配器，如果您希望作為服務訪問該功能，則應該向服務使用者提供服務代理）。如果出于性能或者安全方面的考慮，您希望嵌入訪問，那么您只需要一個服務適配器來訪問這項功能。實現這項服務的企業組件將需要這樣的適配器，以便能夠調用這項功能。但是不必將它作為服務向其使用者公開。只有那些不得不向提供者的使用者公開的服務才需要有服務代理或請求處理程序。
隨著組織發展到使用和采用 SOA 的更高的成熟度，它們將開始邁出內部系統的邊界，超越與少數合作伙伴的點到點零星集成，進入到要求新的功能的服務生態系統。這些功能之一就是我們上面概述的模式，它們幫助使體系結構進入到服務生態系統的領域中。其他的功能包括面向服務的企業體系結構（service-oriented enterprise architecture，SOEA）、面向服務的建模和體系結構方法（service-oriented modeling and architecture method，SOMA)、面向服務的引用模型 (service-oriented reference model)（如圖 7 所示）、管理，以及確保服務生態系統內重組的靈活性所需的模式。
?