理解SOA體系結(jié)構(gòu)中ESB場(chǎng)景與解決方案

1、引言最新的 IT 集成是使用 Web 服務(wù)技術(shù)實(shí)現(xiàn)面向服務(wù)的體系結(jié)構(gòu)（SOA），有許多優(yōu)秀的文章講述了該技術(shù)的好處和相關(guān)的實(shí)踐。最近，企業(yè)服務(wù)總線（Enterprise Service Bus，ESB）的概念被表述為 SOA 基礎(chǔ)架構(gòu)的關(guā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á)到此目的，需要將多種功能集中起來并加以分類。然而，并不是 E

2、SB 能夠傳遞值的每一種情形都需要所有的功能。本文確定了一組最低功能，可以滿足 ESB 與 SOA 的原則保持一致的基本需要。通過確定這些最低功能，您可以確定利用何種現(xiàn)有技術(shù)來實(shí)現(xiàn)支持 SOA 的 ESB。通過考慮特定情形下的需求如何確定對(duì)額外功能的需要，您可以選擇最適合這種情形的實(shí)現(xiàn)技術(shù)。隨著 ESB 解決方案的發(fā)展和成熟，它所需要的功能也在不斷地發(fā)展。同樣，可見的 ESB 產(chǎn)品的可用性和功能也日趨完善。因此，在本系列的最后一篇文章中，我將考慮 SOA 和 ESB 的發(fā)展路線，以指導(dǎo) ESB 功能和技術(shù)的最初應(yīng)用，并且闡述如何選擇循序漸進(jìn)的方法。ESB 在 SOA 內(nèi)的工作角色雖然我不打算深

3、入討論 SOA 的定義，但是在這里概括一下大部分對(duì) SOA 的描述所適用的原則是很有用的：1.利用顯式的與實(shí)現(xiàn)無關(guān)的接口來定義服務(wù)。接口無關(guān)性2.利用強(qiáng)調(diào)位置透明性和可互操作性的通信協(xié)議。通信透明性3.封裝可重用業(yè)務(wù)功能的服務(wù)的定義。重用圖 1說明了這些原則。注意，雖然 Web 服務(wù)技術(shù)非常符合這些原則，但它并不是唯一符合這些原則的技術(shù)。 圖 1: SOA 的原則為了實(shí)現(xiàn) SOA，應(yīng)用程序和基礎(chǔ)架構(gòu)都必須支持 SOA 原則。啟用 SOA 應(yīng)用程序涉及到創(chuàng)建服務(wù)接口，服務(wù)接口可以直接也可以間接地通過使用適配器用于現(xiàn)有的或新的功能。從最基本的級(jí)別來看，啟用該基礎(chǔ)架構(gòu)涉及到規(guī)劃功能來將服務(wù)

4、請(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é)議的方式來調(diào)用服務(wù)。這樣的服務(wù)路由和替代是 ESB 的許多功能中的一部分。    ESB 支持這些服務(wù)交互功能，并提供集成的通信、消息傳遞以及事件基礎(chǔ)架構(gòu)來支持這些功能。因此，它將當(dāng)今正在使用的主要企業(yè)集成模式組合成一個(gè)實(shí)體。ESB 為 SOA 提供與企業(yè)需要保持一致的基礎(chǔ)架構(gòu)，從而提供合適的服務(wù)級(jí)別和可管理性、以及異構(gòu)環(huán)境中的操作。

5、    本文剩余部分將討論 ESB 在 SOA 中的角色，包括它提供的除了基本的路由和傳輸以外的功能，如下面的ESB 功能模型部分中所述。ESB 結(jié)構(gòu)    ESB 有時(shí)被描述為分布式基礎(chǔ)架構(gòu)，這與其他的解決方案形成了對(duì)比，比如消息代理技術(shù)一般被描述為中心輻射型（hub-and-spoke）。然而，這并不是真正的差別。正在研究?jī)蓚€(gè)不同的問題：控制的集中和基礎(chǔ)架構(gòu)的分布。ESB 和中心輻射型（hub-and-spoke）解決方案都集中控制配置，比如服務(wù)交互的路由、服務(wù)命名等等。同樣，這兩個(gè)解決方案可能部署在簡(jiǎn)單的集中式基礎(chǔ)架構(gòu)中，也可能

