面向服務(wù)的體系結(jié)構(gòu)中企業(yè)服務(wù)

1、 HYPERLINK 理解面向服務(wù)的體系結(jié)構(gòu)中企業(yè)服務(wù)總線場(chǎng)景和解決方案第 1 部分企業(yè)服務(wù)總線中的工作角色 HYPERLINK l author1 Rick Robinson（ HYPERLINK mailto:rick_robinson rick_robinson）IT 架構(gòu)師, IBM2004 年 7 月本文確定了一組最低功能，可以滿(mǎn)足企業(yè)服務(wù)總線（Enterprise ServiceBus，ESB）與面向服務(wù)的體系結(jié)構(gòu)（service-orientedarchitecture，SOA）的原則保持一致的基本需要。通過(guò)確定這些最低功能，您可以確定利用何種現(xiàn)有技術(shù)來(lái)實(shí)現(xiàn)支持 SOA 的ESB

2、。通過(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) HYPERLINK l resources 參考資料）。最近，企業(yè)服務(wù)總線（Enterprise ServiceBus，ESB）的概念被表述為 SOA 基礎(chǔ)架構(gòu)的關(guān)鍵組件（請(qǐng)參見(jiàn) HYPERLINK l resources 參考資料）。然而，有必要闡明ESB 究竟是一個(gè)產(chǎn)品、技術(shù)、標(biāo)準(zhǔn)，還是別的什么。特別是，當(dāng)前是否可以構(gòu)建 ESB？如果這樣，該如何構(gòu)建？本文將 ESB 描述

3、為由中間件技術(shù)實(shí)現(xiàn)并支持 SOA 的一組基礎(chǔ)架構(gòu)功能。ESB支持異構(gòu)環(huán)境中的服務(wù)、消息，以及基于事件的交互，并且具有適當(dāng)?shù)姆?wù)級(jí)別和可管理性。為了達(dá)到此目的，需要將多種功能集中起來(lái)并加以分類(lèi)。然而，并不是 ESB能夠傳遞值的每一種情形都需要所有的功能。本文確定了一組最低功能，可以滿(mǎn)足 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)。而

4、解決方案模式又為選擇適當(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) HYPERLINK l resources 參考資料），但是在這里概括一下大部分對(duì) SOA 的描述所適用的原則是很有用的：利用顯式的與實(shí)現(xiàn)無(wú)關(guān)的接口來(lái)定義服務(wù)。利用強(qiáng)調(diào)位置透明性和可互操作性的通信協(xié)議。封裝可重用業(yè)務(wù)功能

5、的服務(wù)的定義。 HYPERLINK l figure1 圖 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ù)的客戶(hù)端的情況下由另一個(gè)服務(wù)實(shí)現(xiàn)替代原有的服務(wù)實(shí)現(xiàn)也是至關(guān)重要的。這不僅需要根據(jù) SOA原則指定服務(wù)接口，而且需要基礎(chǔ)架構(gòu)允許客戶(hù)端

6、代碼以獨(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ù)一般被描述為中心

7、輻射型（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)行部署。 HYPERLINK l figure2 圖 2展示了這一點(diǎn)。毫無(wú)疑問(wèn)，不同的技術(shù)對(duì)它們所支持的物理部署模式有不同的約束有些可能適合于非常廣泛的分布，以支持在很大的地理范圍內(nèi)進(jìn)行的集成，而其他的可能更適合于部署在本地群集中，以支持高可用性和可伸縮性。使物理分布需求與候選技術(shù)的功能相匹配

8、是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 ServiceChoreography、以及 Business-to-Business (B2B) Gateway 這些組件之間的關(guān)系。由于上述 SOA原則對(duì)這些組件并沒(méi)有嚴(yán)格的要求，所以我們可以將它們視為可選組件。 HYPERLINK l figure3 圖 3展示的 SO

