IBM：SOA治理簡介(1)

治理和管理需求

面向服務的體系結構 (SOA) 是一項引人注目的技術，用于開發與業務模型保持最佳一致性的軟件應用程序。不過，SOA 會提高業務和信息技術（Information Technology，IT）以及 IT 部門和各個團隊間所需的合作和協調級別。這個合作和協調是通過 SOA 治理提供的，涵蓋了用于指定和管理如何支持服務和 SOA 應用程序的各個任務和流程。

在本文中，我們將了解治理和管理的含義以及其之所以重要的原因。然后，我們將討論以下 SOA 治理的一些重要方面：

通過本文，您將能很好地理解為何 SOA 工作需要 SOA 治理的支持。您將建立起如何為您的組織構建其 SOA 治理方案的一些基本理念。

沒有治理時的情況

在討論什么是治理之前，讓我們了解一下公司 IT 部門中通常的情況；即沒有治理時的情況如何。

希望提供服務時

讓我們假定您開發了一個很不錯的小型服務來進行貨幣值轉換。您需要在正在處理的訂單處理程序的幾個不同位置使用此服務，因此將代碼編寫為具有可重用功能，以便從程序中的任何位置進行調用。由于在另一個程序中需要此服務，因此將代碼放到 Java .jar 文件中，以便將其添加到任何需要此服務的程序的類路徑中。但該服務存在一個問題，由于需要使用貨幣匯率（如 Yahoo 的貨幣轉換器網站發布的匯率）進行初始化，因此啟動需要很長時間。這些步驟在每次需要對貨幣量進行轉換時，都會花太多的時間進行初始化。因此，您在自己的小程序中承載轉換器，這個程序在啟動并初始化后將始終運行，可以隨時通過遠程 API 從任何程序對其進行調用。此 API 可以作為 SOAP-over-HTTP Web 服務實現，也可以是支持 RMI-over-IIOP 的遠程 Enterprise JavaBean (EJB) 接口。

您現在獲得的就是一個貨幣轉換器服務。不僅您的多個程序可以使用它，您的部門同時也很喜歡這個小東西，開始從他們自己的程序對其進行調用。不久后，您可能不知道，公司的其他部門中您從來沒有聽說過的程序也在使用這個服務了。轉換器運行頻率非常高，而導致其響應時間延長，因此您勸說經理購買更為強大的計算機來承載您的服務。經理并不喜歡將預算中的資金花在另一臺進行簡單工作的計算機上，不過您說服了他。

一個周末，計算機系統崩潰了，而這卻是您公司的某個從來沒有聽說過的人打電話到您家里告訴您的，他讓您到辦公室進行必要的工作，以便使轉換程序重新開始運行。后來，您的經理說其他部門的人抱怨您的轉換器匯率更新并不及時。他希望您對此進行處理，但不希望耽誤您的本職工作。您怎么開始對所有這些負責了呢？

有一天您說“去他的”。您不想再負責轉換器的工作，將其關閉了。大量的投訴電子郵件開始在公司內出現，人們嘗試找出誰負責轉換器程序以及為什么沒有再運行了。其中很多電子郵件抱怨說，由于沒有了轉換器服務，很多非常有用的程序不再能繼續工作了?？蛻舴浅Ｉ鷼?，您的公司因此而蒙受著利潤損失——如果運氣不好，每個人發現要對此負責的是您，您很可能會被辭退。怎么會是這樣呢？

希望使用服務時

現在讓我們看一下另一方面。假定您是該公司中的另一名員工，在處理產品目錄應用程序。不同國家的用戶希望能夠看到以其相應貨幣表示的產品價格。一位同事告訴您可以調用此服務將每個產品的價格轉換為使用用戶的貨幣表示。您試了一下，的確可以正常工作，因此使用該服務實現了您的應用程序。您的經理非常高興您能以創記錄的時間完成新功能，客戶非常喜歡這個功能，網站的銷售額大幅度提高。

然后，您的網站在某個周末停止工作了：無法以其他貨品顯示價格。您的經理打電話到家里，要求您趕快修復程序。您打電話到同事家，得知是他的朋友的朋友告知他這項服務的。同時，銷售副總裁的助手打電話告訴您客戶對此很不滿意。您告訴他是朋友的朋友編寫的這個服務。副總裁的助手打電話給這個人，讓他馬上到辦公室進行相關工作，以使此服務恢復運行。盡管您的應用程序本身沒有問題，而是調用的服務出現了問題，您同時也因為目錄應用程序停止工作而被指責。這怎么會是您的錯呢？

