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