9、A說(shuō)明了這些組件之間的關(guān)系。圖 3: SOA 中的 ESB 角色ESB 需要某種形式的服務(wù)路由目錄（service routingdirectory）來(lái)路由服務(wù)請(qǐng)求。然而，SOA 可能還有單獨(dú)的業(yè)務(wù)服務(wù)目錄（business servicedirectory），其最基本的形式可能是設(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 Ch

10、oreographer 的作用是通過(guò)若干業(yè)務(wù)服務(wù)來(lái)組合業(yè)務(wù)流程；因此，它將通過(guò) ESB 調(diào)用服務(wù)，然后再次通過(guò)ESB 將業(yè)務(wù)流程公開(kāi)為客戶(hù)端可用的其他服務(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

11、 組件的用途是將其與 ESB分離。事實(shí)上，這種用途可能需要附加的功能（如合作伙伴關(guān)系管理），這些功能不是 ESB 的一部分，并且不一定受到 ESB 技術(shù)的支持。ESB 的功能模型 HYPERLINK l table1 表 1對(duì)現(xiàn)有文獻(xiàn)中確定的一些 ESB 功能進(jìn)行了總結(jié)和分類(lèi)（請(qǐng)參見(jiàn) HYPERLINK l resources 參考資料）。雖然有一些功能非常基礎(chǔ)，但是其他的功能（如自動(dòng)化功能或智能化功能）代表著向按需操作環(huán)境轉(zhuǎn)變的重要步驟。重要的是認(rèn)識(shí)到，當(dāng)前的大多數(shù)場(chǎng)景只需要部分類(lèi)別中的部分功能。ESB實(shí)現(xiàn)所需的最低功能將在下面支持 SOA 的最低功能的 ESB實(shí)現(xiàn)部分中進(jìn)行探討。表 1：在

12、現(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ù)

13、調(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)不可抵賴(lài)性機(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)控和自管理建?；A(chǔ)架構(gòu)智能對(duì)象建

14、模通用業(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í)別上面的許多功能既可以使用專(zhuān)有技術(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)鍵決策都涉及到成熟的專(zhuān)有技術(shù)和不成熟的開(kāi)放標(biāo)準(zhǔn)之間的權(quán)衡。在本系列文章中，我們不打算詳細(xì)討論上面的每一個(gè)功能類(lèi)別。相反，我們將集中討

15、論采用或?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)的

16、方法和在分布式異構(gòu)環(huán)境中進(jìn)行操作的功能。 HYPERLINK l table2 表 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 中間件

17、、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）的集成，并不

18、能實(shí)現(xiàn)一些 ESB 需要的關(guān)鍵功能：目前還沒(méi)有用于控制服務(wù)尋址和命名的管理功能。服務(wù)名稱(chēng)通過(guò)每個(gè)適配器單獨(dú)進(jìn)行控制的，服務(wù)路由控制則分散在由服務(wù)客戶(hù)端調(diào)用的地址、HTTP基礎(chǔ)架構(gòu)和分配給適配器的服務(wù)名稱(chēng)之間。雖然這種方法依賴(lài)于實(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)在還是以后，下面的需求類(lèi)型可能會(huì)導(dǎo)致更復(fù)雜

19、高級(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)估什么形式的安全是可以接受的就非常重要。例如：是否可以接受通信基礎(chǔ)架構(gòu)中的安全性，例如，是否在 EAI 中間件服務(wù)器之間使用安全套接字層（Secure Socket

20、Layer，SSL）互相驗(yàn)證，或者是否在使用 HTTPS 協(xié)議？是否可以接受在參與系統(tǒng)之間單獨(dú)的點(diǎn)到點(diǎn)（point-to-point）安全性，或者是否需要端到端（end-to-end）模型？例如，是否有必要通過(guò)類(lèi)似于代理的中間件系統(tǒng)來(lái)把客戶(hù)端身份傳遞到服務(wù)實(shí)現(xiàn)的最終提供者？是否可以接受應(yīng)用層中的安全性，例如，客戶(hù)端代碼是否能夠執(zhí)行帶有用戶(hù) ID 和密碼的基本 HTTP身份驗(yàn)證，或者是否能夠把這些信息作為應(yīng)用程序數(shù)據(jù)傳遞給服務(wù)？是否需要遵守行業(yè)安全標(biāo)準(zhǔn)，例如 Kerberos 或 WS-Security？雖然所有這些都是可能的，但是行業(yè)的發(fā)展方向是基礎(chǔ)架構(gòu)和中間件支持的符合標(biāo)準(zhǔn)的安全性（例如 W

21、eb服務(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)，因而

22、需要一些形式的服務(wù)路由目錄，并且還可能需要業(yè)務(wù)服務(wù)目錄。Business ServiceChoreographer 從 ESB 調(diào)用服務(wù)，然后通過(guò) ESB 把這些流程作為新的服務(wù)公開(kāi)。ESB 的許多功能包括提供：通信服務(wù)交互集成質(zhì)量服務(wù)安全服務(wù)級(jí)別消息處理管理及自治服務(wù)建?；A(chǔ)架構(gòu)智能從這些不同的功能中，我確定了建立 ESB 所需的最低功能，包括通信、集成和服務(wù)交互。在這個(gè)系列的下一個(gè)部分中，我將討論一些通用的場(chǎng)景，以及與這些場(chǎng)景相關(guān)的解決方案模式，同時(shí)指出影響這些場(chǎng)景最一般的問(wèn)題。第 2 部分驅(qū)動(dòng)體系結(jié)構(gòu)的 ESB 場(chǎng)景和問(wèn)題 HYPERLINK l author1 Rick Robinso

23、n（ HYPERLINK mailto:rick_robinson rick_robinson） IT Architect, IBM2004 年 7 月在關(guān)于企業(yè)服務(wù)總線（Enterprise Service Bus，ESB）的這個(gè)系列的第二部分中，作者描述和分析了實(shí)現(xiàn) ESB和其他面向服務(wù)的體系結(jié)構(gòu)（SOA）的解決方案的一些常見(jiàn)場(chǎng)景。這個(gè)系列的 HYPERLINK 第 1篇文章描述了企業(yè)服務(wù)總線（Enterprise ServiceBus，ESB）的基本概念和工作角色。本文側(cè)重于描述為支持面向服務(wù)的體系結(jié)構(gòu)（SOA）而進(jìn)行的 ESB 開(kāi)發(fā)的場(chǎng)景和問(wèn)題。您的組織的 SOA 和 ESB可能需要應(yīng)

24、用到一個(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)行介紹）。在 HYPERLINK l 2.2 驅(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)很好地匹配了特定

25、的當(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)滿(mǎ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)景

26、下面的幾個(gè)部分描述了這些場(chǎng)景的特征： HYPERLINK l table1 兩個(gè)系統(tǒng)的基本集成 HYPERLINK l table2 支持一個(gè)或多個(gè)應(yīng)用程序?qū)崿F(xiàn)更廣泛的連接性 HYPERLINK l table3 支持遺留系統(tǒng)實(shí)現(xiàn)更廣泛的連接性 HYPERLINK l table4 支持企業(yè)應(yīng)用程序集成（EAI）體系結(jié)構(gòu)實(shí)現(xiàn)更廣泛的連接性 HYPERLINK l table5 實(shí)現(xiàn)組織之間服務(wù)或系統(tǒng)的受控集成 HYPERLINK l table6 通過(guò)編排服務(wù)使流程自動(dòng)化 HYPERLINK l table7 實(shí)現(xiàn)具有高服務(wù)質(zhì)量和 Web 服務(wù)標(biāo)準(zhǔn)支持的 SOA 基礎(chǔ)架構(gòu)兩個(gè)系統(tǒng)的基本集成場(chǎng)景