歡迎來到 SOA 治理的世界?；?，在本例中，缺乏有效治理的世界。服務提供者和服務使用者都開始負責很多最初的職責之外的事務。如何在不造成這樣的失控局面的前提下使用服務呢？

什么是 SOA 治理？

我們已經了解了治理無效時可能出現的情況。那么，如果治理更好，IT 是不是會工作得更好？首先，我們需要了解什么是治理，以及它如何影響 IT 和服務。

通常來說，治理意味著建立和執行工作組為了一起工作而一致同意的工作指南。具體來說，治理包括兩個方面：

• 建立責任、授權和通信鏈，以對人員進行權利分配，確定誰有權進行哪些決策
• 建立度量、策略和治理機制，以支持各個人員執行各自的角色任務和旅行相關職責

治理與管理有以下幾個方面的區別：

• 治理確定誰具有權利和責任進行決策
• 管理是進行決策和實施決策的過程

因此，治理說明應該完成哪些工作，而管理用于確保完成此工作。

治理更為具體的一個形式是 IT 治理，用于完成以下任務：

• 建立與 IT 關聯的決策權利
• 建立用于度量和治理 IT 決策及執行的機制和策略

即，IT 治理討論的是關于誰負責 IT 部分中的什么，以及部門如何知道相應的人員履行了這些職責。

SOA 向治理添加了以下幾個獨特的方面：

• 充當 IT 治理的擴展，重點關注服務的生命周期，以確保 SOA 的業務價值
• 確定誰應該監視、定義和授權對企業內現有服務的更改

治理在 SOA 中比在普通 IT 中更為重要。在 SOA 中，服務使用者和服務提供者運行于不同的進程中，由不同的部門開發和管理，為了成功地一起工作，需要進行大量的協調工作。為了 SOA 能成功，多個應用程序需要能共享相同的服務，這意味著它們需要進行協調，以便共享和重用這些服務。這些就是治理問題，比采用獨立應用程序時（甚至包括使用可重用代碼和組件時）要復雜得多。

隨著各個公司開始使用 SOA 來更好地保持 IT 與業務間的一致，可以使用 SOA 治理來非常理想地改進總體 IT 治理。如果公司要實現 SOA 的各種好處，采用 SOA 治理是非常關鍵的。對于 SOA 的成功，SOA 業務和技術治理不是可選的，而是必須使用的手段。

SOA 治理實踐

在實踐中，SOA 治理指導可重用資產的開發，確立如何設計和開發服務，以及這些服務如何隨時間增長進行更改。它將在服務提供者和服務使用者之間建立一個協議，告知使用者可以希望得到什么功能，告知提供者應該提供什么功能。

SOA 治理并不設計服務，而是指導將如何設計服務。這可幫助回答很多有關 SOA 的問題：提供了哪些服務？誰可以使用這些服務？它們的可靠性如何？將在多長時間內支持這些服務？是否可以確定這些服務不會更改？如果為了各種目的（如修復錯誤或添加新功能）而希望進行更改時該怎么辦？如果兩個使用者希望相同的服務以不同的方式工作時該怎么辦？是否因為您決定公開服務就意味著有責任永遠為其提供支持？如果您決定使用服務，是否能保證明天不會關閉這個服務？

SOA 治理以現有 IT 治理技術和實踐為基礎。使用 Java 2 Platform, Enterprise Edition (J2EE) 等面向對象的技術時，IT 治理的一個關鍵方面就是代碼重用。代碼重用也體現了 IT 治理的難點所在。每個人都認為可重用資產很好，但實際工作時卻非常困難：誰為開發可重用資產付款？開發團隊是否會實際盡力進行重用？是否每個人都認同可重用資產的單一行為集，或者每個人都采用自己的自定義版本，實際上完全不能進行重用？SOA 和服務使這些治理問題變得更加重要了，它們的結果也因此變得更為重要。

