一種探索面向服務(wù)的體系結(jié)構(gòu) (SOA) 的價值的方法是如何給價值等式的業(yè)務(wù)和 IT 端提供足夠的靈活性。當(dāng)一組可組合的業(yè)務(wù)流程元素被定義為業(yè)務(wù)的主要功能時，就創(chuàng)造了業(yè)務(wù)價值。然后，可以將這些業(yè)務(wù)元素組合成流程來創(chuàng)建業(yè)務(wù)模型，從而得到靈活的 IT 基礎(chǔ)結(jié)構(gòu)（其中包含支持這些特定流程元素的服務(wù)）更為有效的支持。
了解靈活性的另一個方法是對將來的可擴展性進(jìn)行評估。這是通過在企業(yè)體系結(jié)構(gòu)中引入服務(wù)層來實現(xiàn)的?？梢酝ㄟ^一組松散耦合的服務(wù)接口來協(xié)作實現(xiàn)業(yè)務(wù)目標(biāo)，從而使用 SOA 對打包的應(yīng)用程序和現(xiàn)有系統(tǒng)進(jìn)行集成。因而，與軟件包和應(yīng)用程序的點到點集成相比，打包的應(yīng)用程序能以更靈活的方式進(jìn)行組合和匹配；它們通過實現(xiàn)企業(yè)服務(wù)模型（其中定義了一組服務(wù)）要求的功能來實現(xiàn) SOA 的一致性。
SOA 的這種靈活性是模式（即策略模式）的再現(xiàn)。在此模式中，服務(wù)用于將接口與其實現(xiàn)分離開來，通過使用遠(yuǎn)程服務(wù)策略，實現(xiàn)將無需綁定到分布式系統(tǒng)體系結(jié)構(gòu)內(nèi)的通信協(xié)議上。本文將介紹的另一個方面是 David Parnas 于 1972 年在標(biāo)題為“On the Criteria To Be Used in Decomposing Systems Into Modules”的文章（請參閱參考資料部分）中提到的應(yīng)用程序，它將人們引入了 SOA 中的服務(wù)世界。
在這篇開創(chuàng)性的文章中，Parnas 描述了用于將大型復(fù)雜計算機應(yīng)用程序劃分為一系列組件或模塊的標(biāo)準(zhǔn)，這些組件或模塊可以進(jìn)行互連，以形成滿足系統(tǒng)的基本功能要求的網(wǎng)絡(luò)。雖然經(jīng)常將這篇文章作為提倡信息隱藏（這本來就是面向?qū)ο缶幊痰那吧恚┑膬?nèi)容引用，不過，實際上這篇文章遠(yuǎn)不只討論信息隱藏技術(shù)的具體應(yīng)用，而深入到了我稱之為外化的技術(shù)。外化是關(guān)于封裝更改的技術(shù)。外化的相關(guān)標(biāo)準(zhǔn)和技術(shù)可以在面向變化的分析（Variation-Oriented Anlaysis，VOA——請參閱參考資料）中找到。面向變化的分析和設(shè)計（Variation-Oriented Analysis and Design，VOAD）指出，用于驅(qū)動系統(tǒng)功能及其非功能性需求的規(guī)范的需求基礎(chǔ)結(jié)構(gòu)不僅依賴于一組公共組件（或支持應(yīng)用程序功能的組件集），而且更重要的是，依賴于結(jié)構(gòu)中的變化如何執(zhí)行其功能。這是除了作為驅(qū)動應(yīng)用程序的要求之外的其他用途——這些結(jié)構(gòu)中的變化和行為可以看作業(yè)務(wù)意圖驅(qū)動的功能的基礎(chǔ)主題中的變化。
在 VOAD 中，如果有必要，可以將應(yīng)用程序中變化比較頻繁的元素從功能更穩(wěn)定且存在時間更長的部分中分離出來?？梢詫⑦@些“更改類型”視為集中于應(yīng)用程序以及體系結(jié)構(gòu)內(nèi)的三種基本元素。這三種基本元素包括：
實際上，推動采用 Web 服務(wù)和 SOA 的因素是其可以提供的靈活性。這種靈活性在許多方面都表現(xiàn)得非常明顯。關(guān)鍵因素是請求調(diào)用功能的能力，這些功能現(xiàn)在可能由特定業(yè)務(wù)線向組織內(nèi)部提供，不過同樣保留以后選擇備用服務(wù)提供者的權(quán)利。此新的服務(wù)提供者可以在組織內(nèi)的其他位置（另一個業(yè)務(wù)線），也可以是組織的生態(tài)系統(tǒng)內(nèi)的業(yè)務(wù)合作伙伴（請參閱本系列的第 1 部分，以了解如何構(gòu)建服務(wù)生態(tài)系統(tǒng)——請參閱參考資料）或以 IT 功能的形式提供服務(wù)的第三方供應(yīng)商。
很多企業(yè)非常感興趣的是，能夠保留基于一組可能更改的業(yè)務(wù)協(xié)議和需求來選擇實現(xiàn)的權(quán)利。此靈活性可以提供并支持巨大的業(yè)務(wù)靈活性。
IT 中的這種靈活性可以提供并支持業(yè)務(wù)角度的靈活性，它是通過將接口與實現(xiàn)以及實現(xiàn)與通信協(xié)議綁定分離的組合策略模式來實現(xiàn)的。該策略模式通常使用單個編程語言在單個地址空間內(nèi)實現(xiàn)。但是，當(dāng)涉及不綁定到相同的地址空間（而表現(xiàn)為分布式系統(tǒng)調(diào)用或遠(yuǎn)程過程調(diào)用）的綁定類型時，為了實現(xiàn)在編譯時或運行時動態(tài)綁定到服務(wù)提供者的目標(biāo)，將此模式稱為遠(yuǎn)程服務(wù)策略或分布式策略。
分布式系統(tǒng)要求能夠接入分布在不同地址空間的組件之間的基本通信協(xié)議的資源，但要求盡可能以最無縫和透明的方式接入。Web 服務(wù)標(biāo)準(zhǔn)在提供支持此類基礎(chǔ)通信以啟用分布式系統(tǒng)調(diào)用的開放標(biāo)準(zhǔn)方面尤其成功，特別在作為構(gòu)成 World Wide Web 的基礎(chǔ)的高速電信網(wǎng)絡(luò)方面更是如此。
為了更好地理解如何使用 SOA 實現(xiàn)靈活性，讓我們了解一下通過服務(wù)組合這一概念所帶來的靈活性的程度。
但在此之前，讓我們談?wù)動嬎恪⒔M合和協(xié)作三者之間的重要區(qū)別，我個人認(rèn)為對其進(jìn)行區(qū)分很有必要。計算是通過使用通用編程語言（如 Java? 或 C#）執(zhí)行的細(xì)粒度活動，通用編程語言一般包括數(shù)學(xué)計算、Boolean 計算和基于這些計算的函數(shù)執(zhí)行。組合語言（如 Piccola）的目的在于提供少量語法來實現(xiàn)組件裝配的目標(biāo)。另一方面，協(xié)作是由流定義的（如 Business Process Execution Language for Web Services (BPEL4WS) 或 DAML-S），這可能是工作流或其他形式的有目的的組件集成行為，旨在實現(xiàn)協(xié)作目標(biāo)（例如，支持某個業(yè)務(wù)）。其他人已經(jīng)強調(diào)了為了進(jìn)行此組合而對集成服務(wù)的要求。我將在下面有關(guān)組合的部分中對此進(jìn)行更詳細(xì)的討論。
在 SOA 的世界中，服務(wù)無處不在（也就是說基礎(chǔ)結(jié)構(gòu)是服務(wù)，其可以組合成應(yīng)用程序）。服務(wù)質(zhì)量 (QoS) 和靈活性是使用這種體系結(jié)構(gòu)樣式開發(fā)的應(yīng)用程序的兩個最受歡迎的特征。實現(xiàn)業(yè)務(wù)靈活性的一種方式是借助構(gòu)建為 SOA 且運行良好的靈活 IT 基礎(chǔ)結(jié)構(gòu)，總的說來，這種方式安全可靠，能夠滿足業(yè)務(wù)的 QoS 要求。SOA 主要通過其三個一流的構(gòu)造來提供靈活性的：服務(wù)、組件（實現(xiàn)服務(wù)）和流（或流程）。
這三個主要 SOA 構(gòu)造均提供不同類型的靈活性。例如，從服務(wù)的角度來看，靈活性（及其“姊妹概念”重用）是通過將接口與實現(xiàn)及具體協(xié)議綁定分離來實現(xiàn)的。其中有一種特殊的組件類型，稱為企業(yè)組件（請參閱參考資料），此類組件可以提供服務(wù)的實現(xiàn)。它們可以確保 QoS。
隨著組織（以及整個行業(yè)）通過實現(xiàn) SOA 承諾不斷成熟，應(yīng)用程序?qū)⒃絹碓蕉嗟匾苑?wù)為基礎(chǔ)進(jìn)行構(gòu)建，而不是以組件為基礎(chǔ)采用硬編碼方式連接而成。當(dāng)服務(wù)通過某種流（流程）機制組合成一個整體時，就取得了這樣的發(fā)展。協(xié)調(diào)和編排是類似的組合：松散耦合且基于標(biāo)準(zhǔn) (BPEL)。但是，早期的采用者可以創(chuàng)建具有較多的組件硬編碼連接類型的服務(wù)組合，其中的某些服務(wù)（業(yè)務(wù)功能的松散耦合單元）與組件進(jìn)行組合，以產(chǎn)生實際良好運行的組合。不過，與通過服務(wù)編排完成的組合相比，這種組合的靈活性要略遜一籌。這樣，您可以將 SOA 體系結(jié)構(gòu)設(shè)計看作是通向可動態(tài)重新配置 (DRC) 的體系結(jié)構(gòu)樣式的一種途徑，如圖 1 中所示。
因此，在完全成熟的 SOA 中，每個可調(diào)用功能單元都是服務(wù)，這些服務(wù)通過編排組合在一起，從而以服務(wù)組合為基礎(chǔ)創(chuàng)建應(yīng)用程序。
而組合 就是通過裝配較小（通常也同樣靈活）的構(gòu)建塊來構(gòu)建較大的結(jié)構(gòu)的過程。組合常常對其服務(wù)的狀態(tài)進(jìn)行管理，與 BPEL 引擎處理其所組合的服務(wù)的方式相似。
但在當(dāng)今的現(xiàn)實世界中（與想象的或在不遠(yuǎn)的將來的情況相對），您并不能總是僅從服務(wù)的松散耦合編排創(chuàng)建組合。在很多情況下，您必須在靈活性和 QoS 之間進(jìn)行權(quán)衡，以便最終得到的服務(wù)、組合服務(wù)和它們組成或支持的應(yīng)用程序能夠良好執(zhí)行，并且可以擴展。
讓我們繼續(xù)討論在進(jìn)行與這些權(quán)衡相關(guān)的決策時遇到的一些常見場景。
讓我們首先提出一些相關(guān)概念并對其進(jìn)行定義，從而確定一些基本原則。圖 2 演示了組合。
服務(wù)組合可以包含提供部分功能的組件，并且可以將服務(wù)和組件的功能進(jìn)行聚合以滿足業(yè)務(wù)流程的需要。它可以通過在松散耦合的服務(wù)之間創(chuàng)建松散耦合的流來完成此工作。但對于組件，由于存在硬耦合，因此服務(wù)質(zhì)量依賴于最弱的鏈接：提供最低服務(wù)質(zhì)量的服務(wù)或組件。因此，對于要求很高性能或者存在其他約束（如依賴此組件上的其他業(yè)務(wù)線）的組合（服務(wù)或組件）的這些元素，應(yīng)該習(xí)慣于在組合內(nèi)對其調(diào)用進(jìn)行硬編碼。隨著工具和平臺的不斷成熟，或許您可以對組件進(jìn)行外化，為其創(chuàng)建一個接口，然后將其作為固有的服務(wù)進(jìn)行調(diào)用，同時享有由此帶來的所有靈活性。
讓我們接下來看看基于銀行示例的各種場景，我將通過這些場景指導(dǎo)您完成面向服務(wù)的建模和體系結(jié)構(gòu)（Service-Oriented Modeling and Architecture，SOMA——請參閱參考資料）的實現(xiàn)階段。這里我將重點討論服務(wù)實現(xiàn)。
我經(jīng)常聽到我的客戶問的一個問題是：“我是應(yīng)該將一個特定的功能作為服務(wù)公開（靈活），還是應(yīng)該將其作為對現(xiàn)有組件的直接調(diào)用公開（緊密耦合或 QoS 可能更佳）？”讓我們看看下面的圖 3，以了解如何完成此工作。
讓我們通過一個相當(dāng)常見的場景來仔細(xì)了解此問題：對于每個業(yè)務(wù)線（如政府貸款、個人貸款和商業(yè)貸款），銀行都具有相應(yīng)的批處理、遺留系統(tǒng)、多個數(shù)據(jù)庫和多個應(yīng)用程序。
圖 4 通過一些示例演示了各種類型的可組合性。首先，讓我們了解一下這些橢圓和線條的含義。橢圓表示服務(wù)（取自 UML 用例圖標(biāo)），而線條則是控制和消息的流（同上）。每個服務(wù)均提供獨特的功能部分，并且具有可通過控制該服務(wù)或為其分配的策略訪問的相關(guān)服務(wù)質(zhì)量。
讓我們對各種可組合性進(jìn)行更仔細(xì)的了解：
替換。在這種類型中，業(yè)務(wù)干系人可以在需要該服務(wù)的功能和服務(wù)水平協(xié)議的所有流程內(nèi)使用該服務(wù)。每個 S(x) 都表示一個服務(wù)（功能和服務(wù)質(zhì)量）。
合并或單一訪問點。在這種類型中，可以將服務(wù)作為重復(fù)使用的業(yè)務(wù)功能的單一訪問點進(jìn)行重用，如針對不同類型的客戶的貸款服務(wù)或支付處理服務(wù)。
在簡單的情況下，合并或單一訪問點和替換或多或少有些相同。同時請注意，所有這些都是可組合性的不同說法，體現(xiàn)了針對以下問題的不同設(shè)計決策：給定的服務(wù)是否為“良好服務(wù)”——換句話說，我是否應(yīng)建議為該業(yè)務(wù)提供資金以及應(yīng)該如何決定實現(xiàn)此服務(wù)？這個服務(wù)的“優(yōu)劣”問題可由稱為 Service Litmus Test 的技術(shù)加以解決，我將在本系列后面的部分中對其進(jìn)行討論。
為該銀行構(gòu)造的 VOA 表明一些貸款處理系統(tǒng)的基礎(chǔ)功能有重疊，該重疊部分就是要在這些貸款處理系統(tǒng)之外進(jìn)行重構(gòu)的公共部分。在此情況下，單個貸款處理服務(wù)就可以有效地處理與合作伙伴、客戶及組織間的所有貸款處理請求。
這將為異構(gòu)貸款處理系統(tǒng)提供單一訪問點，現(xiàn)在可以采用虛擬化的方式對這些異構(gòu)系統(tǒng)進(jìn)行合并，并逐步退役，以減少維護(hù)冗余功能的成本。這種虛擬化可提供通過引入服務(wù)層實現(xiàn)的增量功能。服務(wù)層以單一訪問點的形式提供服務(wù)，并且可以幫助逐步對服務(wù)的實現(xiàn)者進(jìn)行物理合并。此合并是由預(yù)算可用性和技術(shù)優(yōu)先級（如成本削減、易于維護(hù)和復(fù)雜性降低）驅(qū)動的。這常常通過引入服務(wù)集成器模式來實現(xiàn)（本系列的第 1 部分——同時請參閱參考資料）。
服務(wù)集成器模式由其他更細(xì)粒度的模式（即服務(wù)路由器 (SR)）組成。此模式可以與網(wǎng)關(guān)（根據(jù)情況不同，可能為 Web 服務(wù)網(wǎng)關(guān)或 ESB 網(wǎng)關(guān)）一起用于跟蹤和將請求映射到恰當(dāng)?shù)哪繕?biāo)服務(wù)；決定將請求發(fā)送到哪個系統(tǒng)。下面的圖 6 顯示了此過程。它將隨后對結(jié)果進(jìn)行處理，并將其操作的結(jié)果提供給服務(wù)使用者。服務(wù)路由器 (SR) 連接到后端系統(tǒng)或其他服務(wù)。SR 可以直接通過其基礎(chǔ)服務(wù)實現(xiàn)者（也就是實現(xiàn)其功能的服務(wù)組件）來訪問遺留系統(tǒng)。只有在不可能通過服務(wù)適配器包裝每個遺留系統(tǒng)來進(jìn)行訪問的情況下，才建議從基礎(chǔ)服務(wù)組件進(jìn)行直接訪問。在這兩種情況下，服務(wù)路由器都支持服務(wù)集成器，服務(wù)集成器現(xiàn)在是業(yè)務(wù)功能或流程的單一訪問點。
務(wù)必注意，如果 QoS 問題讓您有所顧忌，恰當(dāng)?shù)捏w系結(jié)構(gòu)決策通常可能是對這些方法進(jìn)行組合。遺留系統(tǒng)、性能和其他 QoS 特性可能會阻礙使用最優(yōu)的訪問機制：不管是純服務(wù)、硬編碼連接或混合方法。
混合服務(wù)路由器（用于貸款流程 3）的一部分連接是硬編碼連接（由于遺留約束），而其他部分則支持通過 SOA 中的服務(wù)靈活調(diào)用。對于打包應(yīng)用程序的訪問通常都是這樣。
該混合路由器方法的結(jié)果之一是，您現(xiàn)在可能無法像對待實際作為 Web 服務(wù)實現(xiàn)的服務(wù)一樣方便而靈活地重新組合貸款流程 3。
重新組合或上下文更改。業(yè)務(wù)干系人可以建議重新組合服務(wù)，并在其他業(yè)務(wù)或應(yīng)用程序中對其進(jìn)行重用，以滿足新的業(yè)務(wù)目標(biāo)和支持對業(yè)務(wù)流程的新更改。
自包含。在這種情況下，體系結(jié)構(gòu)決策是圍繞此問題進(jìn)行的：盡管服務(wù)可能在運行時與其他服務(wù)協(xié)作執(zhí)行業(yè)務(wù)流程，它是否可以獨立部署以滿足業(yè)務(wù)目標(biāo)？
服務(wù)之間沒有隱式的依賴關(guān)系，所有的依賴關(guān)系都是可替換的或自包含的。
如果我公開的服務(wù)依賴于某個組件，而此組件本身又依賴于數(shù)據(jù)庫和批處理遺留系統(tǒng)，則該服務(wù)將會保留這些依賴關(guān)系。這將最終幫助提高可維護(hù)性和服務(wù)質(zhì)量，并幫助避免重新組合此服務(wù)。事實上，在通常情況下最好將此服務(wù)的可見性范圍隱藏在服務(wù)路由器之后，這樣在遺留或獨立服務(wù)供應(yīng)商（Independent Service Vendor，ISV）軟件包被替換后，服務(wù)的接口和使用服務(wù)（如貸款流程 1）組合而成的應(yīng)用程序就不需要進(jìn)行大幅度的更改（如果確實需要更改）。
業(yè)務(wù)原子性。服務(wù)是否是業(yè)務(wù)流程中的單個步驟的軟件封裝？如果您已經(jīng)完成了流程分解，并根據(jù)使用相關(guān)技術(shù)（如面向服務(wù)的建模和體系結(jié)構(gòu)）進(jìn)行的以業(yè)務(wù)為中心的分析來選擇服務(wù)，則答案為“是”?？梢栽?a >圖 9 中看到這一過程。
圖 10 引入了一個簡單的概念。我發(fā)現(xiàn)這個概念在描述體系結(jié)構(gòu)和關(guān)于在 SOA 內(nèi)耦合服務(wù)和組件的實現(xiàn)決策方面非常有幫助。塊關(guān)系圖經(jīng)常與更正式的概念（如 UML）一起使用，以促進(jìn)技術(shù)社區(qū)和非技術(shù)社區(qū)之間以及干系人之間的理解和溝通；當(dāng)每個關(guān)系圖都考慮了有關(guān)耦合的決策時，就達(dá)到了此目的。
在圖 10 中，您可以看到 Service C 到 Component C 具有松散耦合的實現(xiàn)連接；Service B 具有到 Component B 的緊密耦合連接。
運行時和動態(tài)可重新配置表現(xiàn)為，基礎(chǔ)軟件體系結(jié)構(gòu)有能力快速響應(yīng)和動態(tài)更改組件和服務(wù)的功能以及它們之間的相互連接來應(yīng)對某個問題。然后，它們可以重新配置必要的操作方面（也稱為非功能方面）來保持 QoS 和服務(wù)水平協(xié)議。
性能、安全和互操作性的實際考慮使得這些模型目前難于實現(xiàn)，不過這些領(lǐng)域的 Web 服務(wù)標(biāo)準(zhǔn)的發(fā)展和研究（如面向語法的對象設(shè)計——Grammar-Oriented Object Design，GOOD——請參閱參考資料）有望緩解其中的很多問題。
上述特征已經(jīng)在硬件相關(guān)的系統(tǒng)中廣泛地研究和實現(xiàn)了若干年。我們希望將此功能擴展到軟件系統(tǒng)和體系結(jié)構(gòu)中。為了進(jìn)行此工作，我們不能直接從硬件領(lǐng)域借用關(guān)系圖；除了常見的（錯誤）概念之外，軟件組件和服務(wù)并不能與構(gòu)建模塊完美地適應(yīng)；軟件組件和服務(wù)更像身體中的器官，它們是更小的組件的聚合體，在一定的上下文中提供獨特的功能和目標(biāo)。它們也對其功能和操作能力的更改具有一定的適應(yīng)能力。
因此，軟件服務(wù)和組件的可重新配置性是實現(xiàn)最大 IT 靈活性因而實現(xiàn)業(yè)務(wù)靈活性的關(guān)鍵成功因素。您可以利用 Web 服務(wù)標(biāo)準(zhǔn)和通過一些組合方法和技術(shù)應(yīng)用創(chuàng)新方法（如 GOOD）來實現(xiàn)這一目標(biāo)。
學(xué)習(xí)
Ali Arsanjani 博士是一位高級技術(shù)人員，擔(dān)任 IBM Global Services 的 SOA and Web Services Center of Excellence 的首席架構(gòu)師。他具有 21 年的 IT 從業(yè)經(jīng)驗，參與過很多大型系統(tǒng)的分布式軟件體系結(jié)構(gòu)的設(shè)計和交付工作。他的研究興趣和寫作領(lǐng)域包括軟件設(shè)計模式、軟件體系結(jié)構(gòu)、基于組件和面向服務(wù)的體系結(jié)構(gòu)，以及面向語法的對象設(shè)計。他專長于構(gòu)建可重新動態(tài)配置的軟件系統(tǒng)。您可以通過 arsanjan@us.ibm.com 與他聯(lián)系。
