精通SOA 構建企業(yè)應用服務組合

申請免費試用、咨詢電話：400-8352-114

盡管面向服務的體系結構或SOA仍然是新生事物，但許多公司正逐步認識到需要采用SOA方法作為執(zhí)行滿足業(yè)務需求的解決方案的方法。采用這種方法的一個關鍵步驟是構建可重用服務的組合。

    SOA表示新應用程序的設計、開發(fā)和集成方式的根本性轉(zhuǎn)變。它還將企業(yè)應用程序的開發(fā)簡化為模塊化業(yè)務服務，可以輕松地對其進行集成和重用。

    SOA的一個主要優(yōu)點是縮小了業(yè)務和IT之間的差距。作為需求收集活動的一部分，將業(yè)務和技術需求與機構的與項目有關的主要業(yè)務目標相對應，將對確保項目與業(yè)務需求同步大有幫助。

    著手構建服務組合的動力主要源于意識到需要保持業(yè)務需求與IT項目之間的一致性。一般來說，該過程始于初步確定所需的服務，進而發(fā)展到發(fā)現(xiàn)它們所依賴的服務與資源（如定義特定業(yè)務規(guī)則的政策等）并對其進行分類。理想狀況下，這樣做的成果是一套面向服務的業(yè)務應用程序，應用程序可以修正和重用，以滿足企業(yè)不斷變化的業(yè)務需求。

    盡管在執(zhí)行SOA時有許多問題需要考慮（如業(yè)務流程的編排、用戶界面的開發(fā)以及支持安全和性能的基礎架構等），但是獲得服務組合在邏輯上顯然是第一步。在”精通SOA“系列的此部分中，您可以大致了解用于構建服務組合的框架。

    SOA管理驅(qū)動組合構建

    對SOA組合的創(chuàng)建起積極推動作用的通常是那些最為關心SOA管理相關問題的人。理想狀況下，這個”管理委員會“應當是相關組的交叉項，包括業(yè)務流程所有者、系統(tǒng)架構師和開發(fā)人員。

    SOA管理是一個寬泛的題目，值得專門撰文加以論述。不過，在這里我們不妨將其概括為”將SOA的靈活性與傳統(tǒng)IT體系結構的控制及可預言性相結合的框架“。

    SOA管理在本文中一般涉及下列方面：

    ◆　服務與相關資源的生命周期管理

    ◆　相關性管理

    ◆　策略的應用與管理

    ◆　安全性和運行時策略執(zhí)行

    ◆　服務可用性

    ◆　服務供應

    ◆　執(zhí)行能夠管理不斷增長的服務組合的管理平臺的重要意義遠遠不止于對技術基礎架構和運行時間環(huán)境所需進行的改進。

    對任何管理計劃來說，主要目標都是通過定義將管理建立在其核心內(nèi)的SOA策略來最大限度地降低風險。不受管理的SOA可能會導致如下后果：

    ◆　由于發(fā)布的服務不完全符合服務級要求而導致過程的中斷

    ◆　由于服務問題和故障而使幫助臺和現(xiàn)場服務呼叫猛增，導致支持費用的增加

    ◆　缺乏互操作性，從而形成業(yè)務服務的孤島并時刻面臨傳統(tǒng)的、緊密耦合的體系結構所帶來的挑戰(zhàn)

    ◆　由于無法使主要策略與服務相關聯(lián)而導致無法滿足合歸性要求

    ◆　由于允許隨意訪問數(shù)據(jù)和服務而形成安全漏洞

    ◆　隨著服務產(chǎn)品的增加，未受管理的SOA中存在的這些問題所形成的風險會成指數(shù)倍地增加。不過，通過對服務組合的正確執(zhí)行和管理，其中許多風險能夠得以減少。

    服務發(fā)現(xiàn)

    邏輯上，構建服務組合的第一步是確定需要哪些服務。用于鑒別和發(fā)現(xiàn)候選服務的可行技術有三種，即自頂向下分析、自下向上分析以及業(yè)務流程跟蹤。注意，應當考慮使這些技術互為補充，不要唯一排外，每一種技術都應當在您的服務發(fā)現(xiàn)過程中發(fā)揮作用。

    第一步，您應當啟動自頂向下的分析，重點將機構的業(yè)務分解為若干功能”域“。在這里，域是指密切相關的功能和數(shù)據(jù)（如客戶、產(chǎn)品和合同）的邏輯分組。

    自頂向下的分析一般會形成一個符合業(yè)務需要的、實際的候選服務集。不過，單憑該過程并不能發(fā)現(xiàn)機構內(nèi)的所有候選服務。接下來要做的是對IT基礎架構、應用程序的功能性、業(yè)務應用程序以前曾使用過的數(shù)據(jù)以及現(xiàn)有的服務進行徹底的檢查。這種自下而上的方法通常會產(chǎn)生大量的高級和低級候選服務。

    作為補充手段，您應當對每個業(yè)務事件的生命周期進行跟蹤，以便發(fā)現(xiàn)哪些服務是通過其生命周期處理該事件所需要的。該過程稱為業(yè)務流程跟蹤，它不但可以發(fā)現(xiàn)處理該事件所需的服務，還可以發(fā)現(xiàn)僅通過自頂向下或自下而上的方法操作時所遺漏的候選服務。

    除了識別交付項目所需的服務之外，該業(yè)務流程驅(qū)動的方法還能夠提供完整性檢查，并就特定服務的重用潛力給出首要指示。

    服務發(fā)現(xiàn)的最終結果將是一個概念上的服務組合，該組合包含了項目最需要的候選服務。

    服務分類

    發(fā)現(xiàn)一組候選服務之后，對它們進行分類是對其進行設計、開發(fā)和后續(xù)執(zhí)行的至關重要的一環(huán)。

    分類可以按照功能、用途、結構和調(diào)用等標準進行。例如，將服務分為基礎架構服務（DNS查找、電子郵件）或工具服務（轉(zhuǎn)換）是基于功能進行的分類。

    這種分類方法有助于識別屬于同一功能域的服務、允許定義標準和最佳方法并對不同服務類的要求進行管理和監(jiān)控。對服務進行分類的過程還將會發(fā)現(xiàn)業(yè)務服務的規(guī)則，可以將這些規(guī)則轉(zhuǎn)換成一組應用于不同類型服務的、標準的、可重用的策略。

    雖然服務進行分類還沒有業(yè)界統(tǒng)一的標準，但通用描述、發(fā)現(xiàn)和集成（UDDI）注冊表正在成為事實上的標準。UDDI不但允許將元數(shù)據(jù)設置在服務上，還允許將其設置在諸如策略和XML模式等相關產(chǎn)物之上。

    例如，您可以在UDDI注冊表中創(chuàng)建下列分類模型以簡化服務的發(fā)現(xiàn)、管理和控制：

    ◆　服務所有者和聯(lián)系人信息

    ◆　服務或產(chǎn)物的功能描述

    ◆　版本信息/狀態(tài)，例如”版本“或”狀態(tài)：測試|生產(chǎn)|維護“

    ◆　服務類型（”訂單輸入“）或業(yè)務范圍（”會計“）

    ◆　使用模式/建議，例如”事物處理|子事物處理“、”同步|異步“

    ◆　預期的錯誤信息，用于現(xiàn)有服務的重用

    ◆　服務相關性，可能包括相關的策略、XSL轉(zhuǎn)換和XML模式

    ◆　可用的服務端點，以及Web服務中抽象的和具體的WSDL位置給UDDI注冊表中的服務和產(chǎn)物分類，不但可以使您能夠更好地為潛在的候選項分類，而且還能發(fā)現(xiàn)可以重用的現(xiàn)有服務，從而避免了功能的不必要重復。

