【正文】 I 技術(shù)可能提供了這樣的模型，但在其他的情況下，需要自定義解決方案。在實(shí)踐中，這經(jīng)常通過使用 XML 模式并結(jié)合服務(wù)身份確認(rèn)、尋址以及業(yè)務(wù)數(shù)據(jù)來實(shí)現(xiàn)。然而，也有不使用 XML 的解決方案，比如某些服務(wù)網(wǎng)關(guān)模式的遺留系統(tǒng)的實(shí)現(xiàn)所使用的文本解決方案。 與數(shù)據(jù)模型無關(guān)的接口模型方面的功能，用于聲明性地定義應(yīng)該如何使用 EAI 基礎(chǔ)架構(gòu)的特性來調(diào)度服務(wù)請(qǐng)求和響應(yīng)。應(yīng)用程序需要一些機(jī)制以解釋接口定義及適當(dāng)?shù)恼{(diào)用 EAI 基礎(chǔ)架構(gòu)。還有，這些機(jī)制可以通過 EAI 技術(shù)提供，可供選擇的技術(shù)包括設(shè)計(jì)與開發(fā)規(guī)范的實(shí)施，或者框架 API 的使用。 框架 API 的開發(fā)和維護(hù)顯然代價(jià)不菲，但是它比實(shí)施跨越多個(gè)應(yīng)用程序規(guī)范要更有效。如果至少大多數(shù)連接到服務(wù)總線的應(yīng)用程序都支持同一種編程語言（比如 Java）的情況下，這樣的方法是最有效的。 業(yè)務(wù)數(shù)據(jù)模型的采用也同樣需要選擇，是采用基于 XML 的、專有的還是自定義的。由于存在很多普通的和具體于特定行業(yè)的 XML 數(shù)據(jù)模型，采用這些模型中的一種可能會(huì)有好處。然而，許多這種模型正處于向 Web 服務(wù)規(guī)范移植的過程中，如果考慮使用這種解決方案模式的原因是由于可用的 Web 服務(wù)技術(shù)出于某些原因而不適合使用，那么就不可以選擇那些規(guī)范。最后，如果 Web 服務(wù)或其他基于規(guī)范的某些形式的訪問需要使用這種自定義模式實(shí)現(xiàn)的服務(wù)，那么就既可以選擇使用 EAI 技術(shù)提供的 Web 服務(wù)支持，也可以添加一個(gè)顯式服務(wù)網(wǎng)關(guān)組件（如果它能夠更好的匹配需求的話）。 EAI 中間件模式剖析由于這種解決方案模式代表了重要的開發(fā)、實(shí)現(xiàn)和維護(hù)工作，所以需要慎重考慮。該模式的優(yōu)點(diǎn)是它與 SOA 原則完全一致，這被反復(fù)證明對(duì)交付業(yè)務(wù)有益，并能夠用成熟的技術(shù)實(shí)現(xiàn)，使之具備企業(yè)級(jí)的功能、彈性和性能。 該解決方案的成本主要有兩方面。首先在于解決方案的最初實(shí)現(xiàn)和隨后進(jìn)行的維護(hù)，其次，在于移植工作，隨著 Web 服務(wù)技術(shù)的成熟并日益引人注目，最終很可能需要采用開放標(biāo)準(zhǔn)的解決方案。 這種模式的采用是一個(gè)即時(shí)的決策，這個(gè)決策依賴于近期或中期的利益來證明是否值得進(jìn)行必要的投入。投入的多少依賴于所使用 EAI 的現(xiàn)有級(jí)別，也依賴于附加定制開發(fā)的工作量多少。近期或中期的定義依賴于單個(gè)組織認(rèn)為新興的 Web 服務(wù)規(guī)范何時(shí)會(huì)足夠的成熟，以滿足他們功能性或非功能性的需求。 EAI 中間件的替換模式Web 服務(wù)兼容代理模式是與 EAI 中間件模式相似的使用開放標(biāo)準(zhǔn)技術(shù)的實(shí)現(xiàn)方式。服務(wù)編排解決方案模式這種模式由專用服務(wù)編排組件的實(shí)現(xiàn)組成。這種組件不是真正的 ESB，但是它通過多種協(xié)議（比如 SOAP/HTTP 或 MQ）支持對(duì)服務(wù)的連接性，這需要或隱含著 ESB 的存在。在有些場(chǎng)景中，這種支持足以對(duì)服務(wù)提供方和服務(wù)器請(qǐng)求方進(jìn)行直接連接。但如果情況并非如此，ESB 可以通過本文描述的任何其他解決方案模式來提供。這就構(gòu)成了完整 SOA 基礎(chǔ)架構(gòu)解決方案模式。 圖 6 說明了服務(wù)編排的實(shí)現(xiàn)。圖 6. 服務(wù)編排的實(shí)現(xiàn)選擇服務(wù)編排的實(shí)現(xiàn)技術(shù)這種解決方案模式中要做的最重要的選擇是，它所需開放標(biāo)準(zhǔn)的級(jí)別。有以下三個(gè)場(chǎng)景： 對(duì)服務(wù)接口和流程建模大規(guī)模地采用 Web 服務(wù)規(guī)范。 對(duì)服務(wù)接口采用 Web 服務(wù)規(guī)范，并結(jié)合使用專有的流程建模技術(shù)。 使用專有的接口和流程建模技術(shù)。 因?yàn)榕c流程建模相關(guān)的 Web 服務(wù)標(biāo)準(zhǔn)（首先是 Web 服務(wù)業(yè)務(wù)流程執(zhí)行語言（Business Process Execution Language for Web Services，BPEL4WS）是最近出現(xiàn)的，為此支持它們的產(chǎn)品還不夠成熟，因此這些問題與該解決方案模式特別相關(guān)。大多數(shù)服務(wù)編排技術(shù)的提供商都將提供專用的及基于標(biāo)準(zhǔn)的混合技術(shù)。例如，這樣的技術(shù)包括： WebSphere Enterprise Process Choreographer 技術(shù)提供了對(duì) Web 服務(wù)接口和流程定義的支持。 MQ Workflow 提供了對(duì)更成熟但更專有的服務(wù)編排技術(shù)的支持，該技術(shù)既有 Web 服務(wù)接口也有專有接口。 如果采用專有技術(shù)，也許為了解決可伸縮性或彈性需求，可以添加服務(wù)網(wǎng)關(guān)組件以提供 Web 服務(wù)連接性。如果選擇 服務(wù)編排技術(shù)不能為服務(wù)提供方（例如，遺留系統(tǒng)或應(yīng)用服務(wù)器）提供充分的集成，那么就需要一個(gè)遵守其中一個(gè)其他解決方案中的 ESB。 服務(wù)編排剖析這種解決方案模式很大程度上依賴于基于規(guī)范的或?qū)Ｓ械慕鉀Q方案是否實(shí)現(xiàn)?；谝?guī)范的解決方案目前還不太成熟，但它最終將能夠提供更好的互操作性。專有解決方案將可能在較為熟悉的模型中提供可伸縮性和彈性，還可以充分利用高互操作性的通信技術(shù)（比如 MQ）。但是，隨著開放標(biāo)準(zhǔn)技術(shù)的成熟和蔓延，這種方案可能最終還是需要一些移植工作。 完整 SOA 基礎(chǔ)架構(gòu)解決方案模式這種模式代表了服務(wù)編排組件與服務(wù)總線實(shí)現(xiàn)的結(jié)合。因?yàn)檫@兩方面在本文的其他部分已有描述，在這里就不更多的描述了，只是說完整的實(shí)現(xiàn)顯然是可能的。一端采用完全專有解決方案，它使用 ESB 和專有服務(wù)編排技術(shù)的 EAI Infrastructure for SOA 模式，另一端采用完全開放標(biāo)準(zhǔn)的解決方案，它使用 ESB 以及適應(yīng)開放標(biāo)準(zhǔn)的服務(wù)編排技術(shù)的 Web 服務(wù)兼容代理模式。 采用 SOA 和 ESB 的主要階段本文描述的模式都涉及到從即時(shí)需求構(gòu)建 ESB，這僅僅是朝更復(fù)雜的 SOA 實(shí)現(xiàn)前進(jìn)的第一步。這一部分討論一些有用的選擇，用于組織考慮如何以受控和漸進(jìn)的方式發(fā)展。我不建議所有的組織都采用一種路線，相反，我想討論一些在設(shè)計(jì) SOA 或 ESB 路線中應(yīng)該考慮的問題。 確定所涉及的直接范圍簡單說來，實(shí)現(xiàn)綜合性的 SOA 主要存在兩個(gè)方面：全功能、有彈性的基礎(chǔ)架構(gòu)的實(shí)現(xiàn)和所有相關(guān)功能以服務(wù)的形式跨業(yè)務(wù)地公開。雖然還不是完全獨(dú)立，但兩個(gè)方面之間存在一定程度的松散耦合，這使組織可以比較靈活的選擇如何實(shí)現(xiàn)它們。 在某些方面，第一個(gè)決策就是是驗(yàn)證 ESB 技術(shù)，還是驗(yàn)證功能性體系結(jié)構(gòu)的 SOA 原則？這個(gè)問題引出了兩個(gè)極端的方法： 豐富的基礎(chǔ)架構(gòu)，受限的功能 在這里，主要涉及的是驗(yàn)證這些技術(shù)的功能?；A(chǔ)架構(gòu)很可能包含復(fù)雜的 ESB 功能（開放標(biāo)準(zhǔn)的或?qū)Ｓ械模⒖赡軜?gòu)成完整 SOA 基礎(chǔ)架構(gòu)解決方案模式。但是這種技術(shù)上方案含有高風(fēng)險(xiǎn)性，并可能含有相對(duì)不成熟的技術(shù)。因此，不要用它去實(shí)現(xiàn)關(guān)鍵的業(yè)務(wù)項(xiàng)目或功能。功能以服務(wù)的形式公開既具有低危險(xiǎn)性，又主要通過可選通路保持傳遞。隨著基礎(chǔ)架構(gòu)功能的驗(yàn)證和成熟，服務(wù)以后將移植到基礎(chǔ)架構(gòu)。 基本的基礎(chǔ)架構(gòu)，豐富的功能 在這里，主要涉及的是業(yè)務(wù)功能以服務(wù)的形式公開，這樣就可以用新的方式訪問或組合這些功能以傳遞業(yè)務(wù)價(jià)值。在這種情況下，預(yù)計(jì)的業(yè)務(wù)利益或其他因素驅(qū)動(dòng)的改變往往變得非常重要，以降低技術(shù)風(fēng)險(xiǎn)。因此，基礎(chǔ)架構(gòu)的實(shí)現(xiàn)或者僅使用最基礎(chǔ)最成熟的 Web 服務(wù)規(guī)范，或者使用更確定的 EAI 技術(shù)。一旦基礎(chǔ)架構(gòu)適當(dāng)且支持服務(wù)互操作性，它的功能今后可以隨著 ESB 技術(shù)的成熟而升級(jí)或移植 。 當(dāng)然，還有兩個(gè)其他的極端方式 什么都不做，或者馬上著手做每件事，但這些可能對(duì)路線的觀點(diǎn)不感興趣。另外一個(gè)的方法在無形地使用。那就是單個(gè)部門、項(xiàng)目或工程漸進(jìn)地采用 SOA 和 ESB 原則、技術(shù)和基礎(chǔ)架構(gòu)。許多組織在 ESB 或 SOA 的進(jìn)程中，可能使用的是這種方式而不是直接了當(dāng)?shù)姆绞?。這種局部采用專門技術(shù)或?qū)嵺`的方式可以對(duì)其提供更成功的檢驗(yàn)，這比大爆炸（bigbang）方式要好得多。這與豐富的架構(gòu)，受限的功能方式比較相似，但它由許多基本的架構(gòu)組成，而不是單個(gè)豐富的架構(gòu)。 實(shí)現(xiàn) SOA 的方法有兩個(gè)方面應(yīng)該在早期確定：對(duì)服務(wù)的內(nèi)部或外部訪問的提供，和一個(gè)解決服務(wù)粒度的方法。支持內(nèi)部或外部訪問的決策將驅(qū)動(dòng)一些因素，包括需要什么級(jí)別的服務(wù)安全性（請(qǐng)參閱影響 ESB 的安全問題），以及是否需要顯式服務(wù)網(wǎng)關(guān)組件以控制外部訪問。正如 EAI Infrastructure for SOA 解決方案模式中所討論的，外部訪問也驅(qū)動(dòng)了 Web 服務(wù)規(guī)范的使用。然而內(nèi)部訪問可能更具靈活性，比如 MQ、RMI/IIOP、或?qū)Ｓ?XML。 服務(wù)粒度問題已經(jīng)在業(yè)界被廣泛地討論（請(qǐng)參閱參考資料）。綜合性的 SOA 可能包含多種粒度的服務(wù)，從技術(shù)操作性的功能（比如 登錄、記賬 等），通過業(yè)務(wù)功能（比如查詢賬目結(jié)算），到業(yè)務(wù)處理（比如處理庫存訂單）。 每個(gè)粒度級(jí)別的服務(wù)都由更低粒度級(jí)別的服務(wù)或其他功能組成。因此，需要考慮一些不同等級(jí)的服務(wù)聚集或編排，它可能適合不止一種實(shí)現(xiàn)技術(shù)。在任何特定情況下都可以處理該問題的一個(gè)實(shí)用方法就是，確認(rèn)、特征化以及對(duì)可用的不同服務(wù)粒度級(jí)別進(jìn)行命名。然后就可以在兩個(gè)不同粒度級(jí)別之間定義聚集或編排需求，并選擇適當(dāng)?shù)膶?shí)現(xiàn)技術(shù)。 本部分的最后，值得注意服務(wù)實(shí)現(xiàn)的自上而下（topdown）和自下而上（bottomup）模型之間聯(lián)系。自下而上方法專注于以服務(wù)的形式實(shí)現(xiàn)應(yīng)用程序和遺留系統(tǒng)的功能。在一般情況下，這涉及使用適配器和開發(fā)環(huán)境來提供合適的接口，并導(dǎo)致相對(duì)細(xì)粒度業(yè)務(wù)功能的啟用。 自上而下方法則更多涉及到解析業(yè)務(wù)系統(tǒng)和組件以確認(rèn)流程和服務(wù)的體系結(jié)構(gòu)處理。這個(gè)趨向于確定了粗粒度的服務(wù)，而這些粗粒度服務(wù)可能是由更多的細(xì)粒度服務(wù)組成的。 許多組織可能會(huì)將這兩種方法都加以運(yùn)用以進(jìn)行服務(wù)確認(rèn)和啟用，某種中間匯合點(diǎn)需要來合并他們。如果這種匯合點(diǎn)在約定的地方明確地對(duì)多種粒度級(jí)別的確認(rèn)和分類，那么它對(duì)于技術(shù)人員來說可能更加簡單。 SOA 的重要階段無論選擇那種方法來實(shí)現(xiàn)完整的 SOA，都必須經(jīng)過許多階段。這個(gè)部分指出和討論了其中的一些重要階段。由于它們?cè)诤艽蟪潭壬溪?dú)立，并且它們實(shí)現(xiàn)的次序依賴于影響單個(gè)組織的很多因素，因此并沒有對(duì)它們排序： 基于標(biāo)準(zhǔn)的安全模型 雖然簡化的或?qū)Ｓ械哪Ｐ涂赡茉诙唐趦?nèi)可以滿足需要，但綜合性的 SOA 必須具備全面且開放標(biāo)準(zhǔn)的安全模型。理解哪些支持 Web 服務(wù)安全規(guī)范的產(chǎn)品能夠滿足組織的需求，這是整個(gè)實(shí)現(xiàn)計(jì)劃的關(guān)鍵部分。 啟用服務(wù)遺留系統(tǒng)和應(yīng)用程序 現(xiàn)代應(yīng)用服務(wù)器（例如，J2EE 服務(wù)器比如 Application Server）的發(fā)展讓組織能夠使用 SQL 和 JDBC 或 ODBC 接口來訪問數(shù)據(jù)庫。同樣，SOA 的發(fā)展將驅(qū)動(dòng)組織能夠?qū)z留事務(wù)和應(yīng)用程序功能進(jìn)行基于服務(wù)的訪問。因此組織可以計(jì)劃定義和實(shí)現(xiàn)用最適當(dāng)形式的服務(wù)來啟用每個(gè)系統(tǒng)?？梢赃x擇利用 XML 或 Web 服務(wù)支持、使用適配器（比如 JCA 適配器）或者使用 EAI 網(wǎng)關(guān)技術(shù)提供遺留系統(tǒng)連接性。 實(shí)現(xiàn)高質(zhì)量服務(wù)基礎(chǔ)架構(gòu) 到目前為止，可利用的最成熟的 Web 服務(wù)支持對(duì)不可靠的通信協(xié)議（SOAP/HTTP 規(guī)范提供了更高質(zhì)量的服務(wù)，比如 Web 服務(wù)可靠消息傳遞（WSReliableMessaging）或 Web 服務(wù)事務(wù)（WSTransaction））還沒有廣泛的支持。目前需要使用 EAI 技術(shù)來為 SOA 提供更高質(zhì)量的服務(wù)。從長遠(yuǎn)來看，組織應(yīng)該在對(duì)新興規(guī)范的支持和對(duì)符合 Web 服務(wù)規(guī)范的 EAI 技術(shù)的加強(qiáng)這兩方面保持平行發(fā)展。 確定的服務(wù)粒度級(jí)別 如上面確定所涉及的直接范圍部分強(qiáng)調(diào)的那樣，確定與 SOA 相關(guān)的粒度級(jí)別以及各級(jí)別間的聚集和編排是非常關(guān)鍵的。每個(gè)粒度級(jí)別（例如，技術(shù)性功能、業(yè)務(wù)功能、業(yè)務(wù)流程等）的實(shí)現(xiàn)和相關(guān)的編排也構(gòu)成了一個(gè)關(guān)鍵的里程碑。 SOA 實(shí)現(xiàn)步驟以下問題在前面兩部分已經(jīng)討論過，您現(xiàn)在可以構(gòu)成 SOA 和服務(wù)總線實(shí)現(xiàn)的一般路線：1. 決定 SOA 技術(shù)或 SOA 功能的哪些元素應(yīng)該優(yōu)先實(shí)現(xiàn)（請(qǐng)參閱確定所涉及的直接范圍）。 2. 指定或定義合適的項(xiàng)目來實(shí)現(xiàn)第一個(gè)解決方案，這既可以是技術(shù)試驗(yàn)、業(yè)務(wù)試驗(yàn)，也可以是存在可接受風(fēng)險(xiǎn)的真實(shí)業(yè)務(wù)項(xiàng)目。 3. 指定 SOA 中那一個(gè) ESB 場(chǎng)景可以用于項(xiàng)目。更多關(guān)于驅(qū)動(dòng) ESB 體系結(jié)構(gòu)和設(shè)計(jì)決策的問題和 ESB 功能模型的需求分析。然后基于這些分析選擇一種解決方案。基于更多的分析以及安全和非功能性需求（請(qǐng)參閱影響 ESB 的安全問題），最后選擇一種合適的實(shí)現(xiàn)技術(shù)。 4. 與這個(gè)工作并行的是，開始規(guī)發(fā)從第一個(gè)實(shí)現(xiàn)到完全綜合性的 SOA 發(fā)展的路線。這項(xiàng)工作依賴于最初試驗(yàn)的重點(diǎn)，并包含基礎(chǔ)架構(gòu)技術(shù)性功能的多個(gè)方面，或啟用其他功能性服務(wù)來利用最初的試驗(yàn)。在這兩種情況下，路線都應(yīng)該包含在上面指出的 SOA 重要階段。 在最初項(xiàng)目范圍之外，還可以計(jì)劃在其他幾個(gè)方向上的發(fā)展： 發(fā)展和提高跨組織的數(shù)據(jù)模型和流程。 實(shí)現(xiàn)應(yīng)用程序階段服務(wù)，并將其納入基礎(chǔ)架構(gòu)。 發(fā)展 SOA 基礎(chǔ)架構(gòu)的技術(shù)性能力。 本系列到此結(jié)束。在這個(gè)系列中，說明了如何從體系結(jié)構(gòu)的觀點(diǎn)上最好地使用 ESB。將來，隨著 SOA 之后的技術(shù)的發(fā)展，您將看到 ESB 的使用和解決方案得到更深入的研究。 29 / 2