理解面向服務(wù)的體系結(jié)構(gòu)中企業(yè)服務(wù)總線場(chǎng)景和解決方案.doc

此文檔收集于網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系網(wǎng)站刪除理解面向服務(wù)的體系結(jié)構(gòu)中企業(yè)服務(wù)總線場(chǎng)景和解決方案理解面向服務(wù)的體系結(jié)構(gòu)中企業(yè)服務(wù)總線場(chǎng)景和解決方案1第 1 部分企業(yè)服務(wù)總線中的工作角色1第 2 部分驅(qū)動(dòng)體系結(jié)構(gòu)的 ESB 場(chǎng)景和問(wèn)題9第 3 部分ESB 場(chǎng)景的解決方案15第 1 部分企業(yè)服務(wù)總線中的工作角色2004 年 7 月 01 日本文確定了一組最低功能，可以滿足企業(yè)服務(wù)總線（Enterprise Service Bus，ESB）與面向服務(wù)的體系結(jié)構(gòu)（service-oriented architecture，SOA）的原則保持一致的基本需要。通過(guò)確定這些最低功能，您可以確定利用何種現(xiàn)有技術(shù)來(lái)實(shí)現(xiàn)支持 SOA 的 ESB。通過(guò)考慮特定情形下的需求如何確定對(duì)額外功能的需要，您可以選擇最適合這種情形的實(shí)現(xiàn)技術(shù)。引言最新的 IT 集成是使用 Web 服務(wù)技術(shù)實(shí)現(xiàn)面向服務(wù)的體系結(jié)構(gòu)（SOA），有許多優(yōu)秀的文章講述了該技術(shù)的好處和相關(guān)的實(shí)踐（請(qǐng)參見(jiàn)參考資料）。最近，企業(yè)服務(wù)總線（Enterprise Service Bus，ESB）的概念被表述為 SOA 基礎(chǔ)架構(gòu)的關(guān)鍵組件（請(qǐng)參見(jiàn)參考資料）。然而，有必要闡明 ESB 究竟是一個(gè)產(chǎn)品、技術(shù)、標(biāo)準(zhǔn)，還是別的什么。特別是，當(dāng)前是否可以構(gòu)建 ESB？如果這樣，該如何構(gòu)建？本文將 ESB 描述為由中間件技術(shù)實(shí)現(xiàn)并支持 SOA 的一組基礎(chǔ)架構(gòu)功能。ESB 支持異構(gòu)環(huán)境中的服務(wù)、消息，以及基于事件的交互，并且具有適當(dāng)?shù)姆?wù)級(jí)別和可管理性。為了達(dá)到此目的，需要將多種功能集中起來(lái)并加以分類。然而，并不是 ESB 能夠傳遞值的每一種情形都需要所有的功能。本文確定了一組最低功能，可以滿足 ESB 與 SOA 的原則保持一致的基本需要。通過(guò)確定這些最低功能，您可以確定利用何種現(xiàn)有技術(shù)來(lái)實(shí)現(xiàn)支持 SOA 的 ESB。通過(guò)考慮特定情形下的需求如何確定對(duì)額外功能的需要，您可以選擇最適合這種情形的實(shí)現(xiàn)技術(shù)。在接下來(lái)的文章中，我將在 SOA 中定義一組 ESB 場(chǎng)景，以定義 ESB 或 SOA 實(shí)現(xiàn)的共同起點(diǎn)。而解決方案模式又為選擇適當(dāng)?shù)膶?shí)現(xiàn)技術(shù)提供了指南。隨著 ESB 解決方案的發(fā)展和成熟，它所需要的功能也在不斷地發(fā)展。同樣，可見(jiàn)的 ESB 產(chǎn)品的可用性和功能也日趨完善。因此，在本系列的最后一篇文章中，我將考慮 SOA 和 ESB 的發(fā)展路線，以指導(dǎo) ESB 功能和技術(shù)的最初應(yīng)用，并且闡述如何選擇循序漸進(jìn)的方法。ESB 在 SOA 內(nèi)的工作角色雖然我不打算深入討論 SOA 的定義（請(qǐng)參見(jiàn)參考資料），但是在這里概括一下大部分對(duì) SOA 的描述所適用的原則是很有用的： 利用顯式的與實(shí)現(xiàn)無(wú)關(guān)的接口來(lái)定義服務(wù)。 利用強(qiáng)調(diào)位置透明性和可互操作性的通信協(xié)議。 封裝可重用業(yè)務(wù)功能的服務(wù)的定義。 圖 1說(shuō)明了這些原則。注意，雖然 Web 服務(wù)技術(shù)非常符合這些原則，但它并不是唯一符合這些原則的技術(shù)。圖 1: SOA 的原則為了實(shí)現(xiàn) SOA，應(yīng)用程序和基礎(chǔ)架構(gòu)都必須支持 SOA 原則。啟用 SOA 應(yīng)用程序涉及到創(chuàng)建服務(wù)接口，服務(wù)接口可以直接也可以間接地通過(guò)使用適配器用于現(xiàn)有的或新的功能。從最基本的級(jí)別來(lái)看，啟用該基礎(chǔ)架構(gòu)涉及到規(guī)劃功能來(lái)將服務(wù)請(qǐng)求路由和傳遞給正確的服務(wù)提供者。然而，基礎(chǔ)架構(gòu)支持在不影響服務(wù)的客戶端的情況下由另一個(gè)服務(wù)實(shí)現(xiàn)替代原有的服務(wù)實(shí)現(xiàn)也是至關(guān)重要的。這不僅需要根據(jù) SOA 原則指定服務(wù)接口，而且需要基礎(chǔ)架構(gòu)允許客戶端代碼以獨(dú)立于所涉及的服務(wù)位置和通信協(xié)議的方式來(lái)調(diào)用服務(wù)。這樣的服務(wù)路由和替代是 ESB 的許多功能中的一部分。ESB 支持這些服務(wù)交互功能，并提供集成的通信、消息傳遞以及事件基礎(chǔ)架構(gòu)來(lái)支持這些功能。因此，它將當(dāng)今正在使用的主要企業(yè)集成模式組合成一個(gè)實(shí)體。ESB 為 SOA 提供與企業(yè)需要保持一致的基礎(chǔ)架構(gòu)，從而提供合適的服務(wù)級(jí)別和可管理性、以及異構(gòu)環(huán)境中的操作。本文剩余部分將討論 ESB 在 SOA 中的角色，包括它提供的除了基本的路由和傳輸以外的功能，如下面的ESB 功能模型部分中所述。ESB 結(jié)構(gòu)ESB 有時(shí)被描述為分布式基礎(chǔ)架構(gòu)，這與其他的解決方案形成了對(duì)比，比如消息代理技術(shù)一般被描述為中心輻射型（hub-and-spoke）。然而，這并不是真正的差別。正在研究?jī)蓚€(gè)不同的問(wèn)題：控制的集中和基礎(chǔ)架構(gòu)的分布。ESB 和中心輻射型（hub-and-spoke）解決方案都集中控制配置，比如服務(wù)交互的路由、服務(wù)命名等等。同樣，這兩個(gè)解決方案可能部署在簡(jiǎn)單的集中式基礎(chǔ)架構(gòu)中，也可能采用更復(fù)雜的分布式方式進(jìn)行部署。圖 2展示了這一點(diǎn)。毫無(wú)疑問(wèn)，不同的技術(shù)對(duì)它們所支持的物理部署模式有不同的約束有些可能適合于非常廣泛的分布，以支持在很大的地理范圍內(nèi)進(jìn)行的集成，而其他的可能更適合于部署在本地群集中，以支持高可用性和可伸縮性。使物理分布需求與候選技術(shù)的功能相匹配是 ESB 設(shè)計(jì)的一個(gè)重要方面。另外的一種能力也是非常重要的，就是以增量方式擴(kuò)展最初的部署來(lái)反映不斷變化的需求、集成附加的系統(tǒng)或擴(kuò)展基礎(chǔ)架構(gòu)的物理范圍。圖 2: 分布式 ESB 基礎(chǔ)架構(gòu)的集中控制我還應(yīng)該定位在 SOA 基礎(chǔ)架構(gòu)中 ESB 與其他組件之間的關(guān)系，特別是與 Service Directory、Business Service Choreography、以及 Business-to-Business (B2B) Gateway 這些組件之間的關(guān)系。由于上述 SOA 原則對(duì)這些組件并沒(méi)有嚴(yán)格的要求，所以我們可以將它們視為可選組件。圖 3展示的 SOA 說(shuō)明了這些組件之間的關(guān)系。圖 3: SOA 中的 ESB 角色ESB 需要某種形式的服務(wù)路由目錄（service routing directory）來(lái)路由服務(wù)請(qǐng)求。然而，SOA 可能還有單獨(dú)的業(yè)務(wù)服務(wù)目錄（business service directory），其最基本的形式可能是設(shè)計(jì)時(shí)服務(wù)目錄，用于在組織的整個(gè)開(kāi)發(fā)活動(dòng)中實(shí)現(xiàn)服務(wù)的重用。Web 服務(wù)遠(yuǎn)景在業(yè)務(wù)服務(wù)目錄和服務(wù)路由目錄的角色中都放置了一個(gè) UDDI 目錄，因而使得可以動(dòng)態(tài)發(fā)現(xiàn)和調(diào)用服務(wù)。這樣的目錄可以視為 ESB 的一部分；然而，在這樣的解決方案變得普遍之前，業(yè)務(wù)服務(wù)目錄可能與 ESB 是分離的。Business Service Choreographer 的作用是通過(guò)若干業(yè)務(wù)服務(wù)來(lái)組合業(yè)務(wù)流程；因此，它將通過(guò) ESB 調(diào)用服務(wù)，然后再次通過(guò) ESB 將業(yè)務(wù)流程公開(kāi)為客戶端可用的其他服務(wù)。然而，Business Service Choreographer 在編排業(yè)務(wù)流程和服務(wù)中所扮演的角色確定了這種業(yè)務(wù)工作流技術(shù)是一種與基礎(chǔ)架構(gòu)技術(shù) ESB 分離的技術(shù)。最后，B2B Gateway 組件的作用是使兩個(gè)或多個(gè)組織的服務(wù)在受控且安全的方式下對(duì)彼此可用。這有助于查看這些連接到 ESB 的組件，但它們并不是 ESB 的一部分。雖然有一些網(wǎng)關(guān)技術(shù)可以提供適合于實(shí)現(xiàn) B2B Gateway 組件和 ESB 的功能，但是 B2B Gateway 組件的用途是將其與 ESB 分離。事實(shí)上，這種用途可能需要附加的功能（如合作伙伴關(guān)系管理），這些功能不是 ESB 的一部分，并且不一定受到 ESB 技術(shù)的支持。ESB 的功能模型表 1對(duì)現(xiàn)有文獻(xiàn)中確定的一些 ESB 功能進(jìn)行了總結(jié)和分類（請(qǐng)參見(jiàn)參考資料）。雖然有一些功能非常基礎(chǔ)，但是其他的功能（如自動(dòng)化功能或智能化功能）代表著向按需操作環(huán)境轉(zhuǎn)變的重要步驟。重要的是認(rèn)識(shí)到，當(dāng)前的大多數(shù)場(chǎng)景只需要部分類別中的部分功能。ESB 實(shí)現(xiàn)所需的最低功能將在下面支持 SOA 的最低功能的 ESB 實(shí)現(xiàn)部分中進(jìn)行探討。表 1：在現(xiàn)有的文獻(xiàn)中定義的 ESB 功能通信 服務(wù)交互 路由 尋址 通信技術(shù)、協(xié)議和標(biāo)準(zhǔn)（例如 IBM WebSphere MQ、HTTP 和 HTTPS） 發(fā)布/訂閱 響應(yīng)/請(qǐng)求 Fire-and-Forget，事件 同步和異步消息傳遞 服務(wù)接口定義（例如，Web 服務(wù)描述語(yǔ)言（Web Services Description Language，WSDL） 支持替代服務(wù)實(shí)現(xiàn) 通信和集成所需的服務(wù)消息傳遞模型（例如 SOAP 或企業(yè)應(yīng)用程序集成 (EAI) 中間件模型） 服務(wù)目錄和發(fā)現(xiàn) 集成 服務(wù)質(zhì)量 數(shù)據(jù)庫(kù) 服務(wù)聚合 遺留系統(tǒng)和應(yīng)用程序適配器 EAI 中間件的連接性 服務(wù)映射 協(xié)議轉(zhuǎn)換 應(yīng)用程序服務(wù)器環(huán)境（例如 J2EE 和 .NET） 服務(wù)調(diào)用的語(yǔ)言接口（例如 Java 和 C/C+/C#） 事務(wù)（原子事務(wù)、補(bǔ)償、Web 服務(wù)事務(wù)（WS-Transaction） 各種確定的傳遞范例（例如 Web 服務(wù)可靠消息傳遞（WS-ReliableMessaging）或?qū)?EAI 中間件的支持） 安全性 服務(wù)級(jí)別 身份驗(yàn)證 授權(quán) 不可抵賴性 機(jī)密性 安全標(biāo)準(zhǔn)（例如 Kerberos 和 Web 服務(wù)安全性（WS-Security） 性能 吞吐量 可用性 其他可以構(gòu)成契約或協(xié)定的持久評(píng)估方法 消息處理 管理和自治 編碼的邏輯 基于內(nèi)容的邏輯 消息和數(shù)據(jù)轉(zhuǎn)換 有效性 中介 對(duì)象標(biāo)識(shí)映射 數(shù)據(jù)壓縮 服務(wù)預(yù)置和注冊(cè) 記錄、測(cè)量和監(jiān)控 發(fā)現(xiàn) 系統(tǒng)管理和管理工具的集成 自監(jiān)控和自管理 建模 基礎(chǔ)架構(gòu)智能 對(duì)象建模 通用業(yè)務(wù)對(duì)象建模 數(shù)據(jù)格式庫(kù) B2B 集成的公共與私有模型 開(kāi)發(fā)和部署工具 業(yè)務(wù)規(guī)則 策略驅(qū)動(dòng)的行為，特別是對(duì)于服務(wù)級(jí)別、服務(wù)功能的安全和質(zhì)量（例如 Web 服務(wù)策略（WS-Policy） 模式識(shí)別 上面的許多功能既可以使用專有技術(shù)實(shí)現(xiàn)，也可以通過(guò)利用開(kāi)放標(biāo)準(zhǔn)實(shí)現(xiàn)。然而，使用不同的技術(shù)來(lái)實(shí)現(xiàn) ESB 可能會(huì)使它們的性能、可伸縮性和可靠性這些特性顯著不同，同時(shí) ESB 功能和所支持的開(kāi)放標(biāo)準(zhǔn)也會(huì)有所不同。由于這些原因，再加上最近制訂和正在興起的一些相關(guān)標(biāo)準(zhǔn)，當(dāng)今實(shí)現(xiàn) ESB 的許多關(guān)鍵決策都涉及到成熟的專有技術(shù)和不成熟的開(kāi)放標(biāo)準(zhǔn)之間的權(quán)衡。在本系列文章中，我們不打算詳細(xì)討論上面的每一個(gè)功能類別。相反，我們將集中討論采用或?qū)崿F(xiàn) ESB 的不同方法之間的驅(qū)動(dòng)策略。特別是在下一部分，我們將討論 ESB 為支持 SOA 所需的最低功能由什么構(gòu)成。支持 SOA 的最低功能的 ESB 實(shí)現(xiàn)如果在前面確定的功能中只有一部分和大多數(shù) SOA 場(chǎng)景相關(guān)，我們可能會(huì)問(wèn)：實(shí)現(xiàn) ESB 所需的一組最低功能由什么構(gòu)成？為此，考慮最被普遍認(rèn)同的 ESB 定義的原理： ESB 是一種邏輯體系結(jié)構(gòu)組件，它提供與 SOA 的原則保持一致的集成基礎(chǔ)架構(gòu)。 SOA 原則需要使用與實(shí)現(xiàn)無(wú)關(guān)的的接口、強(qiáng)調(diào)位置透明性和可互操作性的通信協(xié)議、相對(duì)粗粒度和封裝可重用功能的服務(wù)定義。 ESB 可以作為分布式的異構(gòu)基礎(chǔ)架構(gòu)進(jìn)行實(shí)現(xiàn)。 ESB 提供了管理服務(wù)基礎(chǔ)架構(gòu)的方法和在分布式異構(gòu)環(huán)境中進(jìn)行操作的功能。 表 2展示了根據(jù)這些原則定義的最低 ESB 功能表 2: 最低的 ESB 功能通信 集成 提供位置透明性的路由和尋址服務(wù) 控制服務(wù)尋址和命名的管理功能 至少一種形式的消息傳遞范型（例如，請(qǐng)求/響應(yīng)、發(fā)布/訂閱等等） 支持至少一種可以廣泛使用的傳輸協(xié)議 支持服務(wù)提供的多種集成方式，比如 Java 2 連接器、Web 服務(wù)、異步通信、適配器等等 服務(wù)交互 一個(gè)開(kāi)放且與實(shí)現(xiàn)無(wú)關(guān)的服務(wù)消息傳遞與接口模型，它應(yīng)該將應(yīng)用程序代碼從路由服務(wù)和傳輸協(xié)議中分離出來(lái)，并允許替代服務(wù)的實(shí)現(xiàn)。請(qǐng)注意這些最低功能并不需要使用特別的技術(shù)，比如 EAI 中間件、Web 服務(wù)、J2EE 或 XML。這些技術(shù)的使用非常接近也非常符合需求，但是不必強(qiáng)制要求使用它們。相反，最低功能幾乎只需簡(jiǎn)單地使用 SOAP/HTTP 和 WSDL 就可以實(shí)現(xiàn)（當(dāng)然不是所有的情況都這樣）： URL 尋址和現(xiàn)有的 HTTP 和 DNS 基礎(chǔ)架構(gòu)提供了一個(gè)具有路由服務(wù)和位置透明性的“總線（bus）”。 SOAP/HTTP 支持請(qǐng)求-響應(yīng)（Request-Response）通信規(guī)范。 HTTP 傳輸協(xié)議被廣泛地使用。 SOAP 和 WSDL 是開(kāi)放、與實(shí)現(xiàn)無(wú)關(guān)的服務(wù)通信和連接模型。 然而，這些 SOAP/HTTP 和 WSDL 的基本應(yīng)用只是點(diǎn)到點(diǎn)（point-to-point）的集成，并不能實(shí)現(xiàn)一些 ESB 需要的關(guān)鍵功能： 目前還沒(méi)有用于控制服務(wù)尋址和命名的管理功能。服務(wù)名稱通過(guò)每個(gè)適配器單獨(dú)進(jìn)行控制的，服務(wù)路由控制則分散在由服務(wù)客戶端調(diào)用的地址、HTTP 基礎(chǔ)架構(gòu)和分配給適配器的服務(wù)名稱之間。 雖然這種方法依賴于實(shí)現(xiàn)細(xì)節(jié)，但是它往往并不能使服務(wù)實(shí)現(xiàn)的替代變得簡(jiǎn)單；服務(wù)請(qǐng)求者代碼（也可能是開(kāi)發(fā)工具生成的）通常通過(guò)特定地址的特定協(xié)議直接綁定到具體的服務(wù)提供者實(shí)現(xiàn)。如果想要用另一個(gè)服務(wù)實(shí)現(xiàn)來(lái)替代原來(lái)的服務(wù)實(shí)現(xiàn)，就需要修改應(yīng)用程序代碼并重新部署這些代碼。 當(dāng)然，在許多甚至是大多數(shù)情形中往往需要其他的功能，并且這種需要變得越來(lái)越常見(jiàn)。特別地，不管是現(xiàn)在還是以后，下面的需求類型可能會(huì)導(dǎo)致更復(fù)雜高級(jí)的技術(shù)的使用： 服務(wù)質(zhì)量和服務(wù)級(jí)別功能。 高級(jí) SOA 概念，例如服務(wù)編排、目錄、轉(zhuǎn)換等等。 按需操作環(huán)境需求，比如管理與自治功能以及基礎(chǔ)架構(gòu)智能功能。 跨越具有不同所有權(quán)的多個(gè)網(wǎng)絡(luò)、多個(gè)協(xié)議以及多個(gè)域的真正意義上的異步操作。 影響 ESB 的安全問(wèn)題我不想在這里直接提出安全需求，不過(guò)它們對(duì)選擇 ESB 的實(shí)現(xiàn)技術(shù)非常重要。例如，如果服務(wù)請(qǐng)求不需要提供身份驗(yàn)證或授權(quán)，實(shí)現(xiàn)技術(shù)的選擇就可以非常的廣泛。更有可能的情況是，如果需要一些安全級(jí)別，則評(píng)估什么形式的安全是可以接受的就非常重要。例如：1. 是否可以接受通信基礎(chǔ)架構(gòu)中的安全性，例如，是否在 EAI 中間件服務(wù)器之間使用安全套接字層（Secure Socket Layer，SSL）互相驗(yàn)證，或者是否在使用 HTTPS 協(xié)議？ 2. 是否可以接受在參與系統(tǒng)之間單獨(dú)的點(diǎn)到點(diǎn)（point-to-point）安全性，或者是否需要端到端（end-to-end）模型？例如，是否有必要通過(guò)類似于代理的中間件系統(tǒng)來(lái)把客戶端身份傳遞到服務(wù)實(shí)現(xiàn)的最終提供者？ 3. 是否可以接受應(yīng)用層中的安全性，例如，客戶端代碼是否能夠執(zhí)行帶有用戶 ID 和密碼的基本 HTTP 身份驗(yàn)證，或者是否能夠把這些信息作為應(yīng)用程序數(shù)據(jù)傳遞給服務(wù)？ 4. 是否需要遵守行業(yè)安全標(biāo)準(zhǔn)，例如 Kerberos 或 WS-Security？ 雖然所有這些都是可能的，但是行業(yè)的發(fā)展方向是基礎(chǔ)架構(gòu)和中間件支持的符合標(biāo)準(zhǔn)的安全性（例如 Web 服務(wù)安全性（WS-Security）功能。然而，相比之下，這些安全標(biāo)準(zhǔn)也是最近才提出的，而且對(duì)它們的產(chǎn)品支持仍在發(fā)展的過(guò)程中，而不是已經(jīng)確定了，這里尤其需要特別考慮的就是它們的互操作性。因此，任何 ESB 架構(gòu)都需要盡可能早地確定安全需求，以便在選擇實(shí)現(xiàn)技術(shù)時(shí)可以將它們包括進(jìn)來(lái)。 結(jié)束語(yǔ)在本文中，我討論了大多數(shù)通用的 SOA 原則，以及它們與 Web 服務(wù)技術(shù)的關(guān)聯(lián)?；谶@些原則，我提出了需要一個(gè)基礎(chǔ)架構(gòu)組件，這個(gè)組件可以提供路由功能，以便使服務(wù)能夠彼此交互，同時(shí)還能夠支持使用另一個(gè)服務(wù)實(shí)現(xiàn)來(lái)替換原有的服務(wù)實(shí)現(xiàn)。這些功能都是通過(guò) ESB 實(shí)現(xiàn)的。ESB 在維持集中控制的同時(shí)提供分布式的基礎(chǔ)架構(gòu)，因而需要一些形式的服務(wù)路由目錄，并且還可能需要業(yè)務(wù)服務(wù)目錄。Business Service Choreographer 從 ESB 調(diào)用服務(wù)，然后通過(guò) ESB 把這些流程作為新的服務(wù)公開(kāi)。ESB 的許多功能包括提供： 通信 服務(wù)交互 集成 質(zhì)量服務(wù) 安全 服務(wù)級(jí)別 消息處理 管理及自治服務(wù) 建模 基礎(chǔ)架構(gòu)智能 從這些不同的功能中，我確定了建立 ESB 所需的最低功能，包括通信、集成和服務(wù)交互。 在這個(gè)系列的下一個(gè)部分中，我將討論一些通用的場(chǎng)景，以及與這些場(chǎng)景相關(guān)的解決方案模式，同時(shí)指出影響這些場(chǎng)景最一般的問(wèn)題。致謝如果作者沒(méi)有與下列人員進(jìn)行討論，就不會(huì)有本文的存在，他們中的所有人都為本文貢獻(xiàn)了很好的想法和思想：Beth Hutchison、Rachel Reinitz、Olaf Zimmerman、Helen Wylie、Kyle Brown、Mark Colan、Jonathan Adams、Paul Fremantle、Keith Jones、Paul Verschueren、Daniel Sturman、Scott Cosby、Dave Clarke、Ben Mann、Louisa Gillies、Eric Herness、Bill Hassell、Guru Vasudeva、Kareem Yusuf、Ken Wilson、Mark Endrei、Norbert Bieberstein、Chris Nott、Alan Hopkins 和 Yaroslav Dunchych。 參考資料 您可以參閱本文在 developerWorks 全球站點(diǎn)上的英文原文. 要了解 Web 服務(wù)技術(shù)如何為實(shí)現(xiàn)面向服務(wù)的體系結(jié)構(gòu)提供必要的基礎(chǔ)，請(qǐng)閱讀 Annrai OToole 撰寫的 Web Service-Oriented Architecture - The Best Solution to Business Integration 。 在 CBDI 論壇查閱由 Lawrence Wilkes 撰寫的文章SOA - Save Our Assets（需要訂閱）。 Patterns: Service-oriented Architecture and Web Services紅皮書，SG24-6303-00，2004 年 4 月，作者 Endrei M. 等。 閱讀“遷移到面向服務(wù)的體系結(jié)構(gòu)，第 1 部分”（developerWorks，2003 年 12 月）和“遷移到面向服務(wù)的體系結(jié)構(gòu)，第 2 部分”（developerWorks，2003 年 12 月）。 訪問(wèn)LooselyC以獲得企業(yè)服務(wù)總線（Enterprise Service Bus）鏈接列表。 最初定義企業(yè)服務(wù)總線（Enterprise Service Bus）的文章Gartner需要訂閱，不過(guò)，也可以通過(guò)搜索它們的站點(diǎn)進(jìn)行查找，該文章的標(biāo)題為Predicts 2003: Enterprise Service Buses Emerge，2002 年 12 月 9 日發(fā)布，作者 Roy W. Schulte。 研究IBM Patterns for e-business網(wǎng)站。 訪問(wèn) IBM 的按需商務(wù)（on demand business）以獲得更多關(guān)于按需操作環(huán)境的詳細(xì)信息。 本文所用的資料來(lái)自 forthcoming 紅皮書Patterns: Implementing an SOA using an Enterprise Service Bus，SG24-6346-00，草案，作者 Martin Keen 等。 在 developerWorks的 SOA and Web services 技術(shù)專區(qū)查找其他 SOA 和 Web 服務(wù)技術(shù)資源。 在Developer Bookstore購(gòu)買關(guān)于各種各樣的技術(shù)主題的打折圖書。關(guān)于作者Rick Robinson 是 IBM 的一名 IT 架構(gòu)師，他于 1997 年 3 月作為一名開(kāi)發(fā)人員加入該公司。他是 EMEA WebSphere Lab Services 的 Architecture Services group 的一位成員，他從 1999 年 WebSphere 軟件平臺(tái)首次發(fā)布時(shí)就開(kāi)始關(guān)注它。Rick 更關(guān)注技術(shù)而不是行業(yè)，但是在過(guò)去的三年里他花了大量的時(shí)間和金融領(lǐng)域的公司一起工作。Rick 是 IBM 的一位值得信賴的 IT 架構(gòu)設(shè)計(jì)專業(yè)人員。在加入 IBM 之前，Rick 在攻讀物理博士。第 2 部分驅(qū)動(dòng)體系結(jié)構(gòu)的 ESB 場(chǎng)景和問(wèn)題在關(guān)于企業(yè)服務(wù)總線（Enterprise Service Bus，ESB）的這個(gè)系列的第二部分中，作者描述和分析了實(shí)現(xiàn) ESB 和其他面向服務(wù)的體系結(jié)構(gòu)（SOA）的解決方案的一些常見(jiàn)場(chǎng)景。這個(gè)系列的第 1 篇文章描述了企業(yè)服務(wù)總線（Enterprise Service Bus，ESB）的基本概念和工作角色。本文側(cè)重于描述為支持面向服務(wù)的體系結(jié)構(gòu)（SOA）而進(jìn)行的 ESB 開(kāi)發(fā)的場(chǎng)景和問(wèn)題。您的組織的 SOA 和 ESB 可能需要應(yīng)用到一個(gè)或多個(gè)這樣的場(chǎng)景。ESB 場(chǎng)景及分析SOA 中的 ESB 場(chǎng)景部分描述了許多 SOA 和 ESB 實(shí)現(xiàn)的起點(diǎn)。每個(gè)場(chǎng)景都指出驅(qū)動(dòng)體系結(jié)構(gòu)和設(shè)計(jì)決策的問(wèn)題，而這些決策會(huì)影響解決方案模式的選擇（將在這個(gè)系列的第 3 部分中進(jìn)行介紹）。在 驅(qū)動(dòng) ESB 體系結(jié)構(gòu)和設(shè)計(jì)決策的問(wèn)題 部分中，您可以閱讀關(guān)于這些問(wèn)題的詳細(xì)描述。這些解決方案模式代表著從服務(wù)技術(shù)的基本使用，到簡(jiǎn)單的 ESB 實(shí)現(xiàn)，再到復(fù)雜的 SOA 體系結(jié)構(gòu)的發(fā)展過(guò)程。 這些 ESB 場(chǎng)景的目的并不在于展示組織對(duì) SOA 或 ESB 的全部需求。例如，雖然某個(gè)場(chǎng)景（如兩個(gè)系統(tǒng)的基本集成）可能看起來(lái)很好地匹配了特定的當(dāng)前需求，但是隨著時(shí)間的推移，這種需求可能發(fā)展成更復(fù)雜的需求（如支持一個(gè)或多個(gè)應(yīng)用程序?qū)崿F(xiàn)更廣泛的連接性場(chǎng)景。另外，還可能有許多對(duì) SOA 或 ESB 基礎(chǔ)架構(gòu)的單獨(dú)需求會(huì)出現(xiàn)這樣的情況，就其個(gè)別而言符合簡(jiǎn)單場(chǎng)景，但集中在一起則表現(xiàn)得比較復(fù)雜。我們需要在實(shí)現(xiàn)滿足非常明確的需求的解決方案、努力預(yù)料未來(lái)的需求和定義跨企業(yè)的一致解決方案這三者之間作出選擇。將組織的需要看作是總體上相對(duì)復(fù)雜的場(chǎng)景（如實(shí)現(xiàn)具有高服務(wù)質(zhì)量和 Web 服務(wù)標(biāo)準(zhǔn)支持的 SOA 基礎(chǔ)架構(gòu)）可能是比較適合的。另外，還可以將個(gè)別的情形單獨(dú)看作是簡(jiǎn)單場(chǎng)景，但是定義最后得到的這些解決方案以后發(fā)展成通用體系結(jié)構(gòu)的路線。SOA 中的 ESB 場(chǎng)景下面的幾個(gè)部分描述了這些場(chǎng)景的特征： 兩個(gè)系統(tǒng)的基本集成 支持一個(gè)或多個(gè)應(yīng)用程序?qū)崿F(xiàn)更廣泛的連接性 支持遺留系統(tǒng)實(shí)現(xiàn)更廣泛的連接性 支持企業(yè)應(yīng)用程序集成（EAI）體系結(jié)構(gòu)實(shí)現(xiàn)更廣泛的連接性 實(shí)現(xiàn)組織之間服務(wù)或系統(tǒng)的受控集成 通過(guò)編排服務(wù)使流程自動(dòng)化 實(shí)現(xiàn)具有高服務(wù)質(zhì)量和 Web 服務(wù)標(biāo)準(zhǔn)支持的 SOA 基礎(chǔ)架構(gòu) 兩個(gè)系統(tǒng)的基本集成 場(chǎng)景 企業(yè)需要提供用不同的技術(shù)（如 J2EE、.NET、CICS 等等）實(shí)現(xiàn)的兩個(gè)系統(tǒng)之間的集成。Web 服務(wù) SOAP 標(biāo)準(zhǔn)或消息傳遞中間件可能是候選的集成技術(shù)。這個(gè)場(chǎng)景的一個(gè)重要的問(wèn)題是，將來(lái)是否會(huì)出現(xiàn)需要集成其他系統(tǒng)的情況。一開(kāi)始就使用可擴(kuò)展解決方案可能會(huì)對(duì)未來(lái)的需要提供支持；但是必須在為構(gòu)建這樣的解決方案而付出的額外工作與解決簡(jiǎn)單的問(wèn)題的最初需要之間保持平衡。 最相關(guān)的問(wèn)題 相關(guān)的解決方案模式（請(qǐng)參見(jiàn)下一篇文章）1,3,4,6,10,13 使用包裝器或適配器來(lái)實(shí)現(xiàn)基本集成請(qǐng)參見(jiàn)基本適配器。 或者，想要在將來(lái)進(jìn)行擴(kuò)展，有以下兩種方案： o 添加控制服務(wù)網(wǎng)關(guān)。 o 或者實(shí)現(xiàn)一個(gè)復(fù)雜的基礎(chǔ)架構(gòu)比如Web services Compliant Broker或EAI Infrastructure for SOA。 支持一個(gè)或多個(gè)應(yīng)用程序?qū)崿F(xiàn)更廣泛的連接性 場(chǎng)景 現(xiàn)有的已封裝或自定義開(kāi)發(fā)的應(yīng)用程序（例如客戶關(guān)系管理（Customer Relationship Management，CRM）、企業(yè)資源規(guī)劃（Enterprise Resource Planning，ERP）等等）可能是用 J2EE 平臺(tái)或其他應(yīng)用程序服務(wù)器環(huán)境實(shí)現(xiàn)的，它們提供的可用功能超出了應(yīng)用程序本身。以服務(wù)的形式公開(kāi)這些功能的價(jià)值在于，既支持應(yīng)用程序彼此之間的互操作，也提供對(duì)新的通道或客戶端的訪問(wèn)。使用可互操作或開(kāi)放的標(biāo)準(zhǔn)通信和服務(wù)協(xié)議看來(lái)是今后發(fā)展的最佳途徑。 最相關(guān)的問(wèn)題 相關(guān)的解決方案模式（請(qǐng)參見(jiàn)下一篇文章）1、2、3、4、6、8、9、10、11、12、13、14 使用包裝器或適配器來(lái)實(shí)現(xiàn)基本集成請(qǐng)參見(jiàn)基本適配器。 添加控制服務(wù)網(wǎng)關(guān)。 或者實(shí)現(xiàn)一個(gè)復(fù)雜的基礎(chǔ)架構(gòu)比如Web services Compliant Broker或EAI Infrastructure for SOA。 如果還需要流程編排（Process Choreography），就實(shí)現(xiàn)Service Choreographer或者Full SOA Infrastructure。 支持遺留系統(tǒng)實(shí)現(xiàn)更廣泛的連接性 場(chǎng)景 組織對(duì)遺留技術(shù)（比如 CICS、IMS 等等）進(jìn)行了大量的投資，以支持為他們提供核心業(yè)務(wù)事務(wù)和數(shù)據(jù)訪問(wèn)的應(yīng)用程序。其重要價(jià)值在于提供互操作性或開(kāi)放標(biāo)準(zhǔn)、以及對(duì)這些事務(wù)進(jìn)行基于服務(wù)的訪問(wèn)（例如，查詢帳戶余額的事務(wù)、創(chuàng)建訂單、日程安排或交付跟蹤、查詢庫(kù)存級(jí)別等等）。 最相關(guān)的問(wèn)題 相關(guān)的解決方案模式（請(qǐng)參見(jiàn)下一篇文章）1,2,3,4,7,8,9,10,11,13,14 使用包裝器或適配器來(lái)實(shí)現(xiàn)基本集成請(qǐng)參見(jiàn)基本適配器。 或者，想要在將來(lái)進(jìn)行擴(kuò)展，有以下兩種方案： o 添加控制服務(wù)網(wǎng)關(guān)。 o 或者實(shí)現(xiàn)一個(gè)復(fù)雜的基礎(chǔ)架構(gòu)比如Web services Compliant Broker或EAI Infrastructure for SOA。 支持企業(yè)應(yīng)用程序集成（EAI）基礎(chǔ)架構(gòu)實(shí)現(xiàn)更廣泛的連接性 場(chǎng)景 需要對(duì)現(xiàn)有的 EAI 基礎(chǔ)架構(gòu)（如 IBM WebSphere Business Integration）進(jìn)行擴(kuò)展，以對(duì)其進(jìn)行基于可互操作協(xié)議或開(kāi)放標(biāo)準(zhǔn)的訪問(wèn)。雖然根據(jù) XML 業(yè)務(wù)數(shù)據(jù)并通過(guò)高度可互操作協(xié)議（如 HTTP 或 WebSphere MQ）公開(kāi)服務(wù)接口可以在某些場(chǎng)景中提供適當(dāng)?shù)幕ゲ僮餍约?jí)別，但是如果對(duì)現(xiàn)有的集成范圍的自定義開(kāi)發(fā)或?qū)Ｓ袛U(kuò)展都不是可接受的，則可能需要支持 WSDL 和 SOAP Web 標(biāo)準(zhǔn)。 最相關(guān)的問(wèn)題 相關(guān)的解決方案模式（請(qǐng)參見(jiàn)下一篇文章）3、4、5、8、9、11、13、14 使用開(kāi)放數(shù)據(jù)格式及EAI Infrastructure for SOA來(lái)擴(kuò)展 EAI 基礎(chǔ)架構(gòu)。 添加控制服務(wù)網(wǎng)關(guān)。 或者對(duì)帶有Web services Compliant Broker的基礎(chǔ)架構(gòu)增加開(kāi)放標(biāo)準(zhǔn)支持。 實(shí)現(xiàn)組織之間服務(wù)或系統(tǒng)的受控集成 場(chǎng)景 組織希望使其客戶、供應(yīng)商或其他合作伙伴能夠直接集成由一個(gè)或多個(gè)應(yīng)用程序、遺留系統(tǒng)等等提供的功能。控制的重點(diǎn)是需要提供從外部各方到這些應(yīng)用程序的安全且易管理的訪問(wèn)。因?yàn)榻M織不能直接控制其合作伙伴所使用的技術(shù)，因此最好使用開(kāi)放標(biāo)準(zhǔn)。此場(chǎng)景既可以應(yīng)用于分散的組織之間，也可以應(yīng)用于大型分布式組織的各個(gè)單位之間。 最相關(guān)的問(wèn)題 相關(guān)的解決方案模式（參見(jiàn)下一篇文章）1、2、3、4、6、8、9、10、11、13、14 添加服務(wù)網(wǎng)關(guān)。 或者如果需要更多的復(fù)雜功能，就實(shí)現(xiàn)Web Services Compliant Broker。 通過(guò)編排服務(wù)使流程自動(dòng)化 場(chǎng)景（注意：此場(chǎng)景可以看作是支持一個(gè)或多個(gè)應(yīng)用程序?qū)崿F(xiàn)更廣泛的連接性場(chǎng)景的發(fā)展。它不被當(dāng)作一個(gè) ESB 場(chǎng)景，因?yàn)榉?wù)編排通常是與 ESB 分開(kāi)實(shí)現(xiàn)的，正如本系列的第一篇文章所述。然而，我之所以把它包括在這里，是因?yàn)榇藞?chǎng)景往往驅(qū)動(dòng)對(duì) ESB 和服務(wù)編排組件的需求。） 現(xiàn)有的已封裝（例如，客戶關(guān)系管理（Customer Relationship Management，CRM）、企業(yè)資源規(guī)劃（Enterprise Resource Planning，ERP）等等）或自定義開(kāi)發(fā)的應(yīng)用程序可能是在 J2EE 平臺(tái)或其他應(yīng)用程序服務(wù)環(huán)境中實(shí)現(xiàn)的，它們提供的可用功能超出了應(yīng)用程序本身。可以使用可互操作或開(kāi)放通信和服務(wù)協(xié)議將這些功能作為服務(wù)公開(kāi)，這樣應(yīng)用程序就可以交互?？梢栽谀承哟紊辖M合這些交互以構(gòu)成業(yè)務(wù)流程。應(yīng)該使用適當(dāng)?shù)慕：土鞒虉?zhí)行技術(shù)（可能遵守適當(dāng)?shù)拈_(kāi)放標(biāo)準(zhǔn)）來(lái)對(duì)這些流程進(jìn)行顯式建模。 最相關(guān)的問(wèn)題 相關(guān)的解決方案模式（請(qǐng)參見(jiàn)下一篇文章）1、2、3、4、6、10、11、12、13、14 如果服務(wù)的直接連接是可能的，則實(shí)現(xiàn)Service Choreographer。 如果需要更復(fù)雜的集成或控制，則實(shí)現(xiàn)Full SOA Infrastructure。 實(shí)現(xiàn)具有高服務(wù)質(zhì)量和 Web 服務(wù)標(biāo)準(zhǔn)支持的 SOA 基礎(chǔ)架構(gòu) 場(chǎng)景 此場(chǎng)景是由前面的組成的。它代表了對(duì)由多個(gè)應(yīng)用程序、遺留系統(tǒng)等等提供的服務(wù)進(jìn)行普遍的內(nèi)部或外部訪問(wèn)的需要。需要各種安全、聚合、轉(zhuǎn)換、路由以及服務(wù)編排功能。IT 組織以響應(yīng)所支持的業(yè)務(wù)不斷增加的需求，從而使得能夠在業(yè)務(wù)系統(tǒng)之間進(jìn)行更普遍且更靈活的集成。 最相關(guān)的問(wèn)題 相關(guān)的解決方案模式（請(qǐng)參見(jiàn)下一篇文章）全部 實(shí)現(xiàn)Full SOA Infrastructure。 驅(qū)動(dòng) ESB 體系結(jié)構(gòu)和設(shè)計(jì)決策的問(wèn)題為了確定用于 ESB 的合適解決方案模式和實(shí)現(xiàn)技術(shù)，需要對(duì)特定的 ESB 功能需求進(jìn)行詳細(xì)的分析。下面的問(wèn)題旨在幫助進(jìn)行這一過(guò)程，而前面的部分指出了與每個(gè)場(chǎng)景相關(guān)的特定問(wèn)題。1. 現(xiàn)有功能及其數(shù)據(jù)接口是否與您想要提供的服務(wù)相匹配？您是否能夠修改或聚合應(yīng)用程序？ o 如果不可以，則轉(zhuǎn)換或聚合功能就需要由適配器或 ESB 體系結(jié)構(gòu)來(lái)提供，或者不得不由服務(wù)客戶端來(lái)完成。 2. 服務(wù)是否可以以一些通用業(yè)務(wù)數(shù)據(jù)模型的形式公開(kāi)？如果可以，則實(shí)現(xiàn)這些服務(wù)的系統(tǒng)是否已經(jīng)支持該模型？或者說(shuō)可以使它們這樣做？ o 如果服務(wù)不可以，則轉(zhuǎn)換或聚合功能就需要由適配器或 ESB 體系結(jié)構(gòu)來(lái)提供。 3. 是否需要開(kāi)放標(biāo)準(zhǔn)？或者是否可以通過(guò) EAI 中間件來(lái)實(shí)現(xiàn)適當(dāng)?shù)幕ゲ僮餍?？如果需要開(kāi)放標(biāo)準(zhǔn)的話，則哪些開(kāi)放標(biāo)準(zhǔn)是適合的？ o 雖然使用開(kāi)放標(biāo)準(zhǔn)是實(shí)現(xiàn)互操作性的一種途徑，但專有的 EAI 中間件也具有高度的互操作性，并且往往要成熟得多。另外，許多組織還擁有廣泛的現(xiàn)有基礎(chǔ)架構(gòu)，在一些場(chǎng)景中，它們可能會(huì)使得開(kāi)放標(biāo)準(zhǔn)的作用幾近于無(wú)。 o 在需要開(kāi)放標(biāo)準(zhǔn)的場(chǎng)景中，Web 服務(wù)也許是這些情況下最明顯的選擇。不過(guò)，您也可以應(yīng)用 Java Messaging Service (JMS)、JDBC、基本 XML 或者一些其他的技術(shù)（比如 EDI 或業(yè)界通用的 XML 格式。 o 在實(shí)踐中，不能總是假定相同標(biāo)準(zhǔn)的不同實(shí)現(xiàn)之間具有互操作性，特別是對(duì)于近來(lái)出現(xiàn)或剛剛興起的標(biāo)準(zhǔn)。對(duì)于 Web 服務(wù)，Web 服務(wù)互操作性組織（Web Services Interoperability Organization）發(fā)布了使用 SOAP 和 WSDL 的互操作性的基本概要，其他更高級(jí)的標(biāo)準(zhǔn)（例如 Web 服務(wù)安全性（WS-Security）、Web 服務(wù)事務(wù)（WS-Transaction）等等）的概要隨后也將發(fā)布。在產(chǎn)品全面、穩(wěn)定且廣泛地支持這些概要之前，開(kāi)放標(biāo)準(zhǔn)的使用還沒(méi)有得到保證，并且可能并不總是促進(jìn)互操作性。 4. 是否需要支持基本通信協(xié)議及標(biāo)準(zhǔn)（例如 WebSphere MQ、SOAP、WSDL）？或者需要更高級(jí)的功能（例如 Web 服務(wù)安全性（WS-Security）、Web 服務(wù)事務(wù)（WS-Transaction）等等）？ o 對(duì)支持更復(fù)雜標(biāo)準(zhǔn)的需求將對(duì)實(shí)現(xiàn)技術(shù)的選擇加以更嚴(yán)格的約束，并且可能意味著使用還不成熟的技術(shù)。 5. 當(dāng)果考慮更改現(xiàn)有的基礎(chǔ)架構(gòu)使用的消息格式和協(xié)議（包括可能采用開(kāi)放標(biāo)準(zhǔn)）時(shí)，需要在整個(gè)現(xiàn)有的基礎(chǔ)架構(gòu)中進(jìn)行這些更改嗎？或者很快就要應(yīng)用新的消息格式和協(xié)議嗎？如果正在使用或考慮使用 EAI 技術(shù)，該技術(shù)是否有自己的內(nèi)部格式？或者它能夠?qū)㈤_(kāi)放標(biāo)準(zhǔn)處理為內(nèi)部格式嗎？ o 開(kāi)放標(biāo)準(zhǔn)的任何應(yīng)用都是受擴(kuò)展訪問(wèn)的需求驅(qū)動(dòng)的，因此它們對(duì)現(xiàn)有基礎(chǔ)架構(gòu)的接口的可用性比在內(nèi)部使用的這樣的標(biāo)準(zhǔn)更重要。 o 如果需要在內(nèi)部使用特定的格式、技術(shù)或標(biāo)準(zhǔn)，這會(huì)給實(shí)現(xiàn)技術(shù)的選擇帶來(lái)限制。 6. 將作為服務(wù)公開(kāi)的系統(tǒng)實(shí)現(xiàn)功能支持所需的技術(shù)或開(kāi)放標(biāo)準(zhǔn)（比如 SOAP、JMS或 XML）嗎？ o 如果不支持，ESB 基礎(chǔ)架構(gòu)或適配器將需要在所需的開(kāi)放標(biāo)準(zhǔn)和服務(wù)提供者支持的格式之間進(jìn)行轉(zhuǎn)換的功能。 7. 在需要訪問(wèn)遺留系統(tǒng)的情況下，通過(guò)使用更新的基于 XML 的技術(shù)，可以直接支持（例如 CICS SOAP 支持）遺留系統(tǒng)的可用性嗎？是否需要單獨(dú)的適配器？遺留平臺(tái)是否支持 XML 處理？如果支持，這種處理是否可以靈活地使用平臺(tái)功能？ o 如果因?yàn)檫@其中的任何原因而導(dǎo)致所需的 SOAP 或 XML 功能對(duì)遺留平臺(tái)不可用，則需要在適配器（比如s J2C Connector Architecture (JCA) 或 WebSphere Business Integration Adaptors）、集成層或 ESB 基礎(chǔ)架構(gòu)中使用適當(dāng)?shù)霓D(zhuǎn)換功能。 8. 如果 EAI 技術(shù)已經(jīng)可用，它是否使用適當(dāng)?shù)墓δ芑蚪涌诹６葘⒎?wù)作為消息流實(shí)現(xiàn)？它支持哪些連接性協(xié)議（例如 JCA、SOAP、WebSphere MQ 以及 Java 遠(yuǎn)程方法調(diào)用（Java Remote Method Invocation）？ o 如果現(xiàn)有消息流不提供所需要的服務(wù)，則需要另外的流程來(lái)執(zhí)行轉(zhuǎn)換。如果 EAI 技術(shù)不直接支持所需的標(biāo)準(zhǔn)，就需要添加一個(gè)網(wǎng)關(guān)組件。 9. 應(yīng)該從服務(wù)客戶端通道以工作負(fù)荷緩沖、安全、登錄等形式提供給服務(wù)提供者系統(tǒng)什么保護(hù)措施？ o 這種緩沖通常是 ESB 基礎(chǔ)架構(gòu)的一個(gè)角色，并且定義它所需要一些功能。如果特定的服務(wù)提供者系統(tǒng)（例如遺留事務(wù)系統(tǒng)（legacy transactional systems）需要額外的保護(hù)，則可以使用專用集成層。 10. 應(yīng)該實(shí)現(xiàn)多少服務(wù)？實(shí)現(xiàn)的什么方面應(yīng)該在這些服務(wù)中保持一致？如何實(shí)施一致性（可能在多個(gè)平臺(tái)上和多個(gè)應(yīng)用程序中）？ o 如果只需要非常少的服務(wù)，簡(jiǎn)單的點(diǎn)到點(diǎn)（point-to-point）集成模型可能比較適合。然而，如果需要更多的服務(wù)或者過(guò)一段時(shí)間以后可能還是如此，則添加控制點(diǎn)（比如由 ESB 提供的）就變得愈加有益。 11. 服務(wù)交互包含在組織內(nèi)部，還是有一些交互在組織外部？ o 這常常是不同于在單個(gè)組織中實(shí)現(xiàn)的 ESB 基礎(chǔ)架構(gòu)的一種情況，因?yàn)閷?duì)安全和服務(wù)路由的需求可能與外部可用的服務(wù)不同。 12. 是否需要服務(wù)編排？服務(wù)編排是否涉及短期（short-lived）或長(zhǎng)期（long-lived）（換句話說(shuō)就是有狀態(tài)的）流程，還是兩者都涉及？它們是否包含人工活動(dòng)？ o 在這些需求構(gòu)成業(yè)務(wù)功能的情況下，應(yīng)該在與 ESB 分離的 Service Choreographer 組件中實(shí)現(xiàn)編排。關(guān)于是支持長(zhǎng)期有狀態(tài)流程還是支持人工活動(dòng)的需求將對(duì)實(shí)現(xiàn)技術(shù)的選擇產(chǎn)生限制。 13. 基礎(chǔ)架構(gòu)應(yīng)該支持什么樣的服務(wù)級(jí)需求（例如，服務(wù)響應(yīng)時(shí)間、吞吐量、可用性等等）？隨著時(shí)間的推移，需要如何對(duì)其進(jìn)行擴(kuò)展？ o 一些候選的 ESB 實(shí)現(xiàn)技術(shù)相對(duì)較新，并且可能僅僅在有限的服務(wù)級(jí)進(jìn)行過(guò)測(cè)試。同樣，由于相關(guān)的開(kāi)放標(biāo)準(zhǔn)不是最近制訂就是正在興起的，所以在更多的既定產(chǎn)品和技術(shù)中對(duì)它們的支持也是新出現(xiàn)的。 o 在可以預(yù)見(jiàn)的未來(lái)，關(guān)鍵的體系結(jié)構(gòu)決策將專注于特定開(kāi)放標(biāo)準(zhǔn)優(yōu)點(diǎn)的平衡，針對(duì)服務(wù)級(jí)需求的新興或成熟的產(chǎn)品技術(shù)支持這些開(kāi)放標(biāo)準(zhǔn)。制訂這些即時(shí)決策需要考慮到有些標(biāo)準(zhǔn)和支持它們的產(chǎn)品是相對(duì)成熟的（例如 XML、SOAP等等），有些（例如 Web 服務(wù)安全（WS-Security）比較新，還有一些（例如 Web 服務(wù)事務(wù)）是正在興起的。 o 標(biāo)準(zhǔn)的優(yōu)點(diǎn)之間的權(quán)衡和經(jīng)過(guò)驗(yàn)證的服務(wù)級(jí)特征往往驅(qū)動(dòng)一個(gè)結(jié)合了 ESB 與 SOA 體系結(jié)構(gòu)中適應(yīng)標(biāo)準(zhǔn)的、專有的或自定義技術(shù)的混合方法。 14. 是否需要點(diǎn)到點(diǎn)（point-to-point）或端到端（end-to-end）安全模型（例如，ESB 是否可以簡(jiǎn)單的對(duì)服務(wù)請(qǐng)求授權(quán)，還是需要將請(qǐng)求者的身份或其他憑證傳遞給服務(wù)提供者）？是否需要使用應(yīng)用程序或遺留安全系統(tǒng)來(lái)集成服務(wù)安全模型？ o 如果點(diǎn)到點(diǎn)安全性是可接受的，則許多現(xiàn)有解決方案（例如 SSL 、對(duì)數(shù)據(jù)庫(kù)訪問(wèn)的 J2EE 安全性、適配器安全模型等等）就能夠得到應(yīng)用。如果需要端到端安全性，則 Web 服務(wù)安全標(biāo)準(zhǔn)就成為可能，提供所有相關(guān)的系統(tǒng)來(lái)支持它。換句話說(shuō)，您可以使用帶有客戶端消息頭的客戶端模型，或者傳送像應(yīng)用程序數(shù)據(jù)這樣的安全信息。 結(jié)束語(yǔ)本文確定了一些 ESB 實(shí)現(xiàn)中最常見(jiàn)的場(chǎng)景，以及對(duì)相應(yīng)的解決方案直接產(chǎn)生影響的問(wèn)題。雖然沒(méi)有完全涵蓋所有的隱藏問(wèn)題，但這些是其中最常遇到的。我們概述了從兩個(gè)系統(tǒng)的基本集成到實(shí)現(xiàn)支持高質(zhì)量服務(wù)和 Web 服務(wù)標(biāo)準(zhǔn)的 SOA 體系結(jié)構(gòu)的常見(jiàn)場(chǎng)景。并描述了需要重視的十四個(gè)不同的問(wèn)題： 現(xiàn)有數(shù)據(jù)接口 業(yè)務(wù)數(shù)據(jù)模型 開(kāi)放標(biāo)準(zhǔn)的使用 對(duì)基本或高級(jí)通信協(xié)議的支持 通過(guò)現(xiàn)有系統(tǒng)對(duì)數(shù)據(jù)傳遞格式的修改 通過(guò)新技術(shù)公開(kāi)現(xiàn)有服務(wù) 對(duì)遺留系統(tǒng)的訪問(wèn) 現(xiàn)有 EAI 技術(shù) 需要的保護(hù)措施 需要提供多少服務(wù)和需要的一致性程度 公司內(nèi)部以及與其他公司之間的互操作 對(duì)服務(wù)編排的需求 服務(wù)級(jí)需求的基礎(chǔ)架構(gòu)級(jí)支持 點(diǎn)到點(diǎn)（point-to-point）或端到端（end-to-end）安全模型的使用 理解這些基本場(chǎng)景和問(wèn)題為您開(kāi)發(fā)可能的解決方案打下了牢固的基礎(chǔ)。在本系列的第 3 部分，我將討論本文中提到的實(shí)際解決方案。如下： 基本適配器 服務(wù)網(wǎng)關(guān) Web services Compliant Broker Service Choreographer 用于 SOA 的 EAI 體系結(jié)構(gòu) 完整的 SOA 體系結(jié)構(gòu) 最后，我將討論組織考慮如何使用受控和增量的方式發(fā)展它們的體系結(jié)構(gòu)時(shí)可用的選擇。也將說(shuō)明能夠指導(dǎo)您開(kāi)發(fā)自己的 ESB 路線的一些問(wèn)題。第 3 部分ESB 場(chǎng)景的解決方案這個(gè)系列文章的第 3 部分介紹了實(shí)現(xiàn)企業(yè)服務(wù)總線（Enterprise Service Bus，ESB）的場(chǎng)景和解決方案，在此作者分析了第 2 部分概述的多個(gè)場(chǎng)景可能的解決方案。在第 1 部分中說(shuō)明的總線工作角色提供了這些場(chǎng)景的基礎(chǔ)。下面繼續(xù)這個(gè)系列來(lái)構(gòu)建面向服務(wù)體系結(jié)構(gòu)（Service-Oriented Architecture，SOA）的企業(yè)服務(wù)總線，現(xiàn)在我們來(lái)看一看第 2 部分（請(qǐng)參閱參考資料）中所描述場(chǎng)景的多種顯而易見(jiàn)的解決方案模式。以下的每個(gè)部分都描述了一種 ESB 實(shí)現(xiàn)方式的解決方案模式，除了基本適配器（Basic Adaptors）模式以外，其他的都是簡(jiǎn)單的點(diǎn)到點(diǎn)（P2P）解決方案。每個(gè)模式都提出了不同的使用現(xiàn)行技術(shù)的實(shí)現(xiàn)選擇，同時(shí)也做出了正反兩方面以及移植方面的考慮。 請(qǐng)注意每個(gè)解決方案模式的圖示，它認(rèn)為服務(wù)客戶端與提供服務(wù)的系統(tǒng)是分離的。當(dāng)然，在許多情況下，相同的系統(tǒng)或應(yīng)用程序既可以是服務(wù)客戶端也可以是服務(wù)提供者。圖示并非是要排除系統(tǒng)作為單獨(dú)的客戶端和提供者的可能性，而是承認(rèn)了相同的系統(tǒng)在不同的互操作中可以有兩種不同的工作角色。在決定系統(tǒng)是作為客戶端角色來(lái)選擇、確認(rèn)和調(diào)用服務(wù)，還是作為提供者角色來(lái)接收、處理和響應(yīng)服務(wù)請(qǐng)求時(shí)，這個(gè)區(qū)別通常很重要。 本部分的解決方案模式有： 基本適配器（Basic Adaptors） 服務(wù)網(wǎng)關(guān) Web 服務(wù)兼容的代理（Web Service-compliant Broker） 面向服務(wù)體系結(jié)構(gòu)的企業(yè)應(yīng)用集成基礎(chǔ)架構(gòu)（EAI Infrastructure for SOA） 服務(wù)編排（Service Choreographer） 完整的面向服務(wù)體系結(jié)構(gòu)的基礎(chǔ)架構(gòu)（Full SOA Infrastructure） 基本適配器解決方案模式這種解決方案通過(guò)封裝器或適配器技術(shù)來(lái)實(shí)現(xiàn)簡(jiǎn)單的點(diǎn)到點(diǎn)（P2P）服務(wù)集成，而不是真正的 ESB。這種技術(shù)通過(guò) WSDL 定義的 SOAP 訪問(wèn)或者其他可互操作的產(chǎn)品技術(shù)（比如 IBM WebSphere MQ （MQ）來(lái)實(shí)現(xiàn)集成。如果這些技術(shù)沒(méi)有為服務(wù)接口定義（比如 WSDL）提供本地模型，那么將需要使用自定義模型來(lái)實(shí)現(xiàn) SOA 規(guī)范。 雖然設(shè)計(jì)比較簡(jiǎn)單，但是從該模式中可以獲得的好處卻不可低估。例如，通過(guò) MQ 或 SOAP/HTTP 進(jìn)行的直接集成仍然可以是松散耦合式的，尤其是互操作的特征是使用接口來(lái)聲明時(shí)。在將來(lái)的某個(gè)時(shí)候，對(duì)于支持最初使用的集成技術(shù)的 ESB 基礎(chǔ)架構(gòu)，我們可以通過(guò)它來(lái)中斷集成。還可以在進(jìn)程級(jí)別的服務(wù)命名和尋址之上實(shí)現(xiàn)控制級(jí)別。 現(xiàn)在已經(jīng)有各種各樣的適配器可用，而且也可以通過(guò)開(kāi)發(fā)工具或運(yùn)行時(shí)技術(shù)來(lái)創(chuàng)建新的適配器。并能使其提供對(duì) Web 服務(wù)規(guī)范和 企業(yè)應(yīng)用集成（Enterprise Application Integration，EAI）中間件的支持。它也可以提供給多種不同類型的系統(tǒng)，包含最新的分布式應(yīng)用服務(wù)器（J2EE 服務(wù)器（如 WebSphere），或者微軟的 .NET 系統(tǒng)）、企業(yè)遺留系統(tǒng)（比如 CICS）以及 Commercial Off-the-Shelf 軟件包（比如 SAP 或 Siebel）。 圖 1 說(shuō)明了一般的基本適配器解決方案，包含了使用現(xiàn)有的 HTTP 和 EAI 中間件基礎(chǔ)架構(gòu)來(lái)支持新的集成。雖然本圖描繪的是內(nèi)部集成場(chǎng)景，但如果用 HTTP 來(lái)作為通信協(xié)議，或者使用某些 Internet 兼容的 EAI 技術(shù)（比如 MQ internet pass-thru），那么該解決方案同樣可以應(yīng)用于外部場(chǎng)景。 圖 1. 基本適配器解決方案模式將現(xiàn)有 HTTP 和未修改的 EAI 基礎(chǔ)架構(gòu)描述為支持服務(wù)總線功能的某些方面選擇基本適配器的實(shí)現(xiàn)技術(shù)以下是實(shí)現(xiàn)基本適配器的一些選擇： 使用遺留系統(tǒng)或應(yīng)用程序直接提供的 SOAP 或 EAI 功能。例如