基于策略的面向服務計算

1、策略2策略系統(tǒng)34面向服務的策略架構模型驅動的策略計算1策略是關于計算機系統(tǒng)的約束、規(guī)則或者聲明。策略，指計策；謀略。一般是指：1. 可以實現(xiàn)目標的方案集合；2. 根據(jù)形勢發(fā)展而制定的行動方針和斗爭方法；3. 有斗爭藝術，能注意方式方法。（1）最低工資的策略：工人時薪不得低于每小時5元（2）交通規(guī)則的策略：如果紅燈亮，則停下來如果綠燈亮并且前方無人，則可以通過。規(guī)則的特點專門性 規(guī)則所適用的范圍一般比較小，是專門就某一項工作或活動而制定的，超出這一范圍便沒有什么意義了。1具體性 規(guī)則的內容比較具體、細致、周密，往往對具體工作的方方面面、可行性 規(guī)則講究可行性，條款均可直接付諸實施，不需要再制定

2、細則來作解釋、補充。23總結：策略是解決某一問題提出的方案，而規(guī)則更具有制約性。 策略主要用于系統(tǒng)的實時驗證方面。對系統(tǒng)進行驗證的方法有很多，如測試和靜態(tài)分析都對系統(tǒng)進行驗證。然而，這幾種驗證方法分別適用于系統(tǒng)生命周期的不同階段。靜態(tài)的分析、測試和策略實施分別應用于系統(tǒng)設計、實現(xiàn)和執(zhí)行的不同階段。 其中靜態(tài)分析在計算機科學領域指的是一種在不執(zhí)行程序的情況下對程序行為進行分析的理論、技術。 靜態(tài)分析通常采用形式化方法（比如模型檢測），可以支持比較嚴格的驗證。但問題在于靜態(tài)分析方法往往是重量級的，不適合在系統(tǒng)執(zhí)行時應用，并且擴展性差，難以支持分布式應用。 測試的方法有很多，可以支持多種類型的、全方

3、位的系統(tǒng)檢測。但測試通常采用的是非形式化方法，難以保證驗證的完備性，并且也不適于在系統(tǒng)運行時做驗證。 相對于測試和靜態(tài)分析，策略主要具有兩個優(yōu)點，一個是它采用形式化方法，另一個優(yōu)點是策略是輕量級的驗證方法，可以在系統(tǒng)運行時修改，卻無需停機和重新編譯。 策略在系統(tǒng)運行時的執(zhí)行過程如下: 首先，系統(tǒng)的行為會引發(fā)一系列事件（對數(shù)據(jù)的讀寫訪問、對方法的操作、與時間有關的操作），其中某些事件會出發(fā)策略的執(zhí)行。當策略執(zhí)行時，會先去策略庫中把與該事件相關的策略都搜索出來，然后一一驗證這些策略的執(zhí)行條件是否滿足，最后，策略執(zhí)行模塊會把驗證結果返回給主程序，主程序根據(jù)策略驗證結果，執(zhí)行相應的策略。 在安全核心中

4、，策略可以與程序代碼一體，也可以與程序分開。在傳統(tǒng)的計算系統(tǒng)中，策略與系統(tǒng)是緊密耦合的。換句話說，策略是編寫在程序里面的。比如在法定最低小時工資的例子中，5元這個數(shù)字，就是編寫在程序里面的。策略與程序代碼混在一起的好處是運行效率較高。同時，策略和代碼一體化通常也會產生以下幾個方面的問題：（1）策略難以改變。比如說，當收入普遍提高以后，如果政府想將法定最低小時工資提高到8元，那就要把以前系統(tǒng)的源代碼全部找出，然后把有關5元的判斷語句全部改成8元。這樣就增加了工作量。并且很容易出錯和漏改。（2）當策略改變之后，還需要重新編譯、鏈接源代碼（3）還需要將新的可執(zhí)行文件重新部署到各個計算機上。因此，這種

5、一體化方法通常只適用于少數(shù)不會經常改變的策略上。 應用程序安全核心策略與策略執(zhí)行數(shù)據(jù)當計算從靜態(tài)結構向著隨請求變化而動態(tài)改變的商業(yè)事務結構轉變時，策略和代碼緊密綁定的方法就不能滿足需求了。原因主要有三個方面（1）有更多的策略需要被執(zhí)行（2）策略會經常改變，甚至在運行時發(fā)生改變（3）底層硬件已經得到了很大的提高，所以系統(tǒng)的靈活性開始顯得比執(zhí)行速度更加重要。因為，我們需要一種新的策略機制，將策略定義從策略執(zhí)行中分離出來，以支持更加靈活的策略定義及改變。如圖，策略定義獨立于安全核心，由策略庫統(tǒng)一管理，人們可以在不影響程序執(zhí)行情況下，定義和修改策略庫。安全核心在策略執(zhí)行的過程中，每次都通過訪問策略庫，

