精通 SOA.docx
《精通 SOA.docx》由会员分享，可在线阅读，更多相关《精通 SOA.docx（24页珍藏版）》请在冰豆网上搜索。
精通SOA
第1部分：
構建服務組合
作者：
DanHynes和SalilPradhan
儘管面向服務的體系結構或SOA仍然是新生事物，但許多公司正逐步認識到需要採用SOA方法作為執行滿足業務需求的解決方案的方法。
採用這種方法的一個關鍵步驟是構建可重用服務的組合。
SOA表示新應用程式的設計、開發和集成方式的根本性轉變。
它還將企業應用程式的開發簡化為模組化業務服務，可以輕鬆地對其進行集成和重用。
SOA的一個主要優點是縮小了業務和IT之間的差距。
作為需求收集活動的一部分，將業務和技術需求與機構的與專案有關的主要業務目標相對應，將對確保項目與業務需求同步大有幫助。
著手構建服務組合的動力主要源於意識到需要保持業務需求與IT項目之間的一致性。
一般來說，該過程始於初步確定所需的服務，進而發展到發現它們所依賴的服務與資源（如定義特定業務規則的政策等）並對其進行分類。
理想狀況下，這樣做的成果是一套面向服務的業務應用程式，應用程式可以修正和重用，以滿足企業不斷變化的業務需求。
儘管在執行SOA時有許多問題需要考慮（如業務流程的編排、使用者介面的開發以及支援安全和性能的基礎架構等），但是獲得服務組合在邏輯上顯然是第一步。
在“精通SOA”系列的此部分中，您可以大致瞭解用於構建服務組合的框架。
SOA管理驅動組合構建
對SOA組合的創建起積極推動作用的通常是那些最為關心SOA管理相關問題的人。
理想狀況下，這個“管理委員會”應當是相關組的交叉項，包括業務流程所有者、系統架構師和開發人員。
SOA管理是一個寬泛的題目，值得專門撰文加以論述。
不過，在這裡我們不妨將其概括為“將SOA的靈活性與傳統IT體系結構的控制及可預言性相結合的框架”。
SOA管理在本文中一般涉及下列方面：
∙服務與相關資源的生命週期管理
∙相關性管理
∙策略的應用與管理
∙安全性和運行時策略執行
∙服務可用性
∙服務供應
執行能夠管理不斷增長的服務組合的管理平臺的重要意義遠遠不止於對技術基礎架構和執行時間環境所需進行的改進。
對任何管理計畫來說，主要目標都是通過定義將管理建立在其核心內的SOA策略來最大限度地降低風險。
不受管理的SOA可能會導致如下後果：
∙由於發佈的服務不完全符合服務級要求而導致過程的中斷
∙由於服務問題和故障而使説明台和現場服務呼叫猛增，導致支援費用的增加
∙缺乏互通性，從而形成業務服務的孤島並時刻面臨傳統的、緊密耦合的體系結構所帶來的挑戰
∙由於無法使主要策略與服務相關聯而導致無法滿足合歸性要求
∙由於允許隨意訪問資料和服務而形成安全性漏洞
隨著服務產品的增加，未受管理的SOA中存在的這些問題所形成的風險會成指數倍地增加。
不過，通過對服務組合的正確執行和管理，其中許多風險能夠得以減少。
服務發現
邏輯上，構建服務組合的第一步是確定需要哪些服務。
用於鑒別和發現候選服務的可行技術有三種，即自頂向下分析、自下向上分析以及業務流程跟蹤。
注意，應當考慮使這些技術互為補充，不要唯一排外，每一種技術都應當在您的服務發現過程中發揮作用。
第一步，您應當啟動自頂向下的分析，重點將機構的業務分解為若干功能“域”。
在這裡，域是指密切相關的功能和資料（如客戶、產品和合同）的邏輯分組。
自頂向下的分析一般會形成一個符合業務需要的、實際的候選服務集。
不過，單憑該過程並不能發現機構內的所有候選服務。
接下來要做的是對IT基礎架構、應用程式的功能性、業務應用程式以前曾使用過的資料以及現有的服務進行徹底的檢查。
這種自下而上的方法通常會產生大量的高級和低級候選服務。
作為補充手段，您應當對每個業務事件的生命週期進行跟蹤，以便發現哪些服務是通過其生命週期處理該事件所需要的。
該過程稱為業務流程跟蹤，它不但可以發現處理該事件所需的服務，還可以發現僅通過自頂向下或自下而上的方法操作時所遺漏的候選服務。
除了識別交付專案所需的服務之外，該業務流程驅動的方法還能夠提供完整性檢查，並就特定服務的重用潛力給出首要指示。
服務發現的最終結果將是一個概念上的服務組合，該組合包含了專案最需要的候選服務。
服務分類
發現一組候選服務之後，對它們進行分類是對其進行設計、開發和後續執行的至關重要的一環。
分類可以按照功能、用途、結構和調用等標準進行。
例如，將服務分為基礎架構服務（DNS查找、電子郵件）或工具服務（轉換）是基於功能進行的分類。
這種分類方法有助於識別屬於同一功能域的服務、允許定義標準和最佳方法並對不同服務類的要求進行管理和監控。
對服務進行分類的過程還將會發現業務服務的規則，可以將這些規則轉換成一組應用於不同類型服務的、標準的、可重用的策略。
雖然服務進行分類還沒有業界統一的標準，但通用描述、發現和集成（UDDI）註冊表正在成為事實上的標準。
UDDI不但允許將中繼資料設置在服務上，還允許將其設置在諸如策略和XML模式等相關產物之上。
例如，您可以在UDDI註冊表中創建下列分類模型以簡化服務的發現、管理和控制：
∙服務所有者和連絡人資訊
∙服務或產物的功能描述
∙版本資訊/狀態，例如“版本”或“狀態：
測試|生產|維護”
∙服務類型（“訂單輸入”）或業務範圍（“會計”）
∙使用模式/建議，例如“事物處理|子事物處理”、“同步|非同步”
∙預期的錯誤資訊，用於現有服務的重用
∙服務相關性，可能包括相關的策略、XSL轉換和XML模式
∙可用的服務端點，以及Web服務中抽象的和具體的WSDL位置
給UDDI註冊表中的服務和產物分類，不但可以使您能夠更好地為潛在的候選項分類，而且還能發現可以重用的現有服務，從而避免了功能的不必要重複。
確定服務細微性
爭取合適的細微性級別將實現使用、重用和可管理性方面的最佳化。
頂級的、業務驅動的分析通常會發現與現有需求相對應的高級（粗細微性）服務。
例如，一個粗細微性服務可能表示“流程採購訂單”，它清晰地映射到一個業務流程。
由於自下而上的分析專注於IT基礎架構和現有的API，因此該方法通常會產生大量的粗細微性服務和低級（細細微性）服務。
啟動低級任務（例如“插入訂單行項”）的功能就是一個示例。
理想狀況下，您的SOA組合應當首先包括粗細微性服務介面，該介面直接與業務語義相對應。
高級服務在動態的業務環境中靈活得多，因為它們沒有緊密地耦合到下層基礎架構之中。
粗介面還允許您利用來自異類環境的其他服務來構建應用程式和流程，而不必考慮細節和差別。
相反，低級服務是和下層基礎架構或API緊密耦合的，不能輕易加以修改以適應不斷變化的業務需求。
實際上，將一個服務包裝在一個現有業務對象周圍（例如企業JavaBean（EJB））將不可避免地產生細細微性介面，把每個可供呼叫的方法顯示在bean上。
用於處理機構內部非常特殊的案例的服務可以通過細細微性介面執行，這將為使用這些服務的用戶端應用提供更多的靈活性。
不過請記住，在靈活性增強的同時還須面對複雜性增加所帶來的成本問題。
一般來說，您應當避免將低級介面公開出來作為服務組合的一部分以試圖滿足業務需求。
可考慮改為將一組細細微性服務結合起來組合成粗細微性服務。
最後，需要記住的一點是，一個服務是否適當並不在於其是粗細微性還是細細微性，而要看其是否能使業務價值最大化。
服務獲取
定義完服務組合之後，下一步是確定如何獲取實際的服務：
內部構建、獲取服務或預訂外部供應商提供的服務。
按照一般規則，那些關鍵性業務服務（即有益於業務流程、能為機構爭取競爭優勢地位的服務）最好是由內部提供。
您很可能在服務的發現階段就已經在內部把可以映射到候選項的服務識別出來了。
例如，倘若貴機構擁有ERP或CRM系統，則主要介面（客戶、訂單、帳戶）都是可以加入到您的組合中去的服務。
已經在企業內部使用的自訂應用程式可能也值得加以分析，以便識別可用的介面。
提供更多商品驅動的功能的服務（例如提供股票報價）可能是外部預訂的候選項，很可能來自於貴機構已經與之建立關係的業務夥伴。
一旦您開始搜尋符合您需要的服務，服務分類的需要便立即顯現出來了。
顯然，在識別候選服務時，有許多支援產物也需要創建和管理，例如，用於控制服務的策略；服務所使用的消息類型；以及將輸入和輸出消息轉換成適當格式所使用的XSL轉換。
創建一個這些產物及其相應服務之間的關係的目錄將大大有助於構建您的組合。
UDDI註冊表對本任務來說是一個價值極高的工具，它使您能夠構建一個服務和相關產物的完整的線上目錄。
SOA管理需要考慮的事項
最好您的SOA基礎架構能提供一個針對如下管理性能的平臺：
監控與診斷、外化的安全性、集中式審計與事件記錄以及服務級協定與策略管理。
有許多特定於SOA的元件可以用來進一步提高管理能力，例如企業服務匯流排（ESB）可用來實現可靠的消息傳遞；業務規則引擎可用來捕獲和自動化業務策略；業務活動監控解決方案可用來優化服務。
採用中間Web服務管理伺服器尤其受益。
在這種配置中，服務通過一個向使用者開放的代理URL被“虛擬化”，因此請求是通過媒介而不是直接發送到服務端點的。
利用本集中管理平臺可在服務上統一地設置策略，並為運行時策略的執行提供了一個單獨的點。
它還簡化了服務度量和使用情況統計資訊（對維護服務組合的運行狀況至關重要的資料）的捕獲。
服務虛擬化還具有提供位置透明度的優點：
通過公開代理，可以在不影響服務使用者的情況下對下部基礎架構進行改動。
該媒介必須維護其自身的虛擬服務到服務端點映射，或者利用UDDI註冊表發現一個有效的服務端點。
結論
SOA作為溝通IT世界和業務世界的橋樑這一論斷在不斷地發展著。
服務組合的構建是一項時間和資源的投資，它必將在面向服務的業務應用程式方面帶來巨大的回報。
對這些面向服務的應用程式可以加以修改以滿足企業不斷變化的業務需求。
第2部分：
通過企業服務匯流排連接
作者：
BrianWilkinson和DemedL'Her
隨著實施面向服務結構體系（SOA）這一觀念的日漸普及，企業發現自己的服務組合規模日益增大。
如果不遵循正確的體系結構模式，則很難有效地利用和重用這些服務。
企業服務匯流排（ESB）是一種相對較新的軟體類別，我們可以使用它來滿足上述目的。
它提供了一個急需的中間層，從而簡化了企業SOA實施的資料傳遞、服務訪問、服務重用以及服務管理。
ESB還支持智慧指導的通信，調解鬆散耦合業務元件和取消耦合的業務元件之間的關係。
在“精通SOA”的這一部分中，您將瞭解ESB為什麼是企業級SOA必不可少的一部分，以及如何實施ESB（包括常見問題）。
是否需要ESB？
正如本系列第1部分中所說明的那樣，SOA是應用程式在設計、開發和集成方面的一次根本性轉變。
SOA還有助於將企業應用程式作為可輕鬆集成和重用的模組化業務服務來進行開發。
然而，SOA還意味著各種挑戰，其中許多挑戰可直接通過ESB解決：
∙可靠的消息傳遞：
可靠的資料傳輸仍然是所有集成解決方案的基本需要。
雖然SOA的原則需要基於標準的、與平臺無關的消息協定，但該原則本身並未考慮可靠的資料傳遞。
各項標準（如WS-RM）正在逐漸支持該功能，但它們還不夠成熟或者未被廣泛採用。
∙服務虛擬化：
SOA代表了一種基本的體系結構模式，在該模式中，任何服務使用方均可從任何平臺訪問一個服務提供方。
這又意味著適當的協定和語法調解在適當的位置隔離了使用方和提供方。
∙動態發現和調用服務：
為了優化服務的重用，服務使用方需要一個仲介功能來瞭解服務請求的特性，從而方便與提供方進行連接。
在理想的SOA中，這種關係將在運行時作為仲介。
∙策略管理：
已知和未知服務使用方進行訪問都需要一個抽象的策略管理模型，該模型除了強制執行與服務提供方實施無關的更複雜的業務級別策略外，還能夠強制執行身份驗證、授權和加密。
∙管理和監視服務：
逐漸增加的服務數量導致環境越來越複雜。
必須監視該環境以瞭解其可用性、性能以及任何技術或業務級別錯誤。
∙系統異構性：
人們通過常用的應用程式以及用來連接它們的軟體可以發現，今天的新應用程式就是明天的舊應用程式。
這種新技術的普及是必然的，因此，設計系統時必須考慮讓其支援這種變化。
∙從技術實施細節中抽取業務邏輯：
SOA的目標之一是提供一種分層的方法來開發系統，該方法將技術變化從業務流程的變化中隔離出來，並且將業務流程的變化從技術變化中隔離出來。
實際上，必須從一開始就將這種“分別考慮”設計到體系結構中。
解決這些問題的標準方法—無論是企業範圍還是部門範圍—是任何SOA專案成功的基礎。
不能保證資料傳遞的SOA解決方案對大多數業務事務而言不夠強健，不能將業務流程從轉換和路由邏輯中抽取出來的SOA解決方案不會很敏捷。
而且，一個無法適應標準和產品發展變化的體系結構並不會降低TCO。
ESB模式（以及相關ESB產品的引入）是全面的SOA解決方案成功的基礎。
ESB部署的先決條件
深入討論細節之前，我們先進行一下回顧，就會發現並非所有SOA實施都需要重大的重用和鬆散耦合。
例如，較小的實施可能只會從ESB的增加中獲得邊際效益。
您需要滿足一些戰術條件才能建立對ESB的需要。
按照重要性順序，這些條件依次為：
1.服務使用方和提供方可能是鬆散耦合的，或者需要同步、非確定性的路由（其中使用方需要回應，但不會顯式知道服務提供方）。
2.執行業務事務之前，需要根據資料、使用方或提供方執行專門的功能（可能包括策略驗證、轉換等）。
3.必須有一種將端點應用程式連接到匯流排的方法（通過重新設計或者通過適配器），該方法必須能夠在面向服務的模型中運行這些應用程式（並非所有應用程式都能夠輕鬆地支援服務。
例如，傳統的老式程式（如客戶資料應用程式）使用連接到老式螢幕的、基於批次處理的程式設計模型來運行。
它們可能不會很容易地適應更基於事務的SOA模式。
）
對於所有複雜的計算體系結構，這三個條件僅僅是指導方針。
肯定存在這樣的情況：
無需同時滿足以上三個條件即可輕鬆地判別ESB。
著手進行SOA規劃時，不但要關心戰術方面，還要考慮長期策略目標。
自上而下與自下而上
SOA的兩種主要方法通常被稱作“自上而下”和“自下而上”。
在自上而下的方法中，採用SOA是由業務方驅動的，結果是一個專門設計以滿足業務需求的體系結構，著重於效率。
企業的IT部門通常推崇更實用的自下而上的方法，因為該方法更關心服務虛擬化，其主要目標是將成本降至最低並將更多靈活性結合到核心IT資產中。
可以想像，人們就哪種方法最適合或最有效展開了激烈的爭論。
在此，我們不會偏袒任何一方，而是探討ESB是否與這兩種方法相關。
答案是肯定的，自上而下和自下而上這兩種SOA方法通常都需要ESB。
這兩種方法所使用的工具沒有太大的區別；只不過引入這些工具的時間不同。
在自下而上方法中，可能在最初階段就開始使用ESB來執行低級資料和系統集成。
在自上而下方法中，最初關注的可能是構建服務，不過稍後這些服務之間需要進行互連時，就該使用ESB了。
常見用例
詳盡列出所有可能的用例將需要更長的篇幅。
然而，其中一些較為常見的用例需要進行強調：
服務虛擬化。
服務虛擬化是實施ESB的主要驅動因素，其他大多數用例都是它的變形。
設計時缺少清晰的層次（或“分別考慮”）會在業務邏輯和IT細節之間引入不必要的耦合。
起初，這些交叉相關性的影響可能不太明顯，但隨著集成範圍的擴大，它們開始以指數級速度削弱SOA實施最初的優點。
到端點的直接連結越多，最開始靈活、鬆散耦合的體系結構的僵化慣性就越大。
例如，如果將端點詳細資訊嵌入在一個資料庫中，那麼將該資料庫從一個網路重新定位到另一個網路將需要一個新版本的貸款審批流程。
處理幾個這樣的連結可能還是可管理的，但如果增加到50個服務和數十個端點，您就會看到體系結構很快會變成一張糾纏不清的相關性網。
該示例還暴露了這種設計在IT事件（資料庫移動）和業務邏輯（貸款審批流程）之間引入的不正常關係。
當複雜的核心商業資產（如貸款審批流程）根本沒有變化時，日常IT事件難以接受觸發這些資產的整個版本控制。
當然，這個小示例可能已經通過仔細的配置以及使用諸如JNDI或DNS這樣的技術縮減至最少，但它仍然可以方便地闡釋服務虛擬化所能解決的問題。
更現實的用例包括添加或刪除資料庫、更改CRM供應商，甚至吸收作為合併或並購的結果而產生的新系統。
如圖1所示，服務虛擬化是保存面向服務體系結構的增長能力的關鍵。
通過使用ESB，您可以從業務邏輯中徹底消除所有端點詳細資訊（如IP位址、埠以及其他低級特定於電腦的詳細資訊），而是公開一個穩定的介面。
最終結果是將業務需求與IT需求完全分離，從而允許IT和業務獨立修改各自的資產。
圖1服務虛擬化
集中控制策略。
您只需監視幾個應用程式伺服器日誌和設定檔的日子已經一去不返。
幸運的是，ESB可以幫助您解決如今的分散式系統中固有問題的管理和監視，即，提供有關多個應用程式和協定的端到端視圖，在企業範圍內配置並強制執行全域策略。
由於ESB邏輯上作為所有集成通信的仲介，因此對SOA基礎結構的監視變得簡單。
ESB管理主控台提供了流經服務的所有交換和消息的統一視圖。
（請參見圖2。
）這些新的監視功能可用於進行被動和主動監視。
例如，構建和強制執行端到端的服務級別協定（SLA）變成可能。
實際的監視平臺可能是一個外部應用程式（如OpenView或Tivoli，也可能是較新的業務活動監視（BAM）工具，現在越來越多地用於即時基礎結構監視），但ESB提供了所需的統一的、基於標準（SNMP、JMX、SQL）的基礎結構視圖。
圖2集中控制策略
使用ESB可以更輕鬆地全域運行像安全性或可靠性這樣的策略。
通過將標準化的鉤子（例如，WSDL介面）公開到集成體系結構的每個步驟中，ESB使得插入常用的安全、審計和消息處理工具成為可能。
例如，您可以攔截某些網站之間的所有通信來執行安全聲明標記語言（SAML）斷言，或者在企業級別（而非每個單獨的端點）支持64位DES加密。
此外，ESB還允許對專門應用程式的特定任務（如安全性原則）的責任和委託進行清晰的分層。
原有資料來源支援Web服務。
最初，沒有將ESB作為原有集成的解決方案。
但是現在，普遍認為必須在SOA中考慮原有資料來源，事實上，這些資料來源通常組成所涉及的大多數服務。
一般來說，訪問原有應用程式（如ERP或CRM系統）中的服務意味著使用供應商協定和API與目標系統直接交談。
（請參見圖3。
）這意味著構建服務使用方的團隊必須瞭解目標系統，並且能夠編譯其用戶端的供應商API（更不用說購買這些API的許可證了）。
因此，部署新服務使用方的成本非常高。
圖3訪問服務（專有方式）
然而，大多數ESB供應商都提供可以連接到受歡迎的原有系統的適配器。
然後，只需進行配置即可訪問應用程式的服務，添加新服務使用方的成本顯著降低，不用再使用供應商協定，所需的只是標準（SOAP、JMS或ESB公開的任何其他入口點）。
（請參見圖4。
）
圖4訪問服務（基於標準的方法）
進行服務虛擬化之後，即可以在許多情況下利用ESB了。
例如，多通道支持。
（請參見圖5。
）只需進行簡單的配置，即可向過去只能通過單獨的API訪問的服務中添加新通道。
因為使用同一個體系結構來支援多個通道，因此，確保所有訪問（不論是哪個通道）都歸屬一個全域策略中是可能的。
圖5多通道支持
例如，通過一個ESB，只能通過SOAP從客戶門戶訪問的Web服務可以允許其他面向客戶的系統（如可以與JMS或DCOM交談的IVR或傳真閘道）訪問相同的服務。
實施ESB的科學
雖然許多人會認為開發以業務為中心的SOA是一門“藝術”，但ESB的實施更大程度上是一門科學。
遵循正確的方法、標準和體系結構原則將確保成功實施ESB。
ESB的實施通常在兩個工作流中進行；軟體體系結構和支援基礎結構（即“技術體系結構工作流”）；以及支援業務所必須的服務邏輯（以及支援配置）的設計、開發和部署（即“應用程式體系結構工作流”）。
讓我們看一下這兩個工作流。
技術體系結構工作流。
該工作流包括選擇軟體、識別常見體系結構功能和基礎結構要求，以及部署可以開發服務（最終是組合應用程式）的整個基礎體系結構。
與傳統專案相同，有必要對技術體系結構工作流的組成部分進行需求分析。
針對該分析，有必要廣泛地調查期望SOA所具備的功能，並將它們分解到分散的服務中。
需求列表示例（不詳盡的）包括：
∙錯誤處理
∙審計
∙策略管理（不同的詳細資訊級別）
∙服務發現
∙有保證的傳遞
∙協定支援（特定於所涉及的應用程式和需求）
∙標準支援（通常是WS*標準，可能包括其他標準，這取決於規劃）
∙智能路由
只有明確了這些需求並選擇了產品之後，才能開始開發。
如果重用是所有SOA實施的主要著眼點，那麼開發人員培訓可以更廣泛。
應用程式體系結構工作流。
應用程式體系結構工作流包括識別、設計、創建業務級別服務以及將其部署到匯流排上。
通過上述的自上而下或者自下而上的方法可以處理這個特殊的工作流；然而，隨方法的不同，管理實際設計和開發過程的基本原則只會略有不同。
針對ESB進行設計時，第一個也是最重要的決策是識別出在哪些條件下服務應該位於匯流排上，在哪些條件下服務應該位於（例如）業務流程管理（BPM）工具中。
雖然這兩種功能表面上看來有很大差異，但是用BPM工具設計類似於匯流排的功能是很有可能的（在某些情況下，甚至更可取）。
通常，以下準則適合這種情況：
∙ESB上的服務應該是短生命、不連續的事務。
∙需要複雜規則來確定路由、訪問以及其他基於資料的決策的服務應該位於ESB上。
∙具有特定於端點的邏輯的服務應該位於ESB上。
例如，如果無法在應用程式自身內將規範的資料物件映射到特定于應用程式的物件上，就應該在匯流排中進行該操作（因為您在該應用程式中無法進行控制，也可能是因為您沒有留下任何COBOL程式師來進行修改）。
∙ESB服務應該不包含任何人力工作流活動。
除了這些高級準則以外，您還應該在全域範圍內實施一些較低級別的設計和開發準則。
其中某些準則不是ESB所特有的，但由於ESB會變得更相關。
我們已經在下面用斜體標明了新準則。
∙建立成功度量。
乍一看，這似乎是顯而易見的，但經常有很多ESB（以及SOA）項目失敗，都是因為它們無法量化地演示其所支援的過程或服務中的成功。
有用的度量可能包括服務的使用方數量以及服務的回應時間（平均時間和高峰時間）。
∙對於每個應用程式，必須識別適當的適配器以及必須應用的相應協議和封套技術。
這包括識別交互中所需的所有標準（例如，Web服務可靠的消息傳遞）。
確保在選擇適配器和協定時考慮事務模型（非同步或同步的）以及可靠性需求。
∙必須詳細定義所涉及的來源資料物件和目標資料物件，並將它們映射到對應的規範物件。
如果某個規範物件不存在，您必須識別、設計並開發一個。
規範物件的存在對於廣泛採用ESB範例很重要。
∙將度量設計到服務中。
利用BAM工具可以輕鬆地訪問即時度量。
即時度量的示例可
升级会员 