27、企業(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ò)展，有以下兩種方案：添加控制服務(wù)網(wǎng)關(guān)?；蛘邔?shí)現(xiàn)一個(gè)復(fù)雜的基礎(chǔ)架構(gòu)比如Web service

28、s Compliant Broker或EAI Infrastructure for SOA。支持一個(gè)或多個(gè)應(yīng)用程序?qū)崿F(xiàn)更廣泛的連接性場(chǎng)景現(xiàn)有的已封裝或自定義開(kāi)發(fā)的應(yīng)用程序（例如客戶(hù)關(guān)系管理（Customer RelationshipManagement，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ì)新的通道或客戶(hù)端的訪問(wèn)。使用可互操作或開(kāi)放的標(biāo)準(zhǔn)通信和服務(wù)協(xié)議看來(lái)是今后發(fā)展的最佳

29、途徑。最相關(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)行了大量的投資，以支持為他們提供

30、核心業(yè)務(wù)事務(wù)和數(shù)據(jù)訪問(wèn)的應(yīng)用程序。其重要價(jià)值在于提供互操作性或開(kāi)放標(biāo)準(zhǔn)、以及對(duì)這些事務(wù)進(jìn)行基于服務(wù)的訪問(wèn)（例如，查詢(xún)帳戶(hù)余額的事務(wù)、創(chuàng)建訂單、日程安排或交付跟蹤、查詢(xún)庫(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ò)展，有以下兩種方案：添加控制服務(wù)網(wǎng)關(guān)?；蛘邔?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)景需要

31、對(duì)現(xiàn)有的 EAI 基礎(chǔ)架構(gòu)（如 IBM WebSphere BusinessIntegration）進(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)。添加控