6、獲取并解釋執(zhí)行的最新的策略。 應用程序安全核心策略與策略執(zhí)行數(shù)據(jù)策略庫另外，現(xiàn)存的大多數(shù)策略系統(tǒng)與原系統(tǒng)沒有交互。策略的執(zhí)行與系統(tǒng)的執(zhí)行是兩個獨立的過程。這些系統(tǒng)并不解決策略如何被系統(tǒng)的行為觸發(fā)，也不解決策略執(zhí)行的結果會對系統(tǒng)有什么反作用的問題。我們認為，這種方式不是最好的，真正的基于策略的系統(tǒng)應該實現(xiàn)策略與系統(tǒng)的交互。策略的執(zhí)行應該是事件驅動的，即系統(tǒng)中的事件可觸發(fā)策略的執(zhí)行，并且策略執(zhí)行的結果能夠影響系統(tǒng)的行為。為了實現(xiàn)策略系統(tǒng)與原系統(tǒng)的交互，書中提出一種新的策略和系統(tǒng)協(xié)調的機制。核心思想是：（1）在系統(tǒng)分析階段，把策略從系統(tǒng)中分離出來（2）在系統(tǒng)執(zhí)行階段，把策略與系統(tǒng)結合起來執(zhí)行 在集中

7、式計算系統(tǒng)中，策略是集中存在的；在分布式系統(tǒng)中，策略需要分布于各個不同的物理位置。應用程序安全核心策略與策略執(zhí)行數(shù)據(jù)應用程序安全核心策略與策略執(zhí)行數(shù)據(jù)策略庫策略庫 在分布式系統(tǒng)中，策略的執(zhí)行要復雜得多。另外，我們發(fā)現(xiàn)了下列研究問題：（1）不同的安全核心要建立互信機制（2）在分布式程序的不同模塊中，策略可能有時是不一樣的，甚至可能會是完全沖突的。如何解決這種沖突是一個問題。（3）在分布式系統(tǒng)中，每個構建都可能會有自己的局部策略庫，除此之外，整個系統(tǒng)也會有一個全局策略庫。在部署策略的過程中，如何辨別局部策略與全局策略是一個問題。（4）在策略執(zhí)行的過程中，有可能要訪問外部數(shù)據(jù)以確定策略是否成立。以何

8、種方式把這些數(shù)據(jù)實時地暴露給所需的策略執(zhí)行部件也同樣是一個問題。 最底層是各個自治的服務。 第二層是服務規(guī)約。因為每一個規(guī)約均可能有多種具體實現(xiàn)方法，所以每一個規(guī)約可以對應多個服務。 第三層是協(xié)同模板，主要負責服務間的協(xié)同。 第四層是協(xié)同規(guī)約層。每一個協(xié)同模板都有一個規(guī)約文件，用來說明該模板是如何組織的?，F(xiàn)在有兩個面向SOA的策略架構。一個是由IBM、微軟等公司聯(lián)合推出的Web Services Policy Framework(WS-Policy)，它已經提交W3C組織（ w3c 即 萬維網(wǎng)聯(lián)盟 。創(chuàng)建于1994年，是Web技術領域最具權威和影響力的國際中立性技術標準機構。 W3C 最重要的

9、工作是發(fā)展 Web 規(guī)范，這些規(guī)范描述了 Web 的通信協(xié)議），準備成為一個SOA中的標準。另一個是基于XACML的架構，是由Sun公司提出，并提交給OASIS（ OASIS是一個推進電子商務標準的發(fā)展、融合與采納的非盈利性國際化組織。 ）組織，也申請成為標準。 左圖顯示的WS-Policy的是三層架構。最底層是模型層，包括三個元素，分別是WSDL、外部模型以及UDDI中的tModel，然而該架構并沒有提供自己的模型描述語言；在第二層，也就是策略語言層，策略可以用一些聲明來表示；最高一層，也就是策略執(zhí)行層，WS-Policy在此也沒有提供策略執(zhí)行的方法。 右圖顯示了基于XACML的三層策略架構

