策略供應的制作方法

專利名稱：策略供應的制作方法
技術領域：
本發明涉及策略供應。
背景技術：
面向服務的體系架構(S0A)是一種用于計算系統的設計范例。它基于其中在需 要和能力方面來考慮計算資源的抽象模型。在這樣的模型中，服務是一種使得其對于服務 客戶端可用以滿足該客戶端的一個或多個需要的實體。S0A的核心原理是服務被松散地耦 合，即不同的服務可以由潛在地分布于不同物理位置或計算機網絡中的多個點處的不同供 應商提供。因此，不以固定的單一分組提供服務(傳統軟件應用的情況通常就是這樣)，而 是作為代替，服務客戶端可以聚集最適合其需要的特定服務組。當期望整合各種計算功能 (例如在商業中使用的若干不同計算功能)時，S0A模型可能特別有益。在這種情況下，S0A 范例可以導致冗余度的減小以及結果降低的調試(commission)和維護成本，例如因為諸 如登錄或認證之類的常見任務僅被實施一次并且然后作為服務(或服務集)被共享，而不 是在若干單獨的軟件應用中被獨立地提供。由S0A提供的效率和靈活性方面的潛在改進很大。然而，這樣的軟件體系架構所 要求的開放性和互操作性對計算機系統的設計者提出了額外的要求。例如，期望的是組 織保留對于使得作為服務可用的軟件組件的充分控制，而不管其在網絡上的開放可用性。 這就產生“管理服務”的概念，使得該管理服務可供服務客戶端使用但是根據運行時策略 (runtime policy)來管理該管理服務。該運行時策略確保服從組織的整體商業策略。這是 包含在商業策略中的原理的實際實施。執行運行時策略的責任由策略執行點(PEP)承擔。這些點是系統體系架構中可以 充當服務的網關的點。因此，希望訪問服務的客戶端經由為該服務執行運行時策略的策略 執行點來訪問服務。當面向服務的交互的一方同意遵守另一方的策略時形成約定。

發明內容
根據本發明的第一方面，提供了一種用于具有面向服務的體系架構的計算系統的 自動化策略供應方法，所述系統包括至少一個管理服務以及在操作中執行用于所述服務的 運行時策略的至少一個策略執行點，所述方法包括使用物理計算設備，以機器可讀的形 式接收用于限定由商業策略施加的條件的至少一個語義規則；使用物理計算設備，接收用 于描述所述至少一個策略執行點的運行時策略執行能力的機器可讀數據；使用物理計算 設備，基于所述至少一個規則和能力來確定所述至少一個策略執行點是否能夠滿足所述條 件；使用物理計算設備并且基于所述確定，導出適合用于執行所述條件的運行時策略；以 及使用物理計算設備，將所述運行時策略傳送到所述至少一個策略執行點。根據本發明的第二方面，提供了一種用于具有面向服務的體系架構的計算系統的 策略執行點配置方法，所述系統包括至少一個管理服務，該策略執行點在操作中執行用于 所述服務的運行時策略，所述方法包括在包括所述策略執行點的物理計算設備處接收對信息的請求；響應于所述請求，使用所述物理計算設備來提供用于描述所述策略執行點的 運行時策略執行能力的機器可讀數據；以及在所述物理計算設備處接收要被執行的運行時 策略。根據本發明的第三方面，提供了一種計算機程序，包括計算機程序代碼構件，如果 在物理計算設備上運行所述程序則所述計算機程序代碼構件適于使得所述計算設備執行 本發明第一方面的所有步驟。根據本發明的第四方面，提供了一種對具有面向服務的體系架構的計算系統進行 自動化策略供應的供應引擎，所述系統包括至少一個管理服務以及在操作中通過執行運行 時策略來實施所述管理服務的運行時管控的至少一個策略執行點，所述供應引擎包括存 儲器，用于以機器可讀的形式存儲用于限定由商業策略施加的條件的至少一個語義規則以 及用于描述所述至少一個策略執行點的運行時策略執行能力的數據；處理器，適于基于所 述至少一個規則和能力來確定所述至少一個策略執行點是否能夠滿足所述條件以及基于 所述確定來導出適合用于執行所述條件的運行時策略；以及輸出裝置，用于將所述運行時 策略傳送到所述至少一個策略執行點。