32、制服務(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)景組織希望使其客戶(hù)、供應(yīng)商或其他合作伙伴能夠直接集成由一個(gè)或多個(gè)應(yīng)用程序、遺留系統(tǒng)等等提供的功能?？刂频闹攸c(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

33、 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)有的已封裝（例如，客戶(hù)關(guān)系管理（Customer RelationshipManagement，CRM）、企業(yè)資源規(guī)劃（Enterprise Resource Planning，ERP）等等）或自定義開(kāi)發(fā)的應(yīng)用程序可能是在 J2EE平臺(tái)或其他應(yīng)用程序服務(wù)環(huán)境

34、中實(shí)現(xiàn)的，它們提供的可用功能超出了應(yīng)用程序本身。可以使用可互操作或開(kāi)放通信和服務(wù)協(xié)議將這些功能作為服務(wù)公開(kāi)，這樣應(yīng)用程序就可以交互。可以在某些層次上組合這些交互以構(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)景是由前面的組

35、成的。它代表了對(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)題?，F(xiàn)有功能及其數(shù)據(jù)接口是否與您想要提供的服務(wù)相匹配？您是否

36、能夠修改或聚合應(yīng)用程序？如果不可以，則轉(zhuǎn)換或聚合功能就需要由適配器或 ESB 體系結(jié)構(gòu)來(lái)提供，或者不得不由服務(wù)客戶(hù)端來(lái)完成。服務(wù)是否可以以一些通用業(yè)務(wù)數(shù)據(jù)模型的形式公開(kāi)？如果可以，則實(shí)現(xiàn)這些服務(wù)的系統(tǒng)是否已經(jīng)支持該模型？或者說(shuō)可以使它們這樣做？如果服務(wù)不可以，則轉(zhuǎn)換或聚合功能就需要由適配器或 ESB 體系結(jié)構(gòu)來(lái)提供。是否需要開(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)是適合的？雖然使用開(kāi)放標(biāo)準(zhǔn)是實(shí)現(xiàn)互操作性的一種途徑，但專(zhuān)有的 EAI中間件也具有高度的互操作性，并且往往要成熟得多。另外，許多組織還擁有廣泛的現(xiàn)有基礎(chǔ)架構(gòu)，在一些場(chǎng)景中，它們

37、可能會(huì)使得開(kāi)放標(biāo)準(zhǔn)的作用幾近于無(wú)。在需要開(kāi)放標(biāo)準(zhǔn)的場(chǎng)景中，Web 服務(wù)也許是這些情況下最明顯的選擇。不過(guò)，您也可以應(yīng)用 Java Messaging Service(JMS)、JDBC、基本 XML 或者一些其他的技術(shù)（比如 EDI 或業(yè)界通用的 XML 格式。在實(shí)踐中，不能總是假定相同標(biāo)準(zhǔn)的不同實(shí)現(xiàn)之間具有互操作性，特別是對(duì)于近來(lái)出現(xiàn)或剛剛興起的標(biāo)準(zhǔn)。對(duì)于 Web 服務(wù)，Web 服務(wù)互操作性組織（WebServices Interoperability Organization）發(fā)布了使用 SOAP 和 WSDL 的互操作性的基本概要，其他更高級(jí)的標(biāo)準(zhǔn)（例如Web 服務(wù)安全性（WS-Secu

38、rity）、Web服務(wù)事務(wù)（WS-Transaction）等等）的概要隨后也將發(fā)布。在產(chǎn)品全面、穩(wěn)定且廣泛地支持這些概要之前，開(kāi)放標(biāo)準(zhǔn)的使用還沒(méi)有得到保證，并且可能并不總是促進(jìn)互操作性。是否需要支持基本通信協(xié)議及標(biāo)準(zhǔn)（例如 WebSphere MQ、SOAP、WSDL）？或者需要更高級(jí)的功能（例如 Web服務(wù)安全性（WS-Security）、Web 服務(wù)事務(wù)（WS-Transaction）等等）？對(duì)支持更復(fù)雜標(biāo)準(zhǔn)的需求將對(duì)實(shí)現(xiàn)技術(shù)的選擇加以更嚴(yán)格的約束，并且可能意味著使用還不成熟的技術(shù)。當(dāng)果考慮更改現(xiàn)有的基礎(chǔ)架構(gòu)使用的消息格式和協(xié)議（包括可能采用開(kāi)放標(biāo)準(zhǔn)）時(shí)，需要在整個(gè)現(xiàn)有的基礎(chǔ)架構(gòu)中進(jìn)行這些