10、。在模型層，采用了訪問控制語言XACML；在策略語言層次，因此XACML不是通用語言，所以策略只能描述與訪問控制相關的屬性和屬性值。在策略執(zhí)行層上，這一架構提供了一個概念的策略決策模板與策略執(zhí)行模塊。面向服務的策略架構有3個方面的問題：（1）WS-Policy和基于XACML的策略架構只是看門人。因為每個服務對于外部相當于一個黑盒，所以策略的執(zhí)行只能起到看門人的作用，并不能在服務執(zhí)行時全程進行跟蹤并對策略進行驗證。（2）只要外部服務請求能夠滿足看門程序的要求，那么在進入服務之后，任何惡意的行為都不能受到策略的約束。（3）由于策略是由服務擁有者制定的，所以作為服務的看門人，策略所制定的訪問門檻會

11、很低。這樣雖然不一定會破壞服務本身，但卻可能對使用服務的用戶造成無法挽回的損失。1策略規(guī)約2策略分析3策略驗證4策略執(zhí)行5策略補償6策略運行數(shù)據(jù)收集 策略規(guī)約是用半形式化的方法規(guī)定了系統(tǒng)運行時所需要的策略有兩種策略規(guī)約生成方法。 第一種是手工地將系統(tǒng)需求分成兩部分：系統(tǒng)行為和系統(tǒng)策略，然后再把系統(tǒng)策略寫成規(guī)約形式。也就是說系統(tǒng)模型與策略的模型是完全分開的。第二種方法是生成系統(tǒng)模型后，按模型驅動的方式來生成策略。在這種方式下，策略是自動生成的，并自動建立與系統(tǒng)的依賴關系。 另外，今后的系統(tǒng)越來越大，依賴關系也越來越多，所以第一種方法是不適用的，第二種方法會越來越被使用。 策略分析是用于解決策略中

12、的依賴關系 因為策略的生成是模型驅動的，所以當系統(tǒng)模型改變之后，策略也要相應地改變，從而使策略與系統(tǒng)一致。否則，策略的執(zhí)行將會對系統(tǒng)的運行發(fā)出錯誤指令！舉個例子:原來的系統(tǒng)規(guī)定法定最低時薪為5元，且有一條相應的策略實現(xiàn)了改需求，同時還規(guī)定，違反該策略的補償行為是對雇主罰款1萬元。更新系統(tǒng)之后，法定最低時薪上升到10元。假如策略沒有更新的話，那很多在新政策下不合法的雇主就不能得到相應的觸發(fā)。1、策略規(guī)約2、策略分析 策略驗證是用于解決策略中可能存在的不一致關系。舉一個策略不一致的例子：假如一條策略規(guī)定了法定最高時薪為10元，而加入的另一條策略又規(guī)定了公務員的最低時薪不得低于12元，可見這兩條策略

13、是不相容的。策略的驗證方法可以檢測出這種不一致關系 策略的執(zhí)行是由系統(tǒng)運行時產生的事件觸發(fā)的。當策略被觸發(fā)后，根據(jù)系統(tǒng)中其他變量的狀態(tài)，推斷系統(tǒng)的下一步行為是否符合策略，如果符合，就允許系統(tǒng)進入下一步，如果不符合，就交給策略補償模塊去處理。3、策略驗證4、策略執(zhí)行策略補償就是對系統(tǒng)執(zhí)行中的錯誤進行補償?shù)男袨椤Ｑa償?shù)姆椒ㄓ泻芏喾N，根據(jù)不同的系統(tǒng)，不同的錯誤，可以采取不同的方法。通常在模擬仿真中，我們只能把策略執(zhí)行所檢測到的錯誤記錄到日志文件中，并讓系統(tǒng)繼續(xù)運行。然而，在與人的生命相關的系統(tǒng)中，我們必須預先規(guī)定一系列補償措施。當錯誤發(fā)生后，由這些補償措施接手系統(tǒng)的執(zhí)行權。比如說在飛行員試飛系統(tǒng)中，如果發(fā)生的錯誤是致命的，那么補償策略可以是先把飛行員彈出機艙，然后自動打開降落傘。策略在運行時會產生大量數(shù)據(jù)，需要收集這些數(shù)據(jù)。策略運行數(shù)據(jù)的收集并不是一個必需模塊，但卻