6、采用更復(fù)雜的分布式方式進(jìn)行部署。圖 2展示了這一點(diǎn)。    毫無疑問，不同的技術(shù)對(duì)它們所支持的物理部署模式有不同的約束有些可能適合于非常廣泛的分布，以支持在很大的地理范圍內(nèi)進(jìn)行的集成，而其他的可能更適合于部署在本地群集中，以支持高可用性和可伸縮性。使物理分布需求與候選技術(shù)的功能相匹配是 ESB 設(shè)計(jì)的一個(gè)重要方面。另外的一種能力也是非常重要的，就是以增量方式擴(kuò)展最初的部署來反映不斷變化的需求、集成附加的系統(tǒng)或擴(kuò)展基礎(chǔ)架構(gòu)的物理范圍。圖 2: 分布式 ESB 基礎(chǔ)架構(gòu)的集中控制1. 我還應(yīng)該定位在 SOA 基礎(chǔ)架構(gòu)中 ESB 與其他組件之間的關(guān)系，特別是與 Serv

7、ice Directory、Business Service Choreography動(dòng)作設(shè)計(jì)、以及 Business-to-Business (B2B) Gateway 這些組件之間的關(guān)系。由于上述 SOA 原則對(duì)這些組件并沒有嚴(yán)格的要求，所以我們可以將它們視為可選組件圖 3展示的 SOA 說明了這些組件之間的關(guān)系。圖 3: SOA 中的 ESB 角色    ESB 需要某種形式的服務(wù)路由目錄（service routing路由 directory）來路由服務(wù)請(qǐng)求。然而，SOA 可能還有單獨(dú)的業(yè)務(wù)服務(wù)目錄（business service directory），