39、更改嗎？或者很快就要應(yīng)用新的消息格式和協(xié)議嗎？如果正在使用或考慮使用EAI 技術(shù)，該技術(shù)是否有自己的內(nèi)部格式？或者它能夠?qū)㈤_(kāi)放標(biāo)準(zhǔn)處理為內(nèi)部格式嗎？開(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)更重要。如果需要在內(nèi)部使用特定的格式、技術(shù)或標(biāo)準(zhǔn)，這會(huì)給實(shí)現(xiàn)技術(shù)的選擇帶來(lái)限制。將作為服務(wù)公開(kāi)的系統(tǒng)實(shí)現(xiàn)功能支持所需的技術(shù)或開(kāi)放標(biāo)準(zhǔn)（比如 SOAP、JMS或 XML）嗎？如果不支持，ESB 基礎(chǔ)架構(gòu)或適配器將需要在所需的開(kāi)放標(biāo)準(zhǔn)和服務(wù)提供者支持的格式之間進(jìn)行轉(zhuǎn)換的功能。在需要訪問(wèn)遺留系統(tǒng)的情況下，通過(guò)使用更新的基于 XML 的技術(shù)，可以直接支

40、持（例如 CICS SOAP支持）遺留系統(tǒng)的可用性嗎？是否需要單獨(dú)的適配器？遺留平臺(tái)是否支持 XML 處理？如果支持，這種處理是否可以靈活地使用平臺(tái)功能？如果因?yàn)檫@其中的任何原因而導(dǎo)致所需的 SOAP 或 XML 功能對(duì)遺留平臺(tái)不可用，則需要在適配器（比如s J2C ConnectorArchitecture (JCA) 或 WebSphere Business Integration Adaptors）、集成層或 ESB基礎(chǔ)架構(gòu)中使用適當(dāng)?shù)霓D(zhuǎn)換功能。如果 EAI 技術(shù)已經(jīng)可用，它是否使用適當(dāng)?shù)墓δ芑蚪涌诹６葘⒎?wù)作為消息流實(shí)現(xiàn)？它支持哪些連接性協(xié)議（例如JCA、SOAP、WebSphere

41、MQ 以及 Java 遠(yuǎn)程方法調(diào)用（Java Remote Method Invocation）？如果現(xiàn)有消息流不提供所需要的服務(wù)，則需要另外的流程來(lái)執(zhí)行轉(zhuǎn)換。如果 EAI 技術(shù)不直接支持所需的標(biāo)準(zhǔn)，就需要添加一個(gè)網(wǎng)關(guān)組件。應(yīng)該從服務(wù)客戶(hù)端通道以工作負(fù)荷緩沖、安全、登錄等形式提供給服務(wù)提供者系統(tǒng)什么保護(hù)措施？這種緩沖通常是 ESB 基礎(chǔ)架構(gòu)的一個(gè)角色，并且定義它所需要一些功能。如果特定的服務(wù)提供者系統(tǒng)（例如遺留事務(wù)系統(tǒng)（legacytransactional systems）需要額外的保護(hù)，則可以使用專(zhuān)用集成層。應(yīng)該實(shí)現(xiàn)多少服務(wù)？實(shí)現(xiàn)的什么方面應(yīng)該在這些服務(wù)中保持一致？如何實(shí)施一致性（可能在多

42、個(gè)平臺(tái)上和多個(gè)應(yīng)用程序中）？如果只需要非常少的服務(wù)，簡(jiǎn)單的點(diǎn)到點(diǎn)（point-to-point）集成模型可能比較適合。然而，如果需要更多的服務(wù)或者過(guò)一段時(shí)間以后可能還是如此，則添加控制點(diǎn)（比如由ESB 提供的）就變得愈加有益。服務(wù)交互包含在組織內(nèi)部，還是有一些交互在組織外部？這常常是不同于在單個(gè)組織中實(shí)現(xiàn)的 ESB 基礎(chǔ)架構(gòu)的一種情況，因?yàn)閷?duì)安全和服務(wù)路由的需求可能與外部可用的服務(wù)不同。是否需要服務(wù)編排？服務(wù)編排是否涉及短期（short-lived）或長(zhǎng)期（long-lived）（換句話說(shuō)就是有狀態(tài)的）流程，還是兩者都涉及？它們是否包含人工活動(dòng)？在這些需求構(gòu)成業(yè)務(wù)功能的情況下，應(yīng)該在與 ESB

