【正文】 如果想要用另一個(gè)服務(wù)實(shí)現(xiàn)來替代原來的服務(wù)實(shí)現(xiàn)，就需要修改應(yīng)用程序代碼并重新部署這些代碼。 HTTP 傳輸協(xié)議被廣泛地使用。 支持服務(wù)提供的多種集成方式，比如 Java 2 連接器、Web 服務(wù)、異步通信、適配器等等 服務(wù)交互 一個(gè)開放且與實(shí)現(xiàn)無關(guān)的服務(wù)消息傳遞與接口模型，它應(yīng)該將應(yīng)用程序代碼從路由服務(wù)和傳輸協(xié)議中分離出來，并允許替代服務(wù)的實(shí)現(xiàn)。 ESB 可以作為分布式的異構(gòu)基礎(chǔ)架構(gòu)進(jìn)行實(shí)現(xiàn)。在本系列文章中，我們不打算詳細(xì)討論上面的每一個(gè)功能類別。 數(shù)據(jù)格式庫 數(shù)據(jù)壓縮 可用性 各種確定的傳遞范例（例如 Web 服務(wù)可靠消息傳遞（WSReliableMessaging）或?qū)?EAI 中間件的支持） 安全性 服務(wù)級(jí)別 服務(wù)聚合 響應(yīng)/請(qǐng)求 ESB 實(shí)現(xiàn)所需的最低功能將在下面支持 SOA 的最低功能的 ESB 實(shí)現(xiàn)部分中進(jìn)行探討。然而，Business Service Choreographer 在編排業(yè)務(wù)流程和服務(wù)中所扮演的角色確定了這種業(yè)務(wù)工作流技術(shù)是一種與基礎(chǔ)架構(gòu)技術(shù) ESB 分離的技術(shù)。圖 2: 分布式 ESB 基礎(chǔ)架構(gòu)的集中控制我還應(yīng)該定位在 SOA 基礎(chǔ)架構(gòu)中 ESB 與其他組件之間的關(guān)系，特別是與 Service Directory、Business Service Choreography、以及 BusinesstoBusiness (B2B) Gateway 這些組件之間的關(guān)系。然而，這并不是真正的差別。然而，基礎(chǔ)架構(gòu)支持在不影響服務(wù)的客戶端的情況下由另一個(gè)服務(wù)實(shí)現(xiàn)替代原有的服務(wù)實(shí)現(xiàn)也是至關(guān)重要的。 利用強(qiáng)調(diào)位置透明性和可互操作性的通信協(xié)議。在接下來的文章中，我將在 SOA 中定義一組 ESB 場(chǎng)景，以定義 ESB 或 SOA 實(shí)現(xiàn)的共同起點(diǎn)。然而，有必要闡明 ESB 究竟是一個(gè)產(chǎn)品、技術(shù)、標(biāo)準(zhǔn)，還是別的什么。與此同時(shí)，我們還是 IBM 開發(fā) SOA 的軟件平臺(tái) SOA Integration Framework 的主力軍。 案，第 1 部分(developerWorks，2003 年 12 月)作者 Rick Robinson。因此， SOA 本身涵蓋了很多的內(nèi)容，也觸及到了系統(tǒng)整體架構(gòu)設(shè)計(jì)、實(shí)現(xiàn)、維護(hù)等各個(gè)方面。8) 安全性 安全性是指確保系統(tǒng)安全不會(huì)被危及的能力。7) 可管理性 可管理性是指管理系統(tǒng)以確保整個(gè)系統(tǒng)的可升級(jí)性、可靠性、可用性、性能和安全性的能力。這是因?yàn)?SOA 架構(gòu)中的不同服務(wù)之間本身就保持了一種無依賴的低耦合關(guān)系；服務(wù)本身是通過統(tǒng)一的接口定義（可以是WSDL）語言來描述具體的服務(wù)內(nèi)容，并且很好地封裝了底層的具體實(shí)現(xiàn)?？煽啃钥梢栽黾酉到y(tǒng)的整體可用性，但即使系統(tǒng)部件出錯(cuò)，有時(shí)卻并不一定會(huì)影響系統(tǒng)的可用性?？煽啃钥赡軙?huì)在一定程度上限制系統(tǒng)的可升級(jí)性。要想升級(jí)已達(dá)到最大負(fù)載能力的系統(tǒng)，你必須增加新的硬件。在較傳統(tǒng)的基于EJB或者XMLRPC的分布式計(jì)算模型中，它們的服務(wù)提供都是通過函數(shù)調(diào)用的方式進(jìn)行的，一個(gè)功能的完成往往需要通過客戶端和服務(wù)器來回很多次的遠(yuǎn)程函數(shù)調(diào)用才能完成。 可靠性是指確保各應(yīng)用及其相關(guān)的所有交易的完整性和一致性的能力； 例如，如果服務(wù)級(jí)別需求中最重要的是系統(tǒng)性能，架構(gòu)設(shè)計(jì)師很有可能不得不在一定程度上犧牲系統(tǒng)的可維護(hù)性及可擴(kuò)展性，以確保滿足系統(tǒng)性能上的要求。在服務(wù)層之上的第4層就是商業(yè)流程層，在這一層中我們利用已經(jīng)封裝好的各種服務(wù)來構(gòu)建商業(yè)系統(tǒng)中的商業(yè)流程。在 SOA 系統(tǒng)中不同的功能模塊可以被分為7層：第一層就是系統(tǒng)已經(jīng)存在的程序資源，例如ERP或者CRM系統(tǒng)等。本文將延續(xù)第一部分的內(nèi)容，向您介紹了 SOA 為企業(yè)級(jí)架構(gòu)設(shè)計(jì)帶來的影響，以及在構(gòu)建基于 SOA 架構(gòu)的企業(yè)系統(tǒng)時(shí)應(yīng)該怎樣保證所構(gòu)建的系統(tǒng)架構(gòu)能夠滿足系統(tǒng)中不同的服務(wù)級(jí)別需求。本文的內(nèi)容只是涉及到了有關(guān)于架構(gòu)方面的一部分內(nèi)容，希望能對(duì)廣大的SOA系統(tǒng)開發(fā)設(shè)計(jì)人員起到一定的幫助作用。另外EJB容器會(huì)自動(dòng)提供對(duì)并發(fā)的支持，作為無狀態(tài)Session Bean實(shí)現(xiàn)的 EJB 服務(wù)端點(diǎn)不必?fù)?dān)心多線程訪問，因?yàn)?EJB 容器必須串行化對(duì)無狀態(tài)會(huì)話 bean 任何特定實(shí)例的請(qǐng)求。當(dāng)某一個(gè)服務(wù)需要依賴時(shí)，我們最好把它定義成具體的業(yè)務(wù)流程（BPEL）。從技術(shù)上講，粗粒度的服務(wù)接口可能是一個(gè)特定服務(wù)的完整執(zhí)行，而細(xì)粒度的服務(wù)接口可能是實(shí)現(xiàn)這個(gè)粗粒度服務(wù)接口的具體的內(nèi)部操作。當(dāng)SOA架構(gòu)師分析和評(píng)估現(xiàn)有系統(tǒng)中所有可能的集成需求的時(shí)候，我們可以發(fā)現(xiàn)實(shí)際上所有集成方式在任何種類的企業(yè)中都有一定程度的體現(xiàn)。為了避免這種情況的出現(xiàn)，定期由架構(gòu)設(shè)計(jì)師主持的開發(fā)團(tuán)隊(duì)內(nèi)部討論是十分重要的。而技術(shù)風(fēng)險(xiǎn)一般指的是一切未知的、未經(jīng)證明的或未經(jīng)測(cè)試所帶來的風(fēng)險(xiǎn)。從角色上來看，SOA 架構(gòu)師不僅會(huì)負(fù)責(zé)端到端的服務(wù)請(qǐng)求者和提供者的設(shè)計(jì)，并且會(huì)負(fù)責(zé)對(duì)系統(tǒng)中非功能服務(wù)請(qǐng)求的調(diào)研和表述。但是，SOA和其它企業(yè)架構(gòu)的不同之處就在于SOA提供的業(yè)務(wù)靈活性。1. 什么是架構(gòu)？什么是基于SOA的架構(gòu)？1．1 什么是架構(gòu)從架構(gòu)設(shè)計(jì)師的角度來看，架構(gòu)就是一套構(gòu)建系統(tǒng)的準(zhǔn)則。本系列兩部分文章將根據(jù)作者自己的理解來幫助大家分析和了解什么是SOA架構(gòu)，SOA將怎樣對(duì)企業(yè)系統(tǒng)架構(gòu)設(shè)計(jì)帶來積極的影響，什么是SOA架構(gòu)設(shè)計(jì)師的角色，以及SOA架構(gòu)師在設(shè)計(jì)SOA系統(tǒng)架構(gòu)時(shí)有哪些應(yīng)該特別注意的地方。因此，基于SOA的架構(gòu)也一定是從企業(yè)的具體需求開始構(gòu)建的。只有具備了必需的能力，架構(gòu)設(shè)計(jì)師才能在關(guān)鍵的時(shí)刻作出困難的決定，這就是一名架構(gòu)設(shè)計(jì)師應(yīng)該承擔(dān)的責(zé)任。所有的架構(gòu)設(shè)計(jì)師的角色都包含了在構(gòu)建一個(gè)系統(tǒng)的一開始就應(yīng)該盡量減少可能存在的技術(shù)風(fēng)險(xiǎn)。如果由架構(gòu)設(shè)計(jì)師構(gòu)造出的系統(tǒng)模型不是很清晰的話，就可能會(huì)影響設(shè)計(jì)和開發(fā)人員對(duì)于整個(gè)系統(tǒng)架構(gòu)的理解。在分析和評(píng)估一個(gè)已有系統(tǒng)體系結(jié)構(gòu)的集成需求時(shí)，我們必須考慮一些更加具體的集成的類型，這主要包括以下幾個(gè)方面：應(yīng)用程序集成的需求，終端用戶界面集成的需求，流程集成的需求以及已有系統(tǒng)信息集成的需求。通常來說，對(duì)于將暴露在整個(gè)系統(tǒng)外部的服務(wù)推薦使用粗粒度的接口，而相對(duì)較細(xì)粒度的服務(wù)接口通常用于企業(yè)系統(tǒng)架構(gòu)的內(nèi)部。無狀態(tài)服務(wù)的設(shè)計(jì) SOA系統(tǒng)架構(gòu)中的具體服務(wù)應(yīng)該都是獨(dú)立的、自包含的請(qǐng)求，在實(shí)現(xiàn)這些服務(wù)的時(shí)候不需要前一個(gè)請(qǐng)求的狀態(tài)，也就是說服務(wù)不應(yīng)該依賴于其他服務(wù)的上下文和狀態(tài)，即SOA架構(gòu)中的服務(wù)應(yīng)該是無狀態(tài)的服務(wù)。EJB 端點(diǎn)是一種很好的選擇，因?yàn)樗箻I(yè)務(wù)邏輯和端點(diǎn)位于同一層上。因此，SOA本身涵蓋了很多的內(nèi)容，也觸及到了系統(tǒng)整體架構(gòu)設(shè)計(jì)、實(shí)現(xiàn)、維護(hù)等各個(gè)方面。聯(lián)系方式：wangq 架構(gòu)設(shè)計(jì)師與 SOA ， 第 2 部分本系列的第 1 部分 介紹了有關(guān)架構(gòu)設(shè)計(jì)師以及 SOA 架構(gòu)的知識(shí)，分析了 SOA 架構(gòu)師在設(shè)計(jì) SOA 系統(tǒng)架構(gòu)時(shí)有哪些應(yīng)該特別注意的地方。1．2 SOA 架構(gòu)的分層模型接下來簡(jiǎn)要介紹一下 SOA 系統(tǒng)中的分層模型，整個(gè) SOA 架構(gòu)的分層模型如圖2所示。(3)技術(shù)功能服務(wù)（technical function service），這類服務(wù)主要完成一些底層的技術(shù)功能，比如說日志服務(wù)以及安全服務(wù)等。架構(gòu)設(shè)計(jì)師在設(shè)計(jì)架構(gòu)過程中需要平衡所有的這些服務(wù)級(jí)別需求。 可升級(jí)性是指當(dāng)系統(tǒng)負(fù)荷加大時(shí)，能夠確保所需的服務(wù)質(zhì)量，而不需要更改整個(gè)系統(tǒng)的架構(gòu)； 對(duì)于架構(gòu)設(shè)計(jì)師來說，無論采取哪種衡量系統(tǒng)性能的方法來構(gòu)建系統(tǒng)架構(gòu)，這些對(duì)于性能的考慮對(duì)系統(tǒng)設(shè)計(jì)開發(fā)人員來說都應(yīng)該是透明的，也就是說對(duì)于系統(tǒng)整體架構(gòu)性能的考慮應(yīng)該是架構(gòu)設(shè)計(jì)師的工作，而不是系統(tǒng)設(shè)計(jì)開發(fā)人員應(yīng)該關(guān)注的事情。如果系統(tǒng)運(yùn)轉(zhuǎn)時(shí)已經(jīng)不能在可接受時(shí)間范圍內(nèi)反應(yīng)，那么這個(gè)系統(tǒng)已經(jīng)到達(dá)了它的最大可升級(jí)狀態(tài)。當(dāng)系統(tǒng)負(fù)荷增加時(shí)，你的系統(tǒng)必須能夠持續(xù)處理需求訪問，并確保系統(tǒng)能夠象負(fù)荷未增加以前一樣正確地處理各個(gè)進(jìn)程。4) 可用性 可用性是指一個(gè)系統(tǒng)應(yīng)確保一項(xiàng)服務(wù)或者資源應(yīng)該總是可被訪問到的。當(dāng)架構(gòu)設(shè)計(jì)師基于 SOA 來構(gòu)建企業(yè)系統(tǒng)架構(gòu)時(shí)，就已經(jīng)隱含地解決了這幾個(gè)可擴(kuò)展性方面的要素?；谶@些文檔，就可以為 SOA 架構(gòu)設(shè)計(jì)師構(gòu)建企業(yè) SOA 架構(gòu)提供很好的文檔參考和支持。有關(guān)于如何利用已有底層架構(gòu)來構(gòu)建 SOA 系統(tǒng)，中國 SOA 設(shè)計(jì)中心已經(jīng)發(fā)表了一系列相關(guān)的文章，大家可以在DeveloperWorks中的 SOA 專欄看到它們。從架構(gòu)設(shè)計(jì)師的角度， SOA 是一種新的設(shè)計(jì)模式，方法學(xué)。企業(yè)服務(wù)總線解決方案剖析，第 1 部分: 企業(yè)服務(wù)總線的基本概念李珉, 高級(jí)軟件工程師，技術(shù)經(jīng)理, IBM 中國軟件開發(fā)實(shí)驗(yàn)室 SOA設(shè)計(jì)中心通過這些不斷增長(zhǎng)的成功案例，我們不僅深入地推廣了 SOA 的理念，樹立了 SOA 成功實(shí)施的范例，也為我們的隊(duì)伍積累了經(jīng)驗(yàn)，培養(yǎng)了人才。最近，企業(yè)服務(wù)總線（Enterprise Service Bus，ESB）的概念被表述為 SOA 基礎(chǔ)架構(gòu)的關(guān)鍵組件（請(qǐng)參見參考資料）。通過考慮特定情形下的需求如何確定對(duì)額外功能的需要，您可以選擇最適合這種情形的實(shí)現(xiàn)技術(shù)。 從最基本的級(jí)別來看，啟用該基礎(chǔ)架構(gòu)涉及到規(guī)劃功能來將服務(wù)請(qǐng)求路由和傳遞給正確的服務(wù)提供者。ESB 結(jié)構(gòu)ESB 有時(shí)被描述為分布式基礎(chǔ)架構(gòu)，這與其他的解決方案形成了對(duì)比，比如消息代理技術(shù)一般被描述為中心輻射型（hubandspoke）。另外的一種能力也是非常重要的，就是以增量方式擴(kuò)展最初的部署來反映不斷變化的需求、集成附加的系統(tǒng)或擴(kuò)展基礎(chǔ)架構(gòu)的物理范圍。Business Service Choreographer 的作用是通過若干業(yè)務(wù)服務(wù)來組合業(yè)務(wù)流程；因此，它將通過 ESB 調(diào)用服務(wù)，然后再次通過 ESB 將業(yè)務(wù)流程公開為客戶端可用的其他服務(wù)。重要的是認(rèn)識(shí)到，當(dāng)前的大多數(shù)場(chǎng)景只需要部分類別中的部分功能。 發(fā)布/訂閱 數(shù)據(jù)庫 事務(wù)（原子事務(wù)、補(bǔ)償、Web 服務(wù)事務(wù)（WSTransaction）） 吞吐量 對(duì)象標(biāo)識(shí)映射 通用業(yè)務(wù)對(duì)象建模 由于這些原因，再加上最近制訂和正在興起的一些相關(guān)標(biāo)準(zhǔn)，當(dāng)今實(shí)現(xiàn) ESB 的許多關(guān)鍵決策都涉及到成熟的專有技術(shù)和不成熟的開放標(biāo)準(zhǔn)之間的權(quán)衡。 支持至少一種可以廣泛使用的傳輸協(xié)議 雖然這種方法依賴于實(shí)現(xiàn)細(xì)節(jié)，但是它往往并不能使服務(wù)實(shí)現(xiàn)的替代變得簡(jiǎn)單；服務(wù)請(qǐng)求者代碼（也可能是開發(fā)工具生成的）通常通過特定地址的特定協(xié)議直接綁定到具體的服務(wù)提供者實(shí)現(xiàn)。 按需操作環(huán)境需求，比如管理與自治功能以及基礎(chǔ)架構(gòu)智能功能。因此，任何 ESB 架構(gòu)都需要盡可能早地確定安全需求，以便在選擇實(shí)現(xiàn)技術(shù)時(shí)可以將它們包括進(jìn)來。 服務(wù)交互 基礎(chǔ)架構(gòu)智能 從這些不同的功能中，我確定了建立 ESB 所需的最低功能，包括通信、集成和服務(wù)交互。