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 世界和業務世界的橋梁這一論斷在不斷地發展著。服務組合的構建是一項時間和資源的投資，它必將在面向服務的業務應用程序方面帶來巨大的回報。對這些面向服務的應用程序可以加以修改以滿足企業不斷變化的業務需求。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