43、 分離的 Service Choreographer組件中實(shí)現(xiàn)編排。關(guān)于是支持長(zhǎng)期有狀態(tài)流程還是支持人工活動(dòng)的需求將對(duì)實(shí)現(xiàn)技術(shù)的選擇產(chǎn)生限制?；A(chǔ)架構(gòu)應(yīng)該支持什么樣的服務(wù)級(jí)需求（例如，服務(wù)響應(yīng)時(shí)間、吞吐量、可用性等等）？隨著時(shí)間的推移，需要如何對(duì)其進(jìn)行擴(kuò)展？一些候選的 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)的。在可以預(yù)見(jiàn)的未來(lái)，關(guān)鍵的體系結(jié)構(gòu)決策將專(zhuān)注于特定開(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)和支持

44、它們的產(chǎn)品是相對(duì)成熟的（例如XML、SOAP等等），有些（例如 Web 服務(wù)安全（WS-Security）比較新，還有一些（例如 Web 服務(wù)事務(wù)）是正在興起的。標(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)的、專(zhuān)有的或自定義技術(shù)的混合方法。是否需要點(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ù)安全模型？如果點(diǎn)到點(diǎn)安全性是可接受的，則許多現(xiàn)有解決方案（例如 SSL 、對(duì)數(shù)

45、據(jù)庫(kù)訪問(wèn)的 J2EE安全性、適配器安全模型等等）就能夠得到應(yīng)用。如果需要端到端安全性，則 Web服務(wù)安全標(biāo)準(zhǔn)就成為可能，提供所有相關(guān)的系統(tǒng)來(lái)支持它。換句話說(shuō)，您可以使用帶有客戶(hù)端消息頭的客戶(hù)端模型，或者傳送像應(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ù)

46、傳遞格式的修改通過(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)最后，我將討論組

47、織考慮如何使用受控和增量的方式發(fā)展它們的體系結(jié)構(gòu)時(shí)可用的選擇。也將說(shuō)明能夠指導(dǎo)您開(kāi)發(fā)自己的 ESB 路線的一些問(wèn)題。理解面向服務(wù)的體系結(jié)構(gòu)中企業(yè)服務(wù)總線場(chǎng)景和解決方案，第 3 部分ESB 場(chǎng)景的解決方案級(jí)別: 初級(jí) HYPERLINK l author1 Rick Robinson（ HYPERLINK mailto:rick_robinson rick_robinson） IT Architect, IBM2004 年 7 月這個(gè)系列文章的第 3 部分介紹了實(shí)現(xiàn)企業(yè)服務(wù)總線（Enterprise ServiceBus，ESB）的場(chǎng)景和解決方案，在此作者分析了 HYPERLINK 第 2部分概

48、述的多個(gè)場(chǎng)景可能的解決方案。 HYPERLINK 在第 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)參閱 HYPERLINK l resources 參考資料）中所描述場(chǎng)景的多種顯而易見(jiàn)的解決方案模式。以下的每個(gè)部分都描述了一種 ESB 實(shí)現(xiàn)方式的解決方案模式，除了基本適配器（BasicAdaptors）模式以外，其他的都是簡(jiǎn)單的點(diǎn)到點(diǎn)（P2P）解決方案。每個(gè)模式都提出了不同的使用現(xiàn)行技術(shù)的實(shí)現(xiàn)選擇，同時(shí)也做出了正反兩方面以及移植方面的考

49、慮。請(qǐng)注意每個(gè)解決方案模式的圖示，它認(rèn)為服務(wù)客戶(hù)端與提供服務(wù)的系統(tǒng)是分離的。當(dāng)然，在許多情況下，相同的系統(tǒng)或應(yīng)用程序既可以是服務(wù)客戶(hù)端也可以是服務(wù)提供者。圖示并非是要排除系統(tǒng)作為單獨(dú)的客戶(hù)端和提供者的可能性，而是承認(rèn)了相同的系統(tǒng)在不同的互操作中可以有兩種不同的工作角色。在決定系統(tǒng)是作為客戶(hù)端角色來(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 Infr

50、astructure 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ò) M

51、Q 或 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)用集成（EnterpriseApplication Integration，EAI）中間件的支持。它也可以提供給多種不同類(lèi)型的系統(tǒng)，包含最新的分布式應(yīng)用服務(wù)器（J2EE 服務(wù)器（如WebSphere），或者微軟的 .NET 系統(tǒng)）