8、其最基本的形式可能是設(shè)計(jì)時(shí)服務(wù)目錄，用于在組織的整個(gè)開發(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 的作用是通過若干業(yè)務(wù)服務(wù)來組合業(yè)務(wù)流程；因此，它將通過 ESB 調(diào)用服務(wù)，然后再次通過 ESB 將業(yè)務(wù)流程公開為客戶端可用的其他服務(wù)。然而，Business Service Choreographer 在編排業(yè)務(wù)流程和服務(wù)中所扮演的角

9、色確定了這種業(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é)和分類。雖然有一些

10、功能非?；A(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 功能上面的許多功能既可以使用專有技術(shù)實(shí)現(xiàn)，也可以通過利用開放標(biāo)準(zhǔn)實(shí)現(xiàn)。然而，使用不同的技術(shù)來實(shí)現(xiàn) ESB 可能會(huì)使它們的性能、可伸縮性和可靠性這些特性顯著不同，同時(shí) ESB 功能和所支持的開放標(biāo)準(zhǔn)也會(huì)有所不同。由于這些原因，再加上最近制訂和正在興起的一些相關(guān)標(biāo)準(zhǔn)，當(dāng)今實(shí)現(xiàn) ESB 的許多關(guān)鍵決策都涉及到成熟的專有技術(shù)和

11、不成熟的開放標(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ì)問：實(shí)現(xiàn) ESB 所需的一組最低功能由什么構(gòu)成？為此，考慮最被普遍認(rèn)同的 ESB 定義的原理：    1.ESB 是一種邏輯體系結(jié)構(gòu)組件，它提供與 SOA 的原則保持一致的集成基礎(chǔ)架構(gòu)。

12、60;   2.SOA 原則需要使用與實(shí)現(xiàn)無關(guān)的的接口、強(qiáng)調(diào)位置透明性和可互操作性的通信協(xié)議、相對(duì)粗粒度和封裝可重用功能的服務(wù)定義。    3.ESB 可以作為分布式的異構(gòu)基礎(chǔ)架構(gòu)進(jìn)行實(shí)現(xiàn)。    4.ESB 提供了管理服務(wù)基礎(chǔ)架構(gòu)的方法和在分布式異構(gòu)環(huán)境中進(jìn)行操作的功能。    表 2展示了根據(jù)這些原則定義的最低 ESB 功能表 2: 最低的 ESB 功能請(qǐng)注意這些最低功能并不需要使用特別的技術(shù)，比如 EAI 中間件、Web 服務(wù)、J2EE 或 XML。這些技術(shù)的使用非常接近也非常符

13、合需求，但是不必強(qiáng)制要求使用它們。相反，最低功能幾乎只需簡(jiǎn)單地使用 SOAP/HTTP 和 WSDL 就可以實(shí)現(xiàn)（當(dāng)然不是所有的情況都這樣）：1.URL 尋址和現(xiàn)有的 HTTP 和 DNS 基礎(chǔ)架構(gòu)提供了一個(gè)具有路由服務(wù)和位置透明性的“總線（bus）”。2.SOAP/HTTP 支持請(qǐng)求-響應(yīng)（Request-Response）通信規(guī)范。3.HTTP 傳輸協(xié)議被廣泛地使用。4.SOAP 和 WSDL 是開放、與實(shí)現(xiàn)無關(guān)的服務(wù)通信和連接模型。然而，這些 SOAP/HTTP 和 WSDL 的基本應(yīng)用只是點(diǎn)到點(diǎn)（point-to-point）的集成，并不能實(shí)現(xiàn)一些 ESB 需要的關(guān)鍵功能：1.目前還沒

14、有用于控制服務(wù)尋址和命名的管理功能。服務(wù)名稱通過每個(gè)適配器單獨(dú)進(jìn)行控制的，服務(wù)路由控制則分散在由服務(wù)客戶端調(diào)用的地址、HTTP 基礎(chǔ)架構(gòu)和分配給適配器的服務(wù)名稱之間。2.雖然這種方法依賴于實(shí)現(xiàn)細(xì)節(jié)，但是它往往并不能使服務(wù)實(shí)現(xiàn)的替代變得簡(jiǎn)單；服務(wù)請(qǐng)求者代碼（也可能是開發(fā)工具生成的）通常通過特定地址的特定協(xié)議直接綁定到具體的服務(wù)提供者實(shí)現(xiàn)。如果想要用另一個(gè)服務(wù)實(shí)現(xiàn)來替代原來的服務(wù)實(shí)現(xiàn)，就需要修改應(yīng)用程序代碼并重新部署這些代碼。    當(dāng)然，在許多甚至是大多數(shù)情形中往往需要其他的功能，并且這種需要變得越來越常見。特別地，不管是現(xiàn)在還是以后，下面的需求類型可能會(huì)導(dǎo)致更復(fù)雜

15、高級(jí)的技術(shù)的使用：    1.服務(wù)質(zhì)量和服務(wù)級(jí)別功能。    2.高級(jí) SOA 概念，例如服務(wù)編排、目錄、轉(zhuǎn)換等等。    3.按需操作環(huán)境需求，比如管理與自治功能以及基礎(chǔ)架構(gòu)智能功能。    4.跨越具有不同所有權(quán)的多個(gè)網(wǎng)絡(luò)、多個(gè)協(xié)議以及多個(gè)域的真正意義上的異步操作。影響 ESB 的安全問題    我不想在這里直接提出安全需求，不過它們對(duì)選擇 ESB 的實(shí)現(xiàn)技術(shù)非常重要。例如，如果服務(wù)請(qǐng)求不需要提供身份驗(yàn)證或授權(quán)，實(shí)現(xiàn)技術(shù)的選擇就可以非常的廣泛

16、。更有可能的情況是，如果需要一些安全級(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）模型？例如，是否有必要通過類似于代理的中間件系統(tǒng)來把客戶端身份傳遞到服務(wù)實(shí)現(xiàn)的最終提供者？  

17、60; 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ā)展的過程中，而不是已經(jīng)確定了，這里尤其需要特別考慮的就是它們

18、的互操作性。因此，任何 ESB 架構(gòu)都需要盡可能早地確定安全需求，以便在選擇實(shí)現(xiàn)技術(shù)時(shí)可以將它們包括進(jìn)來。    結(jié)束語    在本文中，討論了大多數(shù)通用的 SOA 原則，以及它們與 Web 服務(wù)技術(shù)的關(guān)聯(lián)?；谶@些原則，我提出了需要一個(gè)基礎(chǔ)架構(gòu)組件，這個(gè)組件可以提供路由功能，以便使服務(wù)能夠彼此交互，同時(shí)還能夠支持使用另一個(gè)服務(wù)實(shí)現(xiàn)來替換原有的服務(wù)實(shí)現(xiàn)。這些功能都是通過 ESB 實(shí)現(xiàn)的。    ESB 在維持集中控制的同時(shí)提供分布式的基礎(chǔ)架構(gòu)，因而需要一些形式的服務(wù)路由目錄，并且還可能需要業(yè)務(wù)服務(wù)目錄。Business Service Choreographer 從 ESB 調(diào)用服務(wù)，然后通過 ESB 把這些流程作為新的服務(wù)公開。    ESB 的許多功能包括提供：    1.通信