在分布式應用程序中正確的管理、發布引用及配置數據總是具有挑戰性。面向服務的體系結構 (SOA)、實時及事件驅動處理 (7x24) 的使用使得這項任務成為主要的問題。在接下來的部分當中，Richard Whyte 將向您解釋如何從您自己的策略管理解決方案的實現的關鍵設計點中受益。他也從提煉為最終建議的簡單設計開始，為策略管理服務的一個版本勾勒了框架，并使其成為可能的解決方案。
引言
各公司也正在尋找他們使用及控制技術的方式的改進。業務流程管理（BPM）及面向服務的體系結構 (SOA) 是使得業務靈活、增強業務控制及風險管理的關鍵，并在業務完成主要功能的方式上創建新的機會。
端對端或直接處理 (straight-through-processing，STP) 體系結構在其邊界接收工作條目并在不影響控制的情況下控制其完成流程。這樣的體系結構可以跨越單一部門、多業務線 (LOB) 或商業組的成員。新的挑戰迫使業務及技術優勢被部分的偏移。
關鍵的挑戰是在大型的、高可用性的 SOA 實現中有效的引用及配置數據發布。可以通過調查工作量的性質來突出這一點。例如，SOA 需要供給多業務流程。SOA 為不同階段（秒、日、周或年）控制每個流程實例（工作條目），并需要各種資源來完成。條目流由必需使用通用規則及參考數據處理的組工作條目來創建。
本文討論配置、引用及業務規則發布的解決方案。策略管理是確保策略的服務能被正確、及時及準確通知的動作。它是一種系統開銷，所以必需要操作簡單、高效和經濟的。
術語策略數據 (policy data)指做業務或技術決定的所有數據類型。在某些情況下錯誤的、過時的或不完全的數據是可以接受的但在其他情況下則不可以接受。策略設置的可見性是嚴格的。例如，沒有時區的時間戳在單一地區的情況下可以接受，但在多地區環境中卻不能。
為達到本文的目的，策略是由單一單元管理及檢索的一套指定的數據條目（設置）。設置名在策略中是唯一的但可能存在于多個策略中。
策略是確定的路線或從選擇物中選擇動作的方法，并在給定條件的指引下指導及確定決策。例如，業務策略規定報酬低于 5,000 USD 不作為舞弊檢查的對象。這里的規則及值（5,000 USD）就是策略數據。例如，如果 USD(<Item.Value>) 大于 <Policy.Value>，那么 Do-Fraud-Check。
策略管理顯示
策略管理解決方案（PMS）顯示為 SOA 提供中央管理策略數據服務。該解決方案負責 SOA 中所有元數據。它提供：
- 單點控制
- 相容接口
- 檢測及保護數據惡化
- 準確的、完全的及同步的（及時的）為需要它的任何服務發布策略數據
解決方案的主要原則是：
- 服務保留響應性和對其策略的控制，但是將管理和保留的職責委托給了專用的 PMS。這將可以確保不用復雜的配置改變而向 SOA 中添加或從其中移除服務。由于服務總可以從策略服務中恢復策略，所以他們可以存在于非錯誤容忍的硬件設備上。元件失效并不導致需要恢復配置信息，以及個性化服務組建可以安全的聚焦于業務及當前工作上而不是策略上。
- 工作條目“請求”使用策略的版本而不是服務擁有版本。這確保服務可以確信他們使用正確的策略，而不需要進行遠程版本檢查。 可以在任何給定時間激活策略的新老版本，并可以保證任何服務分別為工作條目選擇正確的策略。這也支持服務使用不同的策略需求同時處理不同工作流中的工作條目（隔離工作流）。
- 不變策略版本及檢查策略數據完整性的能力支持分布及響應環境的優化。它也允許服務的所有實例應用策略版本，而不用考慮其周圍環境。
- 通過實現責任的明確劃分及清除的、明確的所有權保存，解決方案陳列出一致的策略語法及語義、查看跨多服務策略的能力、簡化的實現及保管成本。
- PMS 負責管理及分發策略信息，但并不擁有所有策略數據，它只保留個別（客戶端）服務的屬性信息。集中管理允許對策略進行測試、控制改變及將其作為單獨單元移植到產品中。IT 簡化了啟動新服務實例的配置步驟并保證那個服務使用一致的名字及類型管理模式。結果是使用專一的、簡單的管理接口。
- PMS 應當將它本身及客戶端應用程序間的代碼或操作連接最小化且不能損害獨立性或封裝性（如，Java? 對象版本）。它也不能創建操作依賴性，如爭用或單獨點故障。
- PMS 提供了可調用的管理接口。這創建了分層的解決方案，它可以權衡 SOA 用戶交互解決方案（瀏覽器、門戶及 Eclipse）。這個方法讓 SOA 為所有服務提供一致的用戶接口。要簡化最初的開發及部署，可能要提供簡單的控制臺，在公布的管理應用程序編程接口（API）中使用服務。此方法不向服務中添加任何限制。
開發解決方案
解決方案開發開始于數據結構及創建操作、維護及分發策略數據的軟件。這個解決方案從一個簡單的解決方案發展而來，調整以適合新的問題并根據需要添加功能。結果是該解決方案在不損害 SOA 或導致額外操作成本的情況下滿足需求。
圖 1. 策略管理開始于軟件的編碼
以結構及靈活性為代價換來了最佳性能。由于環境變得很復雜，識別及改變策略的工作也變得費力甚至是冒險。在沒有改變軟件的情況下不能改變策略，并且沒有源代碼時也策略也不可見。嵌入式策略不能被共享，不支持引用數據，不適合封裝解決方案。
圖 2. 配置庫中的策略設置
將策略設置放置在軟件本地的配置庫中使得他們更加可見并更容易更改及共享。本地存儲很可能會提供合理的性能且不創建復雜的訪問性及所有權問題。這解決了嵌入式策略的許多限制。本地庫方法當應用程序想通過網絡并彼此依賴來提供及時并準確的服務時會失敗。在無權使用運行時環境或不了解特定主機上是如何存儲及管理策略時，本地配置是不可見的。一般的問題是使用深奧的語法及語義表示配置，需要專門的控制臺或簡單的文本編輯器進行管理，或者是本地配置文件或數據庫不是很容易的能支持企業級范圍的引用數據。
圖 3. 多實例服務及互關聯分布系統
多實例服務及互關聯分布式系統創建過多的所有本地配置的同步。共享庫通常是發布的模式數據庫。引用及配置數據使用復制技術存儲于數據庫中。應用程序使用 SQL 查詢訪問數據。
這個解決方案在策略庫與使用它的應用程序之間有很強的依賴性。在沒有改變的情況下，模式不能改變且數據庫不能移植到所有的應用程序中。用戶名及密碼經常存儲于各自的應用程序中，但不能在常規基礎上進行改變并且也不安全。
數據所有權、性能問題及單點故障還有更多普遍的問題都存在于這個解決方案中。性能及可用性方面可以通過創建多的、同步的庫映像來解決。然后需要通過負載均衡避免爭用。
復制從一個庫將數據操作（插入、更新、刪除）復制到另一個倉庫。使用從數據庫日志文件或數據庫觸發器觸發的存儲并發送 (store-and-forward) 技術將操作發送給復制。標準的復制模型是可升級的且提供使用異步傳輸的“某時”倉庫的同步。它不保證“時間點 (point-in-time)”同步。
這個 PMS 版本需要所有服務在任意時刻都使用正確的策略，作為解決方案放棄復制其自身。
同步復制使用分布式事務處理管理復制數據操作，（幾乎）同時的作為工作單點，將操作應用到所有復件。一個的失敗導致所有的失敗。不幸的是，這項技術操作費事且不可劃分。錯誤修正、添加、移除及初始化同步復制都是費事的，且相關操作創建實例間的緊耦合。
輕量級目錄訪問協議 (LDAP)是正式的目錄訪問協議。實現一般地提供內建的分布式系統，它可以通過跨企業及網絡來實現。LDAP 提供基于標準的層次數據結構，它允許非安全認證應用程序訪問，或通過提供存儲于他們自己目標記錄中的認證訪問。這個基本的模型對 PMS 發布顯示很有用處。它沒有依賴于簡單數據庫方法的用戶名及密碼的依賴，而是提供可擴充的文檔模式。LDAP 使用復制將數據入棧到它的復件中，它不支持服務選擇特定的記錄的修正。
事件驅動發布是一種解決方案，它依賴于更新記錄的組件登記。這個解決方案不適合那些需要舊策略并將責任推給應用程序的工作條目。入棧技術本身可能不提供顯示需要的準確度。
數據發布檢查點
沒有從最終容器返回有意義反饋的數據入棧的復制不能保證每個服務應用正確給定工作條目的策略版本。服務依賴他們本地庫的更新速度，分布式庫及高性能 SOA 增強同步延遲及錯誤策略應用程序的水平。仍留有問題：解決方案如何保證每個服務每次都使用正確的策略修正？解決方案如何保證它包括所有新的及以前的策略版本，并且它能在發布及響應環境中進行操作么？
PMS 需要工作條目請求特定的版本以允許服務檢查其是否有正確的版本。這個方法可以為舊的及非常新的策略工作。
現在服務可以顯式請求正確的版本。可以使用復制將其重新移入分布緩存中，策略修正請求保證服務使用正確的版本。
第一個結構原則是：將每個工作條目標記上正確的策略修正。
標記工作條目
圖 4. 標記工作條目
原則沒有說明如何完成正確策略修正每個標記工作條目。操作是使用需要運算法則來確定正確版本的一般標簽來標記，或使用顯式的策略修正信息來標記。
常規標簽是從信息的固有數據或從為策略管理的單獨目的而添加的專用的標簽中創建的。
固有標簽使用現有數據（例如，日期及時間）并向屬性添加含意。添加的含意對維護工程師及操作人員不會立即變得明確。使用這個方法，就會限制額外內容的靈活性，操作（如，改變已應用的策略版本）也會受到損害。
專用（非固有）標簽經常從生成器容易獲得的信息中生成。這簡化標簽的生成，但需要查找算法來找出正確的修正或版本。查找可能確定最新的修正，在這之前一天的，兩天之間的或后一天的。這些算法實現起來復雜，當需要的實際修正不在庫中或不符合應用的算法時，查找就會失敗。算法會脫節于從任何特定修正的顯式請求，他們銷毀需要的及不適合的反饋。
顯式標簽描述對單一顯式策略修正的直接連接。添加他們只是為策略管理的目的。
SOA 包含許多服務，每個服務中都定義有一個或多個策略且以不同的級別修正。如果解決方案列出工作條目需要的所有策略修正對，那么該解決方案就會變得臃腫且易于出錯和變得混淆。這個方法強制這個標記類型假設每個工作條目需要每個服務及策略。
通過創建及存儲指定的共同工作的策略修正列表，您可以在 SOA 中創建所有策略的一套相應的特定的修正。然后就有可能用這套策略修正的名字作為顯式標簽而不是作為列表本身。第一個實現原則是：使用策略集合在結構的入口處分別標記每個工作條目。。
策略集合
圖 5. 映射到策略的策略集合
將每個策略的一個版本放置在指定的集合中創建策略集合。標記為策略集合的工作條目與那些策略修正有直接的關系。沒有必要將每個修正都列入工作條目中，需要的標簽的數目減少到一個。標記為相同策略集合的工作條目（工作流）組以一致的及可預測的方式使用相同的策略及流程。
服務可以使用策略集合及策略名顯式的請求他們需要處理的這個工作條目的策略版本。
策略的一個版本可以存在于許多策略集合中，但一旦它被部署在一個集合中就不能再對其進行修改。對策略的“更新”導致生成及更新了一個新的策略版本。.
通過使用檢查或數字簽名，易于區分 key-not-found（緩存不完全）與 invalid-key（不進行遠程請求，他們就不會知道彼此）之間的不同，您可以檢查改變及策略的完整性。例如，使用排序代碼和銀行賬戶號碼訪問客戶的簡介。如果沒有找到，使用排序代碼取得該客戶的默認信息。
成功的策略及策略集合部署確保取得的使用策略名及策略集合的策略總是正確的，沒有過多的開銷或當緩存時沒有緩存合法性問題。
策略所有權及域
策略是特定服務的獨有職責及屬性，但可能被那個服務的所有實例所使用。這個限制保護執行的獨立性及簡化變更管理。要保護這個清楚的劃分，PMS 需要提供防止其他小組對策略更新的控制。屬于重實現或不贊成的服務的策略可以被廢棄以保護解決方案的長期合法性。
一個服務需要用其他服務注冊的情況確實存在（例如，使用報告執行服務注冊報告）。有利的方面是，所有權限制澄清了事件的狀態。首先，報告清楚的保留第一個服務的屬性及職責并被放置在服務的策略當中。PMS 需要報告執行服務訪問那個策略設置的機制。
域是類或類型并表示數據的規則、語法及語義（例如，它必需是整型、浮點型、圖片類型等等）。域是分配給規則及格式的名字。
將域添加進策略設置使得策略管理員依據值并識別那個值屬于已知的特定的域來增強那些域規則及格式。策略管理員可以使域允許服務定義新的域。名字及合法性規則是策略設置，域是，例如，PMS$DOMAIN。
取得策略設置的通常的方式是從特定的策略集合中請求策略，并從特定的策略修正中產生所有的設置。PMS 可以通過允許客戶端服務通過域名訪問策略集合中的多個策略取得策略設置來實現一個服務通知另一個策略的能力。例如，Name = My Report，Value = "Report file + instructions."，Domain= REPORT
由域來獲取可以保留正確的所有權規則并可以防止不同服務策略間的交叉。它為服務提供簡單的機制使用其他服務在保留所有權情況下注冊構件。
實現意見
對已部署策略的更改會導致在新的策略集合中創建新的策略修正。新策略集合需要被顯式的部署以供產品服務所使用。顯式部署允許更改進行測試、控制及授權。部署檢查所有策略及策略集合，標記他們為不可變。
服務連接 SOA 在接收工作前取得他們的技術策略，但從工作條目中取得策略集合。新服務不需要顯式策略同步。
工作條目使用正確的策略集合單獨標記。服務可以支持多并發策略且可以為每個工作條目準確的應用正確的策略。
當策略集合進入體系結構中，它就被分配給每個工作條目。策略集合是最新的集合、名字集或策略集合分配給特定的工作流。如果策略管理員支持策略集合請求，例如，允許 PolicySet = "" 或 PolicySet = "WS$<Name>" 或 PolicySet = "PolicySetName"，處理相同工作流的不同網關不需要相互同步。
空白策略集合的工作條目被分配給指定的策略集合，通過第一個服務請求該信息。使用最新策略集合的名字，工作條目也被從那一點向前被標記。
以一個工作流標識符標記的工作條目，使用與命名策略集合相同的方式用工作流 ID 分解。如果工作流 ID 別名已經分配給了策略集合，請求可能會得到本地緩存的回絕。否則，請求救會被送到策略管理服務。服務為策略集合分配別名，以集合及影射作為回應。
如果不可變約束不合適，必需允許在任意時刻改變策略。如果由數據過期來管理刷新，就像 Web 頁面情況一樣，那么可以使用策略或策略集合內部的關鍵字，來通知任意的緩存，告訴他們數據可以保持多長時間的方式來實現。例如，PolicyCacheDirty 被設置為 "REALTIME"，顯示如果策略過期每次都使用 DateTime / DeltaTime 檢查策略的改變。
當使用過期機制時，可以告知 PMS 使用另外一個關鍵字。例如 PolicyVersionChange 設置為“On Change”顯示改變或新值的增加都會導致策略新版本的產生。
結束語
策略被組織為策略集合而發布。策略集合由許多屬于單獨服務的策略組成。每個策略都被命名并歸屬到版本控制中。不能改變已部署的策略，而且都使用了數字簽以允許任何服務檢查它的可靠性和完整性。工作條目通過指定策略集合指示活動策略。三個重要的方面包括：
- 可以使用不同的策略處理不同線程處理的多條目。
- 策略數據可以被復制或緩存，而且沒有使用過期數據的風險。
- 工作條目為其自身請求正確的策略。
這確保工作條目取得他們需要的策略，并去除對同步服務策略緩存復雜模式的需要。
策略通過其單獨的、專用服務、強制唯一的、一致的語法及域控制語義來構造、維護及部署。應用到工作條目的策略的預測為企業提供了強大的診斷及管理工具。
解決方案為業務提供了以受控及可追蹤方式改變策略的能力，及在工業及聯邦法律的約束下實現其公司的管理需要（Sarbanes-Oxley Act 2002）。