52、、企業(yè)遺留系統(tǒng)（比如 CICS）以及 Commercial Off-the-Shelf 軟件包（比如 SAP或 Siebel）。 HYPERLINK l figure4 圖 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ù)總線功能的某些方面選擇基

53、本適配器的實(shí)現(xiàn)技術(shù)以下是實(shí)現(xiàn)基本適配器的一些選擇：使用遺留系統(tǒng)或應(yīng)用程序直接提供的 SOAP 或 EAI 功能。例如，IBM CICS 目前直接提供對(duì) SOAP 的支持，以及許多系統(tǒng)和應(yīng)用程序包能夠支持MQ 或 SOAP 接口。如果用于提供訪問(wèn)的應(yīng)用程序是用戶(hù)自己開(kāi)發(fā)的應(yīng)用程序且運(yùn)行于應(yīng)用服務(wù)器環(huán)境，或者只要應(yīng)用服務(wù)器運(yùn)行時(shí)環(huán)境和應(yīng)用開(kāi)發(fā)環(huán)境能夠用來(lái)給應(yīng)用程序添加封裝器。例如，WebSphereStudio Application Developer 能夠用來(lái)給部署于 WebSphere Application Server（ApplicationServer）的 J2EE 應(yīng)用程序添加 XM

54、L、SOAP 或 MQ 支持。如果這種支持不可用或不合適（例如， 如果 XML 轉(zhuǎn)換不適合用來(lái)處理現(xiàn)有平臺(tái)上的資源），那么可能需要其他的體系結(jié)構(gòu)層，如 HYPERLINK l figure5 圖 2所示。這可能是托管了與應(yīng)用程序或遺留系統(tǒng)集成的適配器的應(yīng)用服務(wù)器層。例如，Application Developer Integration Edition提供了 Java 2 連接器架構(gòu)（Java 2 Connector Architecture，JCA）連接器技術(shù)來(lái)訪問(wèn)遺留系統(tǒng)（比如 CICS），并通過(guò)WebSphere 運(yùn)行時(shí)環(huán)境為其提供了 J2EE 和 Web 服務(wù)接口。圖 2. 執(zhí)行 XM

55、L 轉(zhuǎn)換處理的其他體系結(jié)構(gòu)層如果使用開(kāi)發(fā)工具來(lái)創(chuàng)建自己的封裝器，那么您可以增強(qiáng)工具提供的功能：通過(guò)創(chuàng)建一個(gè)框架或一組實(shí)用工具類(lèi)來(lái)執(zhí)行通用任務(wù)，比如安全性、日志紀(jì)錄等等。然而，這種方法可能引起范圍蠕變（scopecreep），并最終導(dǎo)致該框架實(shí)際上變成了用戶(hù)開(kāi)發(fā)的 HYPERLINK l 2 服務(wù)網(wǎng)關(guān)或 HYPERLINK l 3 Web 服務(wù)兼容代理。當(dāng)定義框架提議的功能時(shí)，需要注意驗(yàn)證開(kāi)發(fā)和維護(hù)的成本是否合適，以及轉(zhuǎn)換為更復(fù)雜的模式是更不合適的。請(qǐng)參閱 HYPERLINK l resources 參考資料以獲取更多有關(guān)實(shí)現(xiàn)此模式的詳細(xì)信息?；具m配器剖析從正面來(lái)說(shuō)，這種解決方案模式對(duì)新的基本

56、架構(gòu)的需求最低或是根本不需要，并且使用的都是廣泛支持的各種規(guī)范和技術(shù)。從反面來(lái)說(shuō)，像安全、管理等功能都交給了應(yīng)用程序或單個(gè)封裝器的實(shí)現(xiàn)來(lái)處理。由于該模式基于使用協(xié)同操作技術(shù)和開(kāi)放式標(biāo)準(zhǔn)，因此將該模式移植到更復(fù)雜的體系結(jié)構(gòu)也就相對(duì)比較簡(jiǎn)單。模式替換如果以上均不能滿(mǎn)足集成的需求，或者存在一些附加功能或服務(wù)質(zhì)量需求，那么封裝器方式就可能滿(mǎn)足不了需求。如果是這樣，從邏輯上說(shuō)下一步應(yīng)該是 HYPERLINK l 2 服務(wù)網(wǎng)關(guān)。如果需要更高級(jí)ESB 功能，則 HYPERLINK l 3 Web 服務(wù)兼容代理或 HYPERLINK l 4 EAI Infrastructure for SOA模式會(huì)比較適合。