確定服務粒度

    爭取合適的粒度級別將實現(xiàn)使用、重用和可管理性方面的最佳化。頂級的、業(yè)務驅(qū)動的分析通常會發(fā)現(xiàn)與現(xiàn)有需求相對應的高級（粗粒度）服務。例如，一個粗粒度服務可能表示”流程采購訂單“，它清晰地映射到一個業(yè)務流程。

    由于自下而上的分析專注于IT基礎架構和現(xiàn)有的API，因此該方法通常會產(chǎn)生大量的粗粒度服務和低級（細粒度）服務。激活低級任務（例如”插入訂單行項“）的功能就是一個示例。

    理想狀況下，您的SOA組合應當首先包括粗粒度服務界面，該界面直接與業(yè)務語義相對應。高級服務在動態(tài)的業(yè)務環(huán)境中靈活得多，因為它們沒有緊密地耦合到下層基礎架構之中。粗界面還允許您利用來自異類環(huán)境的其他服務來構建應用程序和流程，而不必考慮細節(jié)和差別。

    相反，低級服務是和下層基礎架構或API緊密耦合的，不能輕易加以修改以適應不斷變化的業(yè)務需求。實際上，將一個服務包裝在一個現(xiàn)有業(yè)務對象周圍（例如企業(yè)JavaBean（EJB））將不可避免地產(chǎn)生細粒度界面，把每個可供呼叫的方法顯示在bean上。

    用于處理機構內(nèi)部非常特殊的案例的服務可以通過細粒度界面執(zhí)行，這將為使用這些服務的客戶端應用提供更多的靈活性。不過請記住，在靈活性增強的同時還須面對復雜性增加所帶來的成本問題。

    一般來說，您應當避免將低級界面公開出來作為服務組合的一部分以試圖滿足業(yè)務需求?？煽紤]改為將一組細粒度服務結合起來組合成粗粒度服務。

    最后，需要記住的一點是，一個服務是否適當并不在于其是粗粒度還是細粒度，而要看其是否能使業(yè)務價值最大化。

    服務獲取

    定義完服務組合之后，下一步是確定如何獲取實際的服務：內(nèi)部構建、獲取服務或預訂外部供應商提供的服務。

    按照一般規(guī)則，那些關鍵性業(yè)務服務（即有益于業(yè)務流程、能為機構爭取競爭優(yōu)勢地位的服務）最好是由內(nèi)部提供。

    您很可能在服務的發(fā)現(xiàn)階段就已經(jīng)在內(nèi)部把可以映射到候選項的服務識別出來了。例如，倘若貴機構擁有ERP或CRM系統(tǒng)，則主要界面（客戶、訂單、帳戶）都 是可以加入到您的組合中去的服務。已經(jīng)在企業(yè)內(nèi)部使用的自定義應用程序可能也值得加以分析，以便識別可用的界面。

    提供更多商品驅(qū)動的功能的服務（例如提供股票報價）可能是外部預訂的候選項，很可能來自于貴機構已經(jīng)與之建立關系的業(yè)務伙伴。一旦您開始搜尋符合您需要的服務，服務分類的需要便立即顯現(xiàn)出來了。

    顯然，在識別候選服務時，有許多支持產(chǎn)物也需要創(chuàng)建和管理，例如，用于控制服務的策略；服務所使用的消息類型；以及將輸入和輸出消息轉(zhuǎn)換成適當格式所使用的XSL轉(zhuǎn)換。

    創(chuàng)建一個這些產(chǎn)物及其相應服務之間的關系的目錄將大大有助于構建您的組合。UDDI注冊表對本任務來說是一個價值極高的工具，它使您能夠構建一個服務和相關產(chǎn)物的完整的在線目錄。

    SOA管理需要考慮的事項

    最好您的SOA基礎架構能提供一個針對如下管理性能的平臺：監(jiān)控與診斷、外化的安全性、集中式審計與事件記錄以及服務級協(xié)議與策略管理。有許多特定于 SOA的組件可以用來進一步提高管理能力，例如企業(yè)服務總線（ESB）可用來實現(xiàn)可靠的消息傳遞；業(yè)務規(guī)則引擎可用來捕獲和自動化業(yè)務策略；業(yè)務活動監(jiān)控 解決方案可用來優(yōu)化服務。

    采用中間Web服務管理服務器尤其受益。在這種配置中，服務通過一個向用戶開放的代理URL被”虛擬化“，因此請求是通過媒介而不是直接發(fā)送到服務端點 的。利用本集中管理平臺可在服務上統(tǒng)一地設置策略，并為運行時策略的執(zhí)行提供了一個單獨的點。它還簡化了服務度量和使用情況統(tǒng)計信息（對維護服務組合的運 行狀況至關重要的數(shù)據(jù)）的捕獲。

    服務虛擬化還具有提供位置透明度的優(yōu)點：通過公開代理，可以在不影響服務用戶的情況下對下部基礎架構進行改動。該媒介必須維護其自身的虛擬服務到服務端點映射，或者利用UDDI注冊表發(fā)現(xiàn)一個有效的服務端點。

    結論：

    SOA作為溝通IT世界和業(yè)務世界的橋梁這一論斷在不斷地發(fā)展著。服務組合的構建是一項時間和資源的投資，它必將在面向服務的業(yè)務應用程序方面帶來巨大的回報。對這些面向服務的應用程序可以加以修改以滿足企業(yè)不斷變化的業(yè)務需求。