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

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