57、服務(wù)網(wǎng)關(guān)解決方案模式這種模式代表了一種基本的 ESB實(shí)現(xiàn)，接近于在 HYPERLINK l 2.2 第 1部分中描述的“最低功能的 ESB 實(shí)現(xiàn)”。服務(wù)網(wǎng)關(guān)一般通過(guò) SOAP/HTTP、MQ、Java 消息服務(wù)（Java MessageService，JMS）等來(lái)支持客戶(hù)端連接，但是也可以通過(guò)諸如 JCA 或 WebSphere 業(yè)務(wù)集成適配器（WebSphere BusinessIntegration Adaptors，WBIA）來(lái)對(duì)服務(wù)提供者支持更廣泛的集成。網(wǎng)關(guān)組件為服務(wù)路由、協(xié)議轉(zhuǎn)換以及安全擔(dān)當(dāng)著中央控制點(diǎn)的角色。網(wǎng)關(guān)能夠用來(lái)向客戶(hù)端提供一致的服務(wù)命名空間（例如，以 URL 的形式為

58、SOAP/HTTP服務(wù)提供命名空間），并可以向服務(wù)提供授權(quán)模型，實(shí)際上這些服務(wù)是由完全不同的系統(tǒng)通過(guò)多種協(xié)議來(lái)提供的。當(dāng)需要向外部合作伙伴（比如客戶(hù)端或供應(yīng)方）公開(kāi)服務(wù)時(shí)，網(wǎng)關(guān)所提供的這些功能便成為一個(gè)明顯的需求。然而當(dāng)需要對(duì)從應(yīng)用程序到用多種系統(tǒng)和技術(shù)實(shí)現(xiàn)的功能的訪問(wèn)進(jìn)行簡(jiǎn)化時(shí)，這些功能在單個(gè)企業(yè)內(nèi)部也很有用。一個(gè)關(guān)鍵的網(wǎng)關(guān)功能是將客戶(hù)端支持的服務(wù)協(xié)議轉(zhuǎn)換為提供方支持的服務(wù)協(xié)議。這些協(xié)議可以包括 SOAP/HTTP、MQ 或SOAP/JMS、JCA、RMI/IIOP 等。候選實(shí)現(xiàn)技術(shù)的能力需要針對(duì)所需要的客戶(hù)端和提供方協(xié)議來(lái)進(jìn)行評(píng)價(jià)。 HYPERLINK l figure6 圖 3描述了服務(wù)

59、網(wǎng)關(guān)解決方案模式圖 3. 使用服務(wù)網(wǎng)關(guān)模式實(shí)現(xiàn) ESB選擇服務(wù)網(wǎng)關(guān)的實(shí)現(xiàn)技術(shù)服務(wù)網(wǎng)關(guān)解決方案模式可以用以下的方式來(lái)實(shí)現(xiàn)：使用打包好的網(wǎng)關(guān)技術(shù)，比如 WebSphere Application Server Network Deployment 或 WebSphereBusiness Integration Connection 提供的 Web ServicesGateway。許多網(wǎng)關(guān)技術(shù)支持某些形式的中間件過(guò)濾器或處理器程序設(shè)計(jì)模型，以實(shí)現(xiàn)自定義增強(qiáng)功能。Web Services Gateway提供了一些可配置的中間件功能。它也支持基于 XML 的遠(yuǎn)程過(guò)程調(diào)用 Java APIs（Java A

60、PIs for XML-based RemoteProcedure Call ，JAX-RPC）規(guī)范中定義的 Web 服務(wù)請(qǐng)求/響應(yīng)處理程序。使用應(yīng)用程序開(kāi)發(fā)和最新應(yīng)用服務(wù)器技術(shù)的運(yùn)行時(shí)功能來(lái)實(shí)現(xiàn)自定義網(wǎng)關(guān)。這可能包含與前面 HYPERLINK l 1 基本適配器解決方案模式中所描述的相同類(lèi)型的適配器。如果需要更高級(jí)的功能，就應(yīng)該考慮更復(fù)雜高級(jí)的 EAI 中間件，比如 WebSphere Business Integration MessageBroker。這種模式的許多實(shí)現(xiàn)存在于遺留技術(shù)中，這些遺留技術(shù)通常沒(méi)有使用 Web服務(wù)技術(shù)。例如，許多組織構(gòu)建了路由器事務(wù)，它對(duì)多種遺留事務(wù)提供了使用類(lèi)