為了更好地理解本發明，現在將參考附圖僅以示例的方式來描述實施例，其中圖1是在具有面向服務的體系架構的計算系統中的根據實施例的策略供應 (policy-provisioning)弓|擎的框圖；圖2是示出根據實施例的策略供應引擎的組件的框圖；圖3是圖示對“敏感服務(Susc印tibleService) ”的概念進行建模的本體 (ontology)的示例的示圖；圖4是圖示對策略層級進行建模的本體的示例的示圖；圖5是根據實施例的自動化策略供應方法的流程圖；以及圖6是根據實施例的策略執行點配置方法的流程圖。
具體實施例方式在S0A中設計、實施和維護用于每個管理服務的運行時策略的需要可能使得調試 具有這種體系架構的計算機系統很困難。對于包括多種服務的更復雜的系統而言，情況尤 其如此。不同的客戶端可能以許多不同的方式經由若干策略執行點來訪問每個服務；然而 在每種情況下，預期運行時策略應該對商業策略的需求保持一致且忠誠，例如以避免系統 安全性的潛在弱點。隨著系統變得更加復雜(通常隨時間變化和增長)，變得越來越難以確 保管控服務的運行時策略都與商業策略保持適當一致。此外，商業策略本身可能經歷變化， 那么應該對所有受影響的運行時策略實施該變化。在企業部署情形中，期望的是使得對于顧客和商業伙伴可用的服務由已使得該服 務可用的組織的商業策略管控。商業策略表示高級的一般化的指令。為了實現運行時管控， 商業策略被映射到適當的運行時策略上并且被部署在策略執行點上。將商業策略映射到運 行時策略、將適當的運行時策略與服務相關聯以及將該運行時策略部署在合適的策略執行 點上的過程被稱為“供應(provision)”。
供應過程包括審查(inspect)策略執行點的能力以將它們與服務的任何策略需 求匹配；基于商業策略將特定運行時策略與策略執行點相關聯；以及將運行時策略部署在 適當的策略執行點上。根據一些實施例，在供應過程中的一些或所有步驟可以被高效地自 動化。然而，供應服務本質上不是簡單了當的，并且沒有單一的、簡單的、預先定義的自動化 方法可以被直接應用來實現供應服務。通常在供應過程中的每個步驟中包括多個約束和挑 戰，所以期望自動化(或半自動化)方法應該靈活并且能夠動態地適應其本身可能變化的 這些約束。供應過程中的不同參與者都會提出挑戰。每種服務可以具有在導出運行時策略時 需要考慮的其自己的單獨屬性。例如，如果服務使用Java消息服務(JMS)作為接受消息的 入站機制，則供應引擎不能盲目地應用傳輸安全策略以保障服務的安全；在這種情形下，需 要應用消息級安全策略來保護引入的消息。類似地，盡管任何給定的策略執行點可以具有各種能力來實現期望的商業策略實 施，但是一些方法相對于其它方法來說可能是優選的。例如，PEP可能能夠在消息級和傳輸 級兩者保護服務，然而消息級安全比傳輸級安全可能給出更有利的對策。同樣，組織的商業策略的復雜性和多樣性提出挑戰。可能存在執行商業策略的大 量方式，例如商業策略可能可通過策略A和策略B的組合執行，或者它可以通過執行單一的 策略C來實現，等等。結果，在商業策略和技術策略之間不存在可以被簡單地盲目自動化的 直接的、一般的、可普遍應用的映射。圖1示出具有面向服務的體系架構的計算機系統的框圖。該計算機系統包括根據 實施例的策略供應引擎10。該計算機系統包括若干服務，例如服務A 31和服務B 32。使 得服務客戶端20可以經由兩個策略執行點(PEP) (PEP1 41和PEP2 42)獲得這些服務。提 供策略供應引擎10以用合適的運行時策略配置PEP。該配置步驟是一種脫機過程，也就是 說，策略供應引擎可以運行一次，并且此后它不需要與PEP進行通信。該一次通信由圖1中 的虛線指示。當然，例如當新的服務或策略執行點被添加到該系統時或者在商業策略變化 的情況下，策略供應引擎可以再次運行配置過程來提供新的運行時策略。可選地提供儲存庫50。儲存庫可以存儲關于服務31、32和/或PEP41、42的信息。 在這種情況下，儲存庫50是用作服務和策略執行點偽像(artifact)的持久介質的中央單 元(central location)。策略供應引擎10可以查閱儲存庫50以發現PEP 41、42的能力以 及每個服務31、32的細節。注意，儲存庫50還可以通過還使得服務客戶端20能夠發現可 用服務31、32而在計算機系統的正常操作中起作用。每個PEP 41、42能夠為服務31、32中的一個或多個提供運行時管控。在由圖1所 圖示的示例配置中，PEP 141管理服務A 31 ；PEP 242管理服務A 31和服務B 32兩者。服 務客戶端20可以經由PEP 41、42中的任一個來訪問服務A 31，并且可以僅通過PEP 242來 訪問服務B 32。每個PEP為它管理的服務執行各種運行時策略。這些運行時策略可以包括 例如安全策略或審計策略。策略供應引擎10導出適當的運行時策略以供每個PEP執行。這些策略基于組織 的整體商業策略。供應引擎10將這些單獨的運行時策略部署在相應的PEP上。通過集中 地協調運行時策略的供應，系統可以優選地根據商業策略來確保一致的運行時管控。圖2更詳細地示出了供應引擎10的邏輯結構。供應引擎包括知識庫(knowledgebase) 12、計劃模塊14、推理引擎16、以及供應模塊18。知識庫存儲描述組織的商業策略的 數據。該信息通常包括規則集以及用于表達這些規則的某種概念模型，所述規則是由商業 策略設置的條件。商業策略中的概念模型例如可以是本體。關于商業策略的知識被計劃模 塊14用來導出適當的且優選最優的運行時策略。計劃模塊14負責基于從知識庫12獲得的商業策略的約束以及從儲存庫50獲得 的關于每個PEP的能力和每個服務的需要的信息來計劃運行時策略。例如，計劃模塊14可 以選擇在儲存庫50中登記的給定服務；基于包含在知識庫中的商業策略來標識施加于該 服務的使用上的需求；以及然后為一個或多個PEP開發合適的運行時策略來管理對該服務 的訪問。以此方式開發運行時策略可以包括使用所有可用的信息和約束來進行邏輯推理。 計劃模塊14使用推理引擎16來實施這樣的推理。當計劃模塊14開發了適當的運行時策略時，供應模塊18被用于將這些運行 時策略傳送到它們相應相關的PEP 41、42。例如作為語義web服務(as semantic web services)，每個策略執行點暴露(expose)支持策略的供應的操作。PEP還可以支持用于自 動發現PEP能力的功能。也就是說，供應引擎10可以直接詢問每個PEP來確定其能力。這 可以是在儲存庫50中存儲PEP描述的替換方案或除了將PEP描述存儲在儲存庫50中之外 還可以這樣做。注意，圖2中被示為包括在供應引擎10中的一些組件可以可替換地從外部提供或 以不同的分組提供。例如，知識庫12可以處于供應引擎10的外部(如在圖1和圖2中示 出的儲存庫50)。如上所述，關于用來描述商業策略的概念的信息可以以本體的形式存儲在知識庫 12中。如本領域技術人員將所公知的那樣，本體是概念集以及概念間關系的結構化表示。 本體可以用來支持邏輯推理。圖3示出了對“敏感服務” 61的概念建模的本體的示例。該 本體表示存在特定種類的服務(被稱為“敏感服務”)的知識，根據商業策略所述服務可以 由“消息安全策略” 66或由“傳輸安全策略” 68保障安全。圖4示出了不同類型的策略的層級的示例。本體捕獲下面的關系。“安全策略”72 是“策略”70。“傳輸安全策略”68和“消息安全策略”66是“安全策略”72的兩個示例。“基 于證書的HTTPS互相認證策略” 76是一種“傳輸安全策略” 68。這種策略由HTTPS協議78 支持。“X. 509證書令牌簡檔策略” 74是一種類型的“消息安全策略” 66。這種策略由HTTP 和HTTPS協議79兩者支持。根據在圖3和圖4中示出的本體，推理引擎16可以推斷敏感服務61類型的服務 可以通過HTTPS上的“傳輸安全策略” 68來保障安全，或者它可以通過HTTP或HTTPS上的 “消息安全策略” 66來保障安全。這一非常簡單的示例在原理上示出了邏輯推理如何可以用 來在更廣闊的范圍上使用存儲在本體中的域特定的知識來推理出可能的運行時策略。它還 示出了如何可以以機器可讀且可處理的格式表示通常以自然語言記載的商業策略的概念。 例如，本體可以以可擴展標記語言(XML)或者其它適合的語言或格式表示。根據實施例，商業策略的規則還能以機器可讀的形式表示。此外，可以以機器可讀 的形式例如在儲存庫50中或者通過供應引擎10直接詢問PEP和服務來提供每個PEP的能 力和每個服務的描述。
諸如在圖1和圖2中示出的那些實施例的實施例可以用來在若干階段中供應適合 的運行時策略。第一階段是商業策略建模階段。在該階段中，如上面所描述的，使用本體來 捕獲和建模包含在一個或多個商業策略中的知識。生成語義規則，智能軟件組件可以使用 所述語義規則以及本體來自動生成將管控服務的運行時策略。商業策略建模階段可以包括 該商業策略信息的人工錄入。例如，在商業策略建模階段期間，語義規則和本體優選地以機 器可處理的格式捕獲域知識以及相關聯的約束。因為本體支持邏輯推理，所以包含在本體 內的知識隨后可以被利用來設計供應對策。下一階段是能力發現階段。在該階段中，檢查在儲存庫中登記的策略執行點的能 力。由PEP支持的用來供應具有適當策略的服務的操作也被檢查。該信息可以由供應引 擎10用來確定每個策略執行點如何可以根據商業策略來參與服務的管理。可選地，與每個 PEP有關的能力數據可以被合并到由知識庫12維護的一個或多個本體中。這可以包括創建 新的本體或者更新那些已經存在于該知識庫中的本體。在計劃階段中，供應引擎10選擇要供應的給定服務。存儲在儲存庫50中的該服 務的描述被檢查以評估由商業策略施加的哪些約束適用于該服務。使用推理引擎16來執 行邏輯推理，計劃模塊14將限定商業策略的規則和本體與關于每個策略執行點的能力的 信息相結合，以得到用于該服務的一個或多個有效的運行時策略。這些計劃表示就該服務 而言商業策略的需求可以由可用PEP滿足的可能方式。如果多于一個的可能性集合是可行 的，則系統設計者可以在它們之間選擇。可替換地，知識庫12可以包括與其它可能性相比 偏好一些可能性的知識。這可以優選地使得計劃模塊14能夠基于所有可用的約束和偏好 來設計最優的運行時策略。如果計劃模塊14確定在給定的情況下不可能滿足商業策略需 求，則供應引擎10可以提醒系統設計者注意該問題。在實行(execution)階段中，被認可的計劃被傳送到相關的PEP。這可以通過每個 PEP上的一系列web服務調用(call)來進行。該階段將所計劃的運行時策略應用于PEP， 該PEP然后準備好在計算機系統的正常使用中適當地管理服務。可以對系統中的每個服務 重復計劃和/或實行階段。當服務、PEP或商業策略變化時，可以重復一些或所有階段。圖5示出了根據實施例的方法的流程圖。在步驟80中，計劃模塊14從知識庫12 接收在商業策略建模階段中捕獲的規則。在步驟81中，從儲存庫50接收被供應的一個或多個服務31、32的細節。該服務 信息可以包括每個服務的需求的明確細節，或者可以包括標識服務類型的信息，以使得可 以例如根據已經在知識庫12中捕獲的知識來推理出其需求。作為對從儲存庫50接收服務 信息的替換，服務31、32本身可以將該信息直接或間接地提供給供應引擎。在任何一種情 況下，該信息使得供應引擎能夠確定哪個或哪些規則與任何給定的服務有關。也就是說，基 于該信息，供應引擎能夠確定商業策略的哪些方面可應用于給定的服務。還注意，在一些情形中步驟81可以是可選的運行時策略將不一定總是依賴于服 務需求一例如在系統中的所有服務都具有相同的已知標準需求的普通情況下。然后在步驟82中接收每個PEP的能力信息。該能力信息可以從PEP本身接收或 者還可以從儲存庫50接收。在步驟84中，計劃模塊14控制推理引擎16來執行邏輯推理。 這推斷出對于感興趣的一個或多個給定服務而言滿足商業策略的可能方式，從而使得計劃 模塊14能夠在步驟86中導出完整的運行時策略。在步驟88中該運行時策略被傳送到一個或多個合適的PEP并且應用于所述PEP。圖6示出了由PEP實行的根據實施例的方法的流程圖。在步驟90中，PEP 41,42 從供應引擎10接收對與其策略執行能力有關的信息的請求。作為響應，在步驟92中，PEP 41、42將關于其能力的機器可讀信息提供給供應引擎10。在供應引擎10已為該PEP(以及 系統中潛在的其它PEP)計劃了合適的策略之后，供應引擎10將該策略傳送到該PEP，其中 在步驟94中接收該策略。此后，該PEP應用該策略以控制每個服務客戶端20與由該PEP 管理的服務的交互。現在將通過簡單的具體示例來說明這些一般過程。在該示例中，公司希望使得股 票報價服務31作為web服務對其顧客以及商業伙伴可用。對該服務的所有請求都通過策 略執行點，策略執行點通過在運行時執行各種策略來提供對管理服務的管控。存在兩個策 略執行點41和42。PEP141是第一類型，而PEP2 42是第二類型。我們假定，例如商業策略規定“與可從外部訪問的服務的所有通信必須在安全的 環境中發生”。為了設計滿足上面規定的商業需求的供應對策，供應引擎使用語義規則和本 體來捕獲必要的知識。該過程使得供應引擎能夠解釋預先定義的知識并且設計適當的供應 對策。根據當前說明性的示例，限定具有類別Service的簡單的本體。限定檢驗服務是 否可從外部訪問的運算符 isExternallyAccessible。令 Susc印tibleService 成為 Service 的子類。在商業策略建模階段期間，系統設計者寫出捕獲該商業策略的語義規則。這可以 使用語義Web規則語言(SWRL)來完成。該語言由在http://www. w3. org/Submission/SWRL 可得到的 “SWRL:A Semantic Web Rule Language, W3C Member Submission21 May 2004” 限定。使用該語言，如下可以使用簡單規則來限定特定商業策略需求Service ( ？ someService)"isExternallyAccessible( ？ someService)= >SusceptibleService( ？ someService)該規則規定由變量？ someService表示的任何Service如果可從外部訪問則意 味著它是Susc印tibleService。現在，如果使用如圖3所示的本體來對敏感服務概念建模， 則供應引擎可以通過使用簡單的查詢來斷定可以通過執行消息安全策略或通過執行傳輸 安全策略來保障敏感服務的安全。因此，應該使用這兩種類型策略中的一種或另一種來保 障滿足規則的任何服務的安全。這說明該供應如何可以使用語義規則和本體來制定開發合 適的供應對策所需的合適決策。在策略執行點能力發現階段期間，供應引擎發現所登記的策略執行點41和42的 能力，并且建立所述能力以及其屬性的語義模型。供應引擎發現下列方面可以由給定的PEP執行的策略 PEP1 41可以執行基于證書的HTTPS互相認證策略。-PEP2 42可以執行基于證書的HTTPS互相認證策略和X. 509證書令牌簡檔策略。所支持的策略類型 基于證書的HTTPS互相認證策略是傳輸安全策略。
X. 509證書令牌簡檔策略是消息安全策略。每個所支持的策略的屬性 X. 509證書令牌簡檔策略支持HTTP、HTTPS。
基于證書的HTTPS互相認證策略僅支持HTTPS。在當前說明性的示例中，供應引擎使用在能力發現階段中發現的信息能夠建立如 圖4所示的策略層級的語義模型。現在供應引擎具有為自動生成供應對策所需的所有信息 (在設計商業策略時輸入的)來自商業策略建模階段的語義規則和知識。 (在運行供應引擎時自動和/或交互式發現的)來自策略執行點能力發現階段 的關于PEP的能力的知識。使用在商業策略建模階段中得到的知識，供應引擎了解到如果服務被暴露到外部 世界則它是敏感服務；它還了解到可以通過執行消息安全策略或者傳輸安全策略來保障該 敏感服務的安全。供應引擎還從策略執行點能力發現階段認識到類型1的PEP 41支持基 于證書的HTTPS互相認證策略的執行，而類型2的PEP 42支持基于證書的HTTPS互相認證 策略以及X. 509證書令牌簡檔策略的執行；以及基于證書的HTTPS互相認證策略是傳輸安 全策略，而X. 509證書令牌簡檔策略是消息安全策略。最后，供應引擎能夠制訂出滿足需求的兩個計劃計劃-A 服務31可以被部署在類型1的PEP1 41上；基于證書的HTTPS互相認證策略提 供傳輸級安全，并且可通過HTTPS訪問該服務。 服務31可以被部署在類型2的PEP2 42上；基于證書的HTTPS互相認證策略提 供傳輸級安全，并且可通過HTTPS訪問該服務。計劃-B 服務31可以被部署在類型1的PEP 141上；基于證書的HTTPS互相認證策略提 供傳輸級安全，并且可通過HTTPS訪問該服務。 服務31可以被部署在類型2的PEP2 42上；X. 509證書令牌簡檔策略提供消息 級安全，并且可通過HTTP訪問該服務。在這兩種情形中，或者通過消息級安全或者通過傳輸級安全來實現安全通信的目 標。如果知識庫知道與其它可能性相比偏好一些可能性，則系統可以在所提議的計劃 之中推薦最優的計劃。例如，假如在消息級安全和傳輸級安全之間選擇，組織可能喜歡消息 級安全勝過傳輸級安全，因為消息級安全準許僅加密包含敏感信息的部分消息而不是加密 整個消息。這可以顯著地降低加密的處理時間。如果該知識被包含在供應引擎中，則它可 以將計劃-B排級高于計劃-A。然后可以將計劃-B作為選項之間的最優計劃選擇建議給系 統設計者。這可以去除系統設計者的進一步的負擔。策略供應引擎10的組件計劃模塊14、推理引擎16和供應模塊18 ；該系統的任何 其它軟件組件；以及策略供應引擎10的數據和指令可以被存儲在相應的存儲設備中，所述 存儲設備被實施為一個或多個計算機可讀或計算機可用存儲介質。該存儲介質可以包括不 同形式的存儲器，包括諸如動態或靜態隨機存取存儲器(DRAM或SRAM)、可擦除且可編程只 讀存儲器(EPR0M)、電可擦除且可編程只讀存儲器(EEPR0M)以及閃存之類的半導體存儲器 設備；諸如固定盤、軟盤和可移動盤之類的磁盤；包括磁帶的其它磁介質；以及諸如緊致盤 (CD)或數字視頻盤(DVD)之類的光學介質。注意，上面討論的軟件的指令可以被提供在一
10個計算機可讀或計算機可用存儲介質上，或者可替換地，可以被提供在分布在可能具有多 個節點的大系統中的多個計算機可讀或計算機可用存儲介質上。這樣的一個或多個計算機 可讀或計算機可用存儲介質被認為是物品(或制造物品)的一部分。物品或制造物品可以 指的是任何制造的單個組件或多個組件。因此，策略供應引擎可以由一個或多個物理計算設備來實施或實現。例如，知識庫 12和/或儲存庫50可以被提供為存儲在存儲介質上的數據。這樣的存儲介質可以包括已 經在前面的段落中提及的不同形式的存儲器。因此，例如可以提供存儲器來存儲商業策略 的語義規則、描述PEP的運行時策略執行能力的數據、以及關于服務需求的信息。可以控制計算設備中的處理器以執行用于履行供應引擎的功能的指令，所述功能 包括計劃模塊、推理引擎以及供應模塊中的任一或全部的功能。如所公知的那樣，物理計算設備可以具有各種類型的輸入和輸出裝置。輸入裝置 可以被用來接收要被存儲在一個或多個存儲器中且由供應引擎使用的數據，例如包括商業 策略的規則和模型、PEP能力或服務細節。輸出裝置可以被用來將所導出的運行時策略從 該供應引擎傳送到PEP。輸入和輸出裝置可以包括適合用于計算機的各種各樣的常規輸入 /輸出設備中的任何一種。如本領域技術人員將會認識到的那樣，這些包括(但不限于)有 線或無線網絡連接；諸如通用串行總線(USB)之類的其它光學或電通信接口 ；以及可移動 (或靜態)存儲介質。在商業策略建模階段中，商業策略信息(例如語義規則和/或本體) 可以由系統設計者通過諸如鍵盤或鼠標之類的輸入裝置或者任何其它人機接口人工地輸 入。盡管已經在本文中處于說明的目的描述了特定實施例，但是各種其它修改對本領 域技術人員來說是顯而易見的并且可以在不偏離本發明的范圍的情況下完成。
權利要求
一種用于具有面向服務的體系架構的計算系統的自動化策略供應方法，所述系統包括至少一個管理服務(31、32)以及在操作中執行用于所述服務的運行時策略的至少一個策略執行點(41、42)，所述方法包括使用物理計算設備，以機器可讀的形式接收(80)用于限定由商業策略施加的條件的至少一個語義規則；使用物理計算設備，接收(82)用于描述所述至少一個策略執行點的運行時策略執行能力的機器可讀數據；使用物理計算設備，基于所述至少一個規則和能力來確定(84)所述至少一個策略執行點是否能夠滿足所述條件；使用物理計算設備并且基于所述確定，導出(86)適合用于執行所述條件的運行時策略；以及使用物理計算設備，將所述運行時策略傳送(88)到所述至少一個策略執行點。
2.根據權利要求1所述的方法，還包括以機器可讀的形式接收用于描述被用來限定所述商業策略的多個概念的模型的數據，其中所述模型指定所述概念之間的第一語義關系集合，以及所述至少一個規則指定所述概念之間的第二關系集合，所述第一和第二關系集合包括 商業策略。
3.根據權利要求2所述的方法，其中所述模型包括本體。
4.根據權利要求2所述的方法，其中從知識庫(12)接收所述模型以及所述至少一個語 義規則，之前已將它們輸入到所述知識庫(12)。
5.根據權利要求1所述的方法，其中直接從所述至少一個策略執行點(41、42)本身接 收用于描述所述至少一個策略執行點的運行時策略執行能力的機器可讀數據；或者從之前 已經將所述數據存儲到的儲存庫(50)接收所述數據。
6.根據權利要求1所述的方法，還包括使用物理計算設備，以機器可讀的形式接收(81)用于描述所述至少一個管理服務的 信息；以及使用物理計算設備，基于所述信息確定所述至少一個語義規則能夠應用于所述管理服務。
7.根據權利要求1所述的方法，在確定所述至少一個策略執行點是否能夠滿足所述條 件的步驟中包括確定所述至少一個策略執行點能夠以兩種或更多種不同的方式滿足所述條件；以及在所述兩種或更多種不同的方式之間進行選擇。
8.根據權利要求7所述的方法，其中導出所述運行時策略的步驟包括基于預定的偏好 在所述兩種或更多種不同的方式之間進行選擇。
9.根據權利要求1所述的方法，在確定所述至少一個策略執行點是否能夠滿足所述條 件的步驟中包括確定所述至少一個策略執行點不能滿足所述條件；以及提醒用戶注意這一事實。
10.根據權利要求1所述的方法，其中傳送所述運行時策略的步驟包括在所述至少一個策略執行點上執行一系列web服務調用。
11.一種用于具有面向服務的體系架構的計算系統的策略執行點(41、42)配置方法， 所述系統包括至少一個管理服務(31、32)，該策略執行點(41、42)在操作中執行用于所述 服務的運行時策略，所述方法包括在包括所述策略執行點的物理計算設備處接收對信息的請求； 響應于所述請求，使用所述物理計算設備來提供用于描述所述策略執行點的運行時策 略執行能力的機器可讀數據；以及在所述物理計算設備處接收要被執行的運行時策略。
12.—種計算機程序，包括計算機程序代碼構件，如果在物理計算設備上運行所述程序 則所述計算機程序代碼構件適于使得所述計算設備執行權利要求1的所有步驟。
13.如權利要求12所述的計算機程序，其實現在計算機可讀介質上。
14.一種對具有面向服務的體系架構的計算系統進行自動化策略供應的供應引擎 (10)，所述系統包括至少一個管理服務(31、32)以及在操作中通過執行運行時策略來實施 所述管理服務的運行時管控的至少一個策略執行點(41、42)，所述供應引擎包括存儲器，用于以機器可讀的形式存儲 用于限定由商業策略施加的條件的至少一個語義規則；以及 用于描述所述至少一個策略執行點的運行時策略執行能力的數據， 處理器，適于基于所述至少一個規則和能力來確定所述至少一個策略執行點是否能夠滿足所述條 件；以及基于所述確定來導出適合用于執行所述條件的運行時策略，以及 輸出裝置，用于將所述運行時策略傳送到所述至少一個策略執行點。
15.根據權利要求14所述的供應引擎，還包括輸入裝置，用于以機器可讀的形式接收所述至少一個語義規則；以及 輸入裝置，用于以機器可讀的形式接收用于描述所述至少一個策略執行點的運行時策 略執行能力的數據。
全文摘要
本發明涉及策略供應。給出了一種用于具有面向服務的體系架構的計算系統的自動化策略供應方法。所述系統包括至少一個管理服務以及在操作中執行用于所述服務的運行時策略的至少一個策略執行點。所述方法包括以機器可讀的形式接收用于限定由商業策略施加的條件的至少一個語義規則；接收用于描述所述至少一個策略執行點的運行時策略執行能力的機器可讀數據；基于所述至少一個規則和能力來確定所述至少一個策略執行點是否能夠滿足所述條件；基于所述確定，導出適合用于執行所述條件的運行時策略；以及將所述運行時策略傳送到所述至少一個策略執行點。
文檔編號H04L29/06GK101867569SQ201010167179
公開日2010年10月20日 申請日期2010年4月20日 優先權日2009年4月20日
發明者K·J·阿爾梅達, N·拉馬拉賈, V·K·拉文德蘭 申請人:惠普開發有限公司