【文章內(nèi)容簡介】 務(wù)進(jìn)行普遍的內(nèi)部或外部訪問的需要。需要各種安全、聚合、轉(zhuǎn)換、路由以及服務(wù)編排功能。IT 組織以響應(yīng)所支持的業(yè)務(wù)不斷增加的需求，從而使得能夠在業(yè)務(wù)系統(tǒng)之間進(jìn)行更普遍且更靈活的集成。 最相關(guān)的問題相關(guān)的解決方案模式（請參見下一篇文章）全部 實(shí)現(xiàn) Full SOA Infrastructure。 驅(qū)動 ESB 體系結(jié)構(gòu)和設(shè)計(jì)決策的問題為了確定用于 ESB 的合適解決方案模式和實(shí)現(xiàn)技術(shù)，需要對特定的 ESB 功能需求進(jìn)行詳細(xì)的分析。下面的問題旨在幫助進(jìn)行這一過程，而前面的部分指出了與每個場景相關(guān)的特定問題。1. 現(xiàn)有功能及其數(shù)據(jù)接口是否與您想要提供的服務(wù)相匹配？您是否能夠修改或聚合應(yīng)用程序？ o 如果不可以，則轉(zhuǎn)換或聚合功能就需要由適配器或 ESB 體系結(jié)構(gòu)來提供，或者不得不由服務(wù)客戶端來完成。 2. 服務(wù)是否可以以一些通用業(yè)務(wù)數(shù)據(jù)模型的形式公開？如果可以，則實(shí)現(xiàn)這些服務(wù)的系統(tǒng)是否已經(jīng)支持該模型？或者說可以使它們這樣做？ o 如果服務(wù)不可以，則轉(zhuǎn)換或聚合功能就需要由適配器或 ESB 體系結(jié)構(gòu)來提供。 3. 是否需要開放標(biāo)準(zhǔn)？或者是否可以通過 EAI 中間件來實(shí)現(xiàn)適當(dāng)?shù)幕ゲ僮餍?？如果需要開放標(biāo)準(zhǔn)的話，則哪些開放標(biāo)準(zhǔn)是適合的？ o 雖然使用開放標(biāo)準(zhǔn)是實(shí)現(xiàn)互操作性的一種途徑，但專有的 EAI 中間件也具有高度的互操作性，并且往往要成熟得多。另外，許多組織還擁有廣泛的現(xiàn)有基礎(chǔ)架構(gòu)，在一些場景中，它們可能會使得開放標(biāo)準(zhǔn)的作用幾近于無。 o 在需要開放標(biāo)準(zhǔn)的場景中，Web 服務(wù)也許是這些情況下最明顯的選擇。不過，您也可以應(yīng)用 Java Messaging Service (JMS)、JDBC、基本 XML 或者一些其他的技術(shù)（比如 EDI 或業(yè)界通用的 XML 格式。 o 在實(shí)踐中，不能總是假定相同標(biāo)準(zhǔn)的不同實(shí)現(xiàn)之間具有互操作性，特別是對于近來出現(xiàn)或剛剛興起的標(biāo)準(zhǔn)。對于 Web 服務(wù)，Web 服務(wù)互操作性組織（Web Services Interoperability Organization）發(fā)布了使用 SOAP 和 WSDL 的互操作性的基本概要，其他更高級的標(biāo)準(zhǔn)（例如 Web 服務(wù)安全性（WSSecurity）、Web 服務(wù)事務(wù)（WSTransaction）等等）的概要隨后也將發(fā)布。在產(chǎn)品全面、穩(wěn)定且廣泛地支持這些概要之前，開放標(biāo)準(zhǔn)的使用還沒有得到保證，并且可能并不總是促進(jìn)互操作性。 4. 是否需要支持基本通信協(xié)議及標(biāo)準(zhǔn)（例如 WebSphere MQ、SOAP、WSDL）？或者需要更高級的功能（例如 Web 服務(wù)安全性（WSSecurity）、Web 服務(wù)事務(wù)（WSTransaction）等等）？ o 對支持更復(fù)雜標(biāo)準(zhǔn)的需求將對實(shí)現(xiàn)技術(shù)的選擇加以更嚴(yán)格的約束，并且可能意味著使用還不成熟的技術(shù)。 5. 當(dāng)果考慮更改現(xiàn)有的基礎(chǔ)架構(gòu)使用的消息格式和協(xié)議（包括可能采用開放標(biāo)準(zhǔn)）時，需要在整個現(xiàn)有的基礎(chǔ)架構(gòu)中進(jìn)行這些更改嗎？或者很快就要應(yīng)用新的消息格式和協(xié)議嗎？如果正在使用或考慮使用 EAI 技術(shù)，該技術(shù)是否有自己的內(nèi)部格式？或者它能夠?qū)㈤_放標(biāo)準(zhǔn)處理為內(nèi)部格式嗎？ o 開放標(biāo)準(zhǔn)的任何應(yīng)用都是受擴(kuò)展訪問的需求驅(qū)動的，因此它們對現(xiàn)有基礎(chǔ)架構(gòu)的接口的可用性比在內(nèi)部使用的這樣的標(biāo)準(zhǔn)更重要。 o 如果需要在內(nèi)部使用特定的格式、技術(shù)或標(biāo)準(zhǔn)，這會給實(shí)現(xiàn)技術(shù)的選擇帶來限制。 6. 將作為服務(wù)公開的系統(tǒng)實(shí)現(xiàn)功能支持所需的技術(shù)或開放標(biāo)準(zhǔn)（比如 SOAP、JMS或 XML）嗎？ o 如果不支持，ESB 基礎(chǔ)架構(gòu)或適配器將需要在所需的開放標(biāo)準(zhǔn)和服務(wù)提供者支持的格式之間進(jìn)行轉(zhuǎn)換的功能。 7. 在需要訪問遺留系統(tǒng)的情況下，通過使用更新的基于 XML 的技術(shù)，可以直接支持（例如 CICS SOAP 支持）遺留系統(tǒng)的可用性嗎？是否需要單獨(dú)的適配器？遺留平臺是否支持 XML 處理？如果支持，這種處理是否可以靈活地使用平臺功能？ o 如果因?yàn)檫@其中的任何原因而導(dǎo)致所需的 SOAP 或 XML 功能對遺留平臺不可用，則需要在適配器（比如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ù)，則需要另外的流程來執(zhí)行轉(zhuǎn)換。如果 EAI 技術(shù)不直接支持所需的標(biāo)準(zhǔn)，就需要添加一個網(wǎng)關(guān)組件。 9. 應(yīng)該從服務(wù)客戶端通道以工作負(fù)荷緩沖、安全、登錄等形式提供給服務(wù)提供者系統(tǒng)什么保護(hù)措施？ o 這種緩沖通常是 ESB 基礎(chǔ)架構(gòu)的一個角色，并且定義它所需要一些功能。如果特定的服務(wù)提供者系統(tǒng)（例如遺留事務(wù)系統(tǒng)（legacy transactional systems））需要額外的保護(hù)，則可以使用專用集成層。 10. 應(yīng)該實(shí)現(xiàn)多少服務(wù)？實(shí)現(xiàn)的什么方面應(yīng)該在這些服務(wù)中保持一致？如何實(shí)施一致性（可能在多個平臺上和多個應(yīng)用程序中）？ o 如果只需要非常少的服務(wù)，簡單的點(diǎn)到點(diǎn)（pointtopoint）集成模型可能比較適合。然而，如果需要更多的服務(wù)或者過一段時間以后可能還是如此，則添加控制點(diǎn)（比如由 ESB 提供的）就變得愈加有益。 11. 服務(wù)交互包含在組織內(nèi)部，還是有一些交互在組織外部？ o 這常常是不同于在單個組織中實(shí)現(xiàn)的 ESB 基礎(chǔ)架構(gòu)的一種情況，因?yàn)閷Π踩头?wù)路由的需求可能與外部可用的服務(wù)不同。 12. 是否需要服務(wù)編排？服務(wù)編排是否涉及短期（shortlived）或長期（longlived）（換句話說就是有狀態(tài)的）流程，還是兩者都涉及？它們是否包含人工活動？ o 在這些需求構(gòu)成業(yè)務(wù)功能的情況下，應(yīng)該在與 ESB 分離的 Service Choreographer 組件中實(shí)現(xiàn)編排。關(guān)于是支持長期有狀態(tài)流程還是支持人工活動的需求將對實(shí)現(xiàn)技術(shù)的選擇產(chǎn)生限制。 13. 基礎(chǔ)架構(gòu)應(yīng)該支持什么樣的服務(wù)級需求（例如，服務(wù)響應(yīng)時間、吞吐量、可用性等等）？隨著時間的推移，需要如何對其進(jìn)行擴(kuò)展？ o 一些候選的 ESB 實(shí)現(xiàn)技術(shù)相對較新，并且可能僅僅在有限的服務(wù)級進(jìn)行過測試。同樣，由于相關(guān)的開放標(biāo)準(zhǔn)不是最近制訂就是正在興起的，所以在更多的既定產(chǎn)品和技術(shù)中對它們的支持也是新出現(xiàn)的。 o 在可以預(yù)見的未來，關(guān)鍵的體系結(jié)構(gòu)決策將專注于特定開放標(biāo)準(zhǔn)優(yōu)點(diǎn)的平衡，針對服務(wù)級需求的新興或成熟的產(chǎn)品技術(shù)支持這些開放標(biāo)準(zhǔn)。制訂這些即時決策需要考慮到有些標(biāo)準(zhǔn)和支持它們的產(chǎn)品是相對成熟的（例如 XML、SOAP等等），有些（例如 Web 服務(wù)安全（WSSecurity））比較新，還有一些（例如 Web 服務(wù)事務(wù)）是正在興起的。 o 標(biāo)準(zhǔn)的優(yōu)點(diǎn)之間的權(quán)衡和經(jīng)過驗(yàn)證的服務(wù)級特征往往驅(qū)動一個結(jié)合了 ESB 與 SOA 體系結(jié)構(gòu)中適應(yīng)標(biāo)準(zhǔn)的、專有的或自定義技術(shù)的混合方法。 14. 是否需要點(diǎn)到點(diǎn)（pointtopoint）或端到端（endtoend）安全模型（例如，ESB 是否可以簡單的對服務(wù)請求授權(quán)，還是需要將請求者的身份或其他憑證傳遞給服務(wù)提供者）？是否需要使用應(yīng)用程序或遺留安全系統(tǒng)來集成服務(wù)安全模型？ o 如果點(diǎn)到點(diǎn)安全性是可接受的，則許多現(xiàn)有解決方案（例如 SSL 、對數(shù)據(jù)庫訪問的 J2EE 安全性、適配器安全模型等等）就能夠得到應(yīng)用。如果需要端到端安全性，則 Web 服務(wù)安全標(biāo)準(zhǔn)就成為可能，提供所有相關(guān)的系統(tǒng)來支持它。換句話說，您可以使用帶有客戶端消息頭的客戶端模型，或者傳送像應(yīng)用程序數(shù)據(jù)這樣的安全信息。 結(jié)束語本文確定了一些 ESB 實(shí)現(xiàn)中最常見的場景，以及對相應(yīng)的解決方案直接產(chǎn)生影響的問題。雖然沒有完全涵蓋所有的隱藏問題，但這些是其中最常遇到的。我們概述了從兩個系統(tǒng)的基本集成到實(shí)現(xiàn)支持高質(zhì)量服務(wù)和 Web 服務(wù)標(biāo)準(zhǔn)的 SOA 體系結(jié)構(gòu)的常見場景。并描述了需要重視的十四個不同的問題： 現(xiàn)有數(shù)據(jù)接口 業(yè)務(wù)數(shù)據(jù)模型 開放標(biāo)準(zhǔn)的使用 對基本或高級通信協(xié)議的支持 通過現(xiàn)有系統(tǒng)對數(shù)據(jù)傳遞格式的修改 通過新技術(shù)公開現(xiàn)有服務(wù) 對遺留系統(tǒng)的訪問 現(xiàn)有 EAI 技術(shù) 需要的保護(hù)措施 需要提供多少服務(wù)和需要的一致性程度 公司內(nèi)部以及與其他公司之間的互操作 對服務(wù)編排的需求 服務(wù)級需求的基礎(chǔ)架構(gòu)級支持 點(diǎn)到點(diǎn)（pointtopoint）或端到端（endtoend）安全模型的使用 理解這些基本場景和問題為您開發(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)時可用的選擇。也將說明能夠指導(dǎo)您開發(fā)自己的 ESB 路線的一些問題。理解面向服務(wù)的體系結(jié)構(gòu)中企業(yè)服務(wù)總線場景和解決方案，第 3 部分ESB 場景的解決方案級別: 初級Rick Robinson （rick_robinson@） IT Architect, IBM2004 年 7 月 這個系列文章的第 3 部分介紹了實(shí)現(xiàn)企業(yè)服務(wù)總線（Enterprise Service Bus，ESB）的場景和解決方案，在此作者分析了第 2 部分概述的多個場景可能的解決方案。在第 1 部分中說明的總線工作角色提供了這些場景的基礎(chǔ)。 下面繼續(xù)這個系列來構(gòu)建面向服務(wù)體系結(jié)構(gòu)（ServiceOriented Architecture，SOA）的企業(yè)服務(wù)總線，現(xiàn)在我們來看一看第 2 部分（請參閱參考資料）中所描述場景的多種顯而易見的解決方案模式。 以下的每個部分都描述了一種 ESB 實(shí)現(xiàn)方式的解決方案模式，除了基本適配器（Basic Adaptors）模式以外，其他的都是簡單的點(diǎn)到點(diǎn)（P2P）解決方案。每個模式都提出了不同的使用現(xiàn)行技術(shù)的實(shí)現(xiàn)選擇，同時也做出了正反兩方面以及移植方面的考慮。 請注意每個解決方案模式的圖示，它認(rèn)為服務(wù)客戶端與提供服務(wù)的系統(tǒng)是分離的。當(dāng)然，在許多情況下，相同的系統(tǒng)或應(yīng)用程序既可以是服務(wù)客戶端也可以是服務(wù)提供者。圖示并非是要排除系統(tǒng)作為單獨(dú)的客戶端和提供者的可能性，而是承認(rèn)了相同的系統(tǒng)在不同的互操作中可以有兩種不同的工作角色。在決定系統(tǒng)是作為客戶端角色來選擇、確認(rèn)和調(diào)用服務(wù)，還是作為提供者角色來接收、處理和響應(yīng)服務(wù)請求時，這個區(qū)別通常很重要。 本部分的解決方案模式有： 基本適配器（Basic Adaptors） 服務(wù)網(wǎng)關(guān) Web 服務(wù)兼容的代理（Web Servicepliant 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） 基本適配器解決方案模式這種解決方案通過封裝器或適配器技術(shù)來實(shí)現(xiàn)簡單的點(diǎn)到點(diǎn)（P2P）服務(wù)集成，而不是真正的 ESB。這種技術(shù)通過 WSDL 定義的 SOAP 訪問或者其他可互操作的產(chǎn)品技術(shù)（比如 IBM WebSphere174。 MQ （MQ））來實(shí)現(xiàn)集成。如果這些技術(shù)沒有為服務(wù)接口定義（比如 WSDL）提供本地模型，那么將需要使用自定義模型來實(shí)現(xiàn) SOA 規(guī)范。 雖然設(shè)計(jì)比較簡單，但是從該模式中可以獲得的好處卻不可低估。例如，通過 MQ 或 SOAP/HTTP 進(jìn)行的直接集成仍然可以是松散耦合式的，尤其是互操作的特征是使用接口來聲明時。在將來的某個時候，對于支持最初使用的集成技術(shù)的 ESB 基礎(chǔ)架構(gòu)，我們可以通過它來中斷集成。還可以在進(jìn)程級別的服務(wù)命名和尋址之上實(shí)現(xiàn)控制級別。 現(xiàn)在已經(jīng)有各種各樣的適配器可用，而且也可以通過開發(fā)工具或運(yùn)行時技術(shù)來創(chuàng)建新的適配器。并能使其提供對 Web 服務(wù)規(guī)范和 企業(yè)應(yīng)用集成（Enterprise Application Integration，EAI）中間件的支持。它也可以提供給多種不同類型的系統(tǒng)，包含最新的分布式應(yīng)用服務(wù)器（J2EE 服務(wù)器（如 WebSphere），或者微軟的 .NET 系統(tǒng)）、企業(yè)遺留系統(tǒng)（比如 CICS174。）以及 Commer