治理更多的是政策問題，而不是技術或業務問題。技術的重點是匹配接口和調用協議。業務的重點是為客戶服務的功能。技術和業務都關注的是需求。雖然治理也涉及這些方面，但它更多的是要確保所有部分一起工作，獨立的工作彼此并不會沖突。治理并不會確定決策的結果是什么，而是考慮必須進行哪些決策以及誰進行這些決策。

使用者和提供者雙方彼此就如何一起工作達成一致。這些認識上的一致大部分都能通過服務水平協議（Service-Level Agreement，SLA）進行捕獲，形成服務提供者愿意提供且服務使用者愿意接受的可度量目標。這個協議就像各方之間的契約，而且可以成為事實上的具有法律效力的合同。SLA 至少要清楚說明提供者必須進行怎樣的工作，以及使用者可以期望得到什么服務。

SOA 治理是由精英團隊（Center of Excellence，COE）（一組知識豐富的 SOA 技術人員）制訂的，他們負責建立策略并監督其執行，從而幫助確保企業的 SOA 成功。COE 將建立各種策略，以用于標識和開發服務、建立 SLA、管理注冊中心以及進行其他提供有效治理的工作。COE 成員隨后將這些策略付諸實施，指導和幫助團隊開發服務和組合應用程序。

治理 COE 制訂了策略后，就可以使用相關技術來管理這些策略。技術并不會定義 SLA，但可以用于執行和度量遵從情況。例如，技術可以限制哪些使用者可以調用某個服務以及何時可以調用服務?？梢韵蚴褂谜甙l出警告，告知服務已經棄用?？梢詫Ψ盏目捎眯院晚憫獣r間進行度量。

技術執行治理策略的一個不錯的途徑是通過企業服務總線（Enterprise Service Bus，ESB）和服務注冊中心的組合?？梢圆捎锰囟ǖ姆绞焦_服務，以便只有特定的 ESB 才能調用該服務。然后 ESB/注冊中心就可以治理使用者的訪問，監視和測定使用情況，確定 SLA 遵從情況等。通過這種方式，服務可以將重點放在提供業務功能上，而 ESB/注冊中心則主要負責治理方面的工作。

治理可能成為 SOA 中任何錯誤的替罪羊。和性能一樣，治理可能成為極大的顧慮，成為所有問題的托詞和每個有問題的解決方案的正當借口。只需要在任何 SOA 討論中扔出一句火藥味十足的話（好比扔出了一顆“手榴彈”），然后就可以看著原本有用的討論瞬時間陷入一片靜寂。SOA 的一個挑戰就是明智地使用治理來使 SOA 更好地工作，而不會讓治理方面的顧慮淹沒了所有其他事項。

SOA 治理的各個方面

SOA 治理不是一組實踐操作，而是很多彼此協調工作的系列操作實踐。SOA 治理的每個方面都值得在以后的文章中進一步地深入討論。此處的討論僅是簡單的概述。

服務定義

SOA 治理最基礎的方面就是監視服務的創建過程。必須對服務進行標識，必須描述其功能，確定其行為范圍并設計其接口。治理 COE 可以不執行這些任務，但要確保有人執行這些任務。COE 對創建服務和需要使用這些服務的團隊進行協調，以確保滿足相關的需求，并避免重復工作。

通常，什么應該是服務這個問題的答案并不明顯。功能應該與一組可重復的業務任務匹配。服務的邊界應當封裝一項可重用、不受上下文約束的功能。接口應該公開服務進行的工作，但要隱藏服務如何實現的，并允許更改實現或采用替代實現。從頭設計服務時，可以將其設計成對業務進行建模；包裝現有服務時，創建并實現好的業務接口可能會更難。

定義服務邊界的潛在困難的一個有意思的例子就是在何處設置事務邊界。服務通常在自己的事務中運行，確保其工作要么完全完成，要么完全回滾。不過，服務協調程序（也稱為協調器或編排器）可能希望在單個事務中調用多個服務（最好是通過指定的交互，如 WS-AtomicTransactions）。此任務要求服務接口公開其事務支持，以便能參與調用方的事務。但這樣的公開要求對調用方信任，對提供者具有很大的風險。例如，提供者可能會鎖定執行服務的資源，但如果調用方永遠不完成事務（沒有提交或回滾），提供者將很難干凈地釋放資源鎖定。正如這種情況所表明的，服務的范圍以及誰具有治理權有時候并不太容易確定。