【正文】 BM 中國軟件開發(fā)實驗室 SOA設計中心 高級軟件工程師，技術經(jīng)理周志榮 IBM 中國軟件開發(fā)實驗室 SOA設計中心 軟件工程師張柯 IBM 中國軟件開發(fā)實驗室 SOA設計中心 軟件工程師金戈 IBM 中國軟件開發(fā)實驗室 SOA設計中心 資深軟件工程師，技術經(jīng)理 理解面向服務的體系結(jié)構(gòu)中企業(yè)服務總線場景和解決方案，第 1 部分企業(yè)服務總線中的工作角色本文確定了一組最低功能，可以滿足企業(yè)服務總線（Enterprise Service Bus，ESB）與面向服務的體系結(jié)構(gòu)（serviceoriented architecture，SOA）的原則保持一致的基本需要。通過考慮特定情形下的需求如何確定對額外功能的需要，您可以選擇最適合這種情形的實現(xiàn)技術。最近，企業(yè)服務總線（Enterprise Service Bus，ESB）的概念被表述為 SOA 基礎架構(gòu)的關鍵組件（請參見參考資料）。特別是，當前是否可以構(gòu)建 ESB？如果這樣，該如何構(gòu)建？本文將 ESB 描述為由中間件技術實現(xiàn)并支持 SOA 的一組基礎架構(gòu)功能。為了達到此目的，需要將多種功能集中起來并加以分類。本文確定了一組最低功能，可以滿足 ESB 與 SOA 的原則保持一致的基本需要。通過考慮特定情形下的需求如何確定對額外功能的需要，您可以選擇最適合這種情形的實現(xiàn)技術。而解決方案模式又為選擇適當?shù)膶崿F(xiàn)技術提供了指南。同樣，可見的 ESB 產(chǎn)品的可用性和功能也日趨完善?；仨撌譋SB 在 SOA 內(nèi)的工作角色雖然我不打算深入討論 SOA 的定義（請參見參考資料），但是在這里概括一下大部分對 SOA 的描述所適用的原則是很有用的： 圖 1說明了這些原則。圖 1: SOA 的原則為了實現(xiàn) SOA，應用程序和基礎架構(gòu)都必須支持 SOA 原則。從最基本的級別來看，啟用該基礎架構(gòu)涉及到規(guī)劃功能來將服務請求路由和傳遞給正確的服務提供者。這不僅需要根據(jù) SOA 原則指定服務接口，而且需要基礎架構(gòu)允許客戶端代碼以獨立于所涉及的服務位置和通信協(xié)議的方式來調(diào)用服務。ESB 支持這些服務交互功能，并提供集成的通信、消息傳遞以及事件基礎架構(gòu)來支持這些功能。ESB 為 SOA 提供與企業(yè)需要保持一致的基礎架構(gòu)，從而提供合適的服務級別和可管理性、以及異構(gòu)環(huán)境中的操作。ESB 結(jié)構(gòu)ESB 有時被描述為分布式基礎架構(gòu)，這與其他的解決方案形成了對比，比如消息代理技術一般被描述為中心輻射型（hubandspoke）。正在研究兩個不同的問題：控制的集中和基礎架構(gòu)的分布。同樣，這兩個解決方案可能部署在簡單的集中式基礎架構(gòu)中，也可能采用更復雜的分布式方式進行部署。毫無疑問，不同的技術對它們所支持的物理部署模式有不同的約束——有些可能適合于非常廣泛的分布，以支持在很大的地理范圍內(nèi)進行的集成，而其他的可能更適合于部署在本地群集中，以支持高可用性和可伸縮性。另外的一種能力也是非常重要的，就是以增量方式擴展最初的部署來反映不斷變化的需求、集成附加的系統(tǒng)或擴展基礎架構(gòu)的物理范圍。由于上述 SOA 原則對這些組件并沒有嚴格的要求，所以我們可以將它們視為可選組件。圖 3: SOA 中的 ESB 角色ESB 需要某種形式的服務路由目錄（service routing directory）來路由服務請求。Web 服務遠景在業(yè)務服務目錄和服務路由目錄的角色中都放置了一個 UDDI 目錄，因而使得可以動態(tài)發(fā)現(xiàn)和調(diào)用服務。Business Service Choreographer 的作用是通過若干業(yè)務服務來組合業(yè)務流程；因此，它將通過 ESB 調(diào)用服務，然后再次通過 ESB 將業(yè)務流程公開為客戶端可用的其他服務。最后，B2B Gateway 組件的作用是使兩個或多個組織的服務在受控且安全的方式下對彼此可用。雖然有一些網(wǎng)關技術可以提供適合于實現(xiàn) B2B Gateway 組件和 ESB 的功能，但是 B2B Gateway 組件的用途是將其與 ESB 分離。ESB 的功能模型表 1對現(xiàn)有文獻中確定的一些 ESB 功能進行了總結(jié)和分類（請參見參考資料）。重要的是認識到，當前的大多數(shù)場景只需要部分類別中的部分功能。表 1：在現(xiàn)有的文獻中定義的 ESB 功能通信 服務交互 尋址 WebSphere174。 發(fā)布/訂閱 FireandForget，事件 服務接口定義（例如，Web 服務描述語言（Web Services Description Language，WSDL）） 通信和集成所需的服務消息傳遞模型（例如 SOAP 或企業(yè)應用程序集成 (EAI) 中間件模型） 數(shù)據(jù)庫 遺留系統(tǒng)和應用程序適配器 服務映射 應用程序服務器環(huán)境（例如 J2EE 和 .NET） 事務（原子事務、補償、Web 服務事務（WSTransaction）） 身份驗證 不可抵賴性 安全標準（例如 Kerberos 和 Web 服務安全性（WSSecurity）） 吞吐量 其他可以構(gòu)成契約或協(xié)定的持久評估方法 消息處理 管理和自治 基于內(nèi)容的邏輯 有效性 對象標識映射 服務預置和注冊 發(fā)現(xiàn) 自監(jiān)控和自管理 建模 基礎架構(gòu)智能 通用業(yè)務對象建模 B2B 集成的公共與私有模型 業(yè)務規(guī)則 模式識別 上面的許多功能既可以使用專有技術實現(xiàn)，也可以通過利用開放標準實現(xiàn)。由于這些原因，再加上最近制訂和正在興起的一些相關標準，當今實現(xiàn) ESB 的許多關鍵決策都涉及到成熟的專有技術和不成熟的開放標準之間的權衡。相反，我們將集中討論采用或?qū)崿F(xiàn) ESB 的不同方法之間的驅(qū)動策略。支持 SOA 的最低功能的 ESB 實現(xiàn)如果在前面確定的功能中只有一部分和大多數(shù) SOA 場景相關，我們可能會問：實現(xiàn) ESB 所需的一組最低功能由什么構(gòu)成？為此，考慮最被普遍認同的 ESB 定義的原理： 表 2展示了根據(jù)這些原則定義的最低 ESB 功能表 2: 最低的 ESB 功能通信 集成 控制服務尋址和命名的管理功能 支持至少一種可以廣泛使用的傳輸協(xié)議 請注意這些最低功能并不需要使用特別的技術，比如 EAI 中間件、Web 服務、J2EE 或 XML。相反，最低功能幾乎只需簡單地使用 SOAP/HTTP 和 WSDL 就可以實現(xiàn)（當然不是所有的情況都這樣）： 然而，這些 SOAP/HTTP 和 WSDL 的基本應用只是點到點（pointtopoint）的集成，并不能實現(xiàn)一些 ESB 需要的關鍵功能： 服務名稱通過每個適配器單獨進行控制的，服務路由控制則分散在由服務客戶端調(diào)用的地址、HTTP 基礎架構(gòu)和分配給適配器的服務名稱之間。 雖然這種方法依賴于實現(xiàn)細節(jié)，但是它往往并不能使服務實現(xiàn)的替代變得簡單；服務請求者代碼（也可能是開發(fā)工具生成的）通常通過特定地址的特定協(xié)議直接綁定到具體的服務提供者實現(xiàn)。 當然，在許多甚至是大多數(shù)情形中往往需要其他的功能，并且這種需要變得越來越常見。 服務質(zhì)量和服務級別功能。 高級 SOA 概念，例如服務編排、目錄、轉(zhuǎn)換等等。 按需操作環(huán)境需求，比如管理與自治功能以及基礎架構(gòu)智能功能。 跨越具有不同所有權的多個網(wǎng)絡、多個協(xié)議以及多個域的真正意義上的異步操作。例如，如果服務請求不需要提供身份驗證或授權，實現(xiàn)技術的選擇就可以非常的廣泛。例如：1. 是否可以接受通信基礎架構(gòu)中的安全性，例如，是否在 EAI 中間件服務器之間使用安全套接字層（Secure Socket Layer，SSL）互相驗證，或者是否在使用 HTTPS 協(xié)議？ 2. 是否可以接受在參與系統(tǒng)之間單獨的點到點（pointtopoint）安全性，或者是否需要端到端（endtoend）模型？例如，是否有必要通過類似于代理的中間件系統(tǒng)來把客戶端身份傳遞到服務實現(xiàn)的最終提供者？ 3. 是否可以接受應用層中的安全性，例如，客戶端代碼是否能夠執(zhí)行帶有用戶 ID 和密碼的基本 HTTP 身份驗證，或者是否能夠把這些信息作為應用程序數(shù)據(jù)傳遞給服務？ 4. 是否需要遵守行業(yè)安全標準，例如 Kerberos 或 WSSecurity？ 雖然所有這些都是可能的，但是行業(yè)的發(fā)展方向是基礎架構(gòu)和中間件支持的符合標準的安全性（例如 Web 服務安全性（WSSecurity））功能。因此，任何 ESB 架構(gòu)都需要盡可能早地確定安全需求，以便在選擇實現(xiàn)技術時可以將它們包括進來?；谶@些原則，我提出了需要一個基礎架構(gòu)組件，這個組件可以提供路由功能，以便使服務能夠彼此交互，同時還能夠支持使用另一個服務實現(xiàn)來替換原有的服務實現(xiàn)。ESB 在維持集中控制的同時提供分布式的基礎架構(gòu)，因而需要一些形式的服務路由目錄，并且還可能需要業(yè)務服務目錄。ESB 的許多功能包括提供： 服務交互 質(zhì)量服務 服務級別 管理及自治服務 基礎架構(gòu)智能 從這些不同的功能中，我確定了建立 ESB 所需的最低功能，包括通信、集成和服務交互。回頁首致謝如果作者沒有與下列人員進行討論，就不會有本文的存在，他們中的所有人都為本文貢獻了很好的想法和思想：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 全球站點上的英文原文.關于作者Rick Robinson 是 IBM 的一名 IT 架構(gòu)師，他于 1997 年 3 月作為一名開發(fā)人員加入該公司。Rick 更關注技術而不是行業(yè)，但是在過去的三年里他花了大量的時間和金融領域的公司一起工作。在加入 IBM 之前，Rick 在攻讀物理博士