策略供应

摘要

本发明涉及策略供应。给出了一种用于具有面向服务的体系架构的计算系统的自动化策略供应方法。所述系统包括至少一个管理服务以及在操作中执行用于所述服务的运行时策略的至少一个策略执行点。所述方法包括：以机器可读的形式接收用于限定由商业策略施加的条件的至少一个语义规则；接收用于描述所述至少一个策略执行点的运行时策略执行能力的机器可读数据；基于所述至少一个规则和能力来确定所述至少一个策略执行点是否能够满足所述条件；基于所述确定，导出适合用于执行所述条件的运行时策略；以及将所述运行时策略传送到所述至少一个策略执行点。

权利要求

1.一种用于具有面向服务的体系架构的计算系统的自动化策略供应方法，所述系统包括至少一个管理服务(31、32)以及在操作中执行用于所述服务的运行时策略的至少一个策略执行点(41、42)，所述方法包括：使用物理计算设备，以机器可读的形式接收(80)用于限定由商业策略施加的条件的至少一个语义规则；

使用物理计算设备，接收(82)用于描述所述至少一个策略执行点的运行时策略执行能力的机器可读数据；

使用物理计算设备，基于所述至少一个语义规则和能力来确定(84)所述至少一个策略执行点是否能够满足所述条件；

使用物理计算设备并且基于所述确定，导出(86)适合用于执行所述条件的运行时策略；以及使用物理计算设备，将所述运行时策略传送(88)到所述至少一个策略执行点，其中该方法还包括：以机器可读的形式接收用于描述被用来限定所述商业策略的多个概念的模型的数据，其中所述模型指定所述概念之间的第一语义关系集合，以及所述至少一个语义规则指定所述概念之间的第二关系集合，所述第一和第二关系集合包括商业策略。

2.根据权利要求1所述的方法，其中所述模型包括本体。

3.根据权利要求1所述的方法，其中从知识库(12)接收所述模型以及所述至少一个语义规则，之前已将它们输入到所述知识库(12)。

4.根据权利要求1所述的方法，其中直接从所述至少一个策略执行点(41、42)本身接收用于描述所述至少一个策略执行点的运行时策略执行能力的机器可读数据；或者从之前已经将所述数据存储到的储存库(50)接收所述数据。

5.根据权利要求1所述的方法，还包括：

使用物理计算设备，以机器可读的形式接收(81)用于描述所述至少一个管理服务的信息；以及使用物理计算设备，基于所述信息确定所述至少一个语义规则能够应用于所述管理服务。

6.根据权利要求1所述的方法，在确定所述至少一个策略执行点是否能够满足所述条件的步骤中包括：确定所述至少一个策略执行点能够以两种或更多种不同的方式满足所述条件；以及在所述两种或更多种不同的方式之间进行选择。

7.根据权利要求6所述的方法，其中导出所述运行时策略的步骤包括基于预定的偏好在所述两种或更多种不同的方式之间进行选择。

8.根据权利要求1所述的方法，在确定所述至少一个策略执行点是否能够满足所述条件的步骤中包括：确定所述至少一个策略执行点不能满足所述条件；以及提醒用户注意这一事实。

9.根据权利要求1所述的方法，其中传送所述运行时策略的步骤包括在所述至少一个策略执行点上执行一系列web服务调用。

10.一种对具有面向服务的体系架构的计算系统进行自动化策略供应的供应引擎(10)，所述系统包括至少一个管理服务(31、32)以及在操作中通过执行运行时策略来实施所述管理服务的运行时管控的至少一个策略执行点(41、42)，所述供应引擎包括：存储器，用于以机器可读的形式存储：

用于限定由商业策略施加的条件的至少一个语义规则；以及用于描述所述至少一个策略执行点的运行时策略执行能力的数据，处理器，适于：

基于所述至少一个语义规则和能力来确定所述至少一个策略执行点是否能够满足所述条件；以及基于所述确定来导出适合用于执行所述条件的运行时策略，以及输出装置，用于将所述运行时策略传送到所述至少一个策略执行点，其中该存储器还以机器可读的形式存储用于描述被用来限定所述商业策略的多个概念的模型的数据，其中所述模型指定所述概念之间的第一语义关系集合，以及所述至少一个语义规则指定所述概念之间的第二关系集合，所述第一和第二关系集合包括商业策略。

11.根据权利要求10所述的供应引擎，还包括：

输入装置，用于以机器可读的形式接收所述至少一个语义规则；以及输入装置，用于以机器可读的形式接收用于描述所述至少一个策略执行点的运行时策略执行能力的数据。

说明书

策略供应

技术领域

[0001] 本发明涉及策略供应。

背景技术

[0002] 面向服务的体系架构(SOA)是一种用于计算系统的设计范例。它基于其中在需要和能力方面来考虑计算资源的抽象模型。在这样的模型中，服务是一种使得其对于服务客户端可用以满足该客户端的一个或多个需要的实体。SOA的核心原理是服务被松散地耦合，即不同的服务可以由潜在地分布于不同物理位置或计算机网络中的多个点处的不同供应商提供。因此，不以固定的单一分组提供服务(传统软件应用的情况通常就是这样)，而是作为代替，服务客户端可以聚集最适合其需要的特定服务组。当期望整合各种计算功能(例如在商业中使用的若干不同计算功能)时，SOA模型可能特别有益。在这种情况下，SOA范例可以导致冗余度的减小以及结果降低的调试(commission)和维护成本，例如因为诸如登录或认证之类的常见任务仅被实施一次并且然后作为服务(或服务集)被共享，而不是在若干单独的软件应用中被独立地提供。

[0003] 由SOA提供的效率和灵活性方面的潜在改进很大。然而，这样的软件体系架构所要求的开放性和互操作性对计算机系统的设计者提出了额外的要求。例如，期望的是组织保留对于使得作为服务可用的软件组件的充分控制，而不管其在网络上的开放可用性。这就产生“管理服务”的概念，使得该管理服务可供服务客户端使用但是根据运行时策略(runtime policy)来管理该管理服务。该运行时策略确保服从组织的整体商业策略。这是包含在商业策略中的原理的实际实施。

[0004] 执行运行时策略的责任由策略执行点(PEP)承担。这些点是系统体系架构中可以充当服务的网关的点。因此，希望访问服务的客户端经由为该服务执行运行时策略的策略执行点来访问服务。当面向服务的交互的一方同意遵守另一方的策略时形成约定。

发明内容

[0005] 根据本发明的第一方面，提供了一种用于具有面向服务的体系架构的计算系统的自动化策略供应方法，所述系统包括至少一个管理服务以及在操作中执行用于所述服务的运行时策略的至少一个策略执行点，所述方法包括：使用物理计算设备，以机器可读的形式接收用于限定由商业策略施加的条件的至少一个语义规则；使用物理计算设备，接收用于描述所述至少一个策略执行点的运行时策略执行能力的机器可读数据；使用物理计算设备，基于所述至少一个规则和能力来确定所述至少一个策略执行点是否能够满足所述条件；使用物理计算设备并且基于所述确定，导出适合用于执行所述条件的运行时策略；以及使用物理计算设备，将所述运行时策略传送到所述至少一个策略执行点。

[0006] 根据本发明的第二方面，提供了一种用于具有面向服务的体系架构的计算系统的策略执行点配置方法，所述系统包括至少一个管理服务，该策略执行点在操作中执行用于所述服务的运行时策略，所述方法包括：在包括所述策略执行点的物理计算设备处接收对信息的请求；响应于所述请求，使用所述物理计算设备来提供用于描述所述策略执行点的运行时策略执行能力的机器可读数据；以及在所述物理计算设备处接收要被执行的运行时策略。

[0007] 根据本发明的第三方面，提供了一种计算机程序，包括计算机程序代码构件，如果在物理计算设备上运行所述程序则所述计算机程序代码构件适于使得所述计算设备执行本发明第一方面的所有步骤。

[0008] 根据本发明的第四方面，提供了一种对具有面向服务的体系架构的计算系统进行自动化策略供应的供应引擎，所述系统包括至少一个管理服务以及在操作中通过执行运行时策略来实施所述管理服务的运行时管控的至少一个策略执行点，所述供应引擎包括：存储器，用于以机器可读的形式存储用于限定由商业策略施加的条件的至少一个语义规则以及用于描述所述至少一个策略执行点的运行时策略执行能力的数据；处理器，适于基于所述至少一个规则和能力来确定所述至少一个策略执行点是否能够满足所述条件以及基于所述确定来导出适合用于执行所述条件的运行时策略；以及输出装置，用于将所述运行时策略传送到所述至少一个策略执行点。

附图说明

[0009] 为了更好地理解本发明，现在将参考附图仅以示例的方式来描述实施例，其中：

[0010] 图1是在具有面向服务的体系架构的计算系统中的根据实施例的策略供应(policy-provisioning)引擎的框图；

[0011] 图2是示出根据实施例的策略供应引擎的组件的框图；

[0012] 图3是图示对“敏感服务(SusceptibleService)”的概念进行建模的本体(ontology)的示例的示图；

[0013] 图4是图示对策略层级进行建模的本体的示例的示图；

[0014] 图5是根据实施例的自动化策略供应方法的流程图；以及

[0015] 图6是根据实施例的策略执行点配置方法的流程图。

具体实施方式

[0016] 在SOA中设计、实施和维护用于每个管理服务的运行时策略的需要可能使得调试具有这种体系架构的计算机系统很困难。对于包括多种服务的更复杂的系统而言，情况尤其如此。不同的客户端可能以许多不同的方式经由若干策略执行点来访问每个服务；然而在每种情况下，预期运行时策略应该对商业策略的需求保持一致且忠诚，例如以避免系统安全性的潜在弱点。随着系统变得更加复杂(通常随时间变化和增长)，变得越来越难以确保管控服务的运行时策略都与商业策略保持适当一致。此外，商业策略本身可能经历变化，那么应该对所有受影响的运行时策略实施该变化。

[0017] 在企业部署情形中，期望的是使得对于顾客和商业伙伴可用的服务由已使得该服务可用的组织的商业策略管控。商业策略表示高级的一般化的指令。为了实现运行时管控，商业策略被映射到适当的运行时策略上并且被部署在策略执行点上。将商业策略映射到运行时策略、将适当的运行时策略与服务相关联以及将该运行时策略部署在合适的策略执行点上的过程被称为“供应(provision)”。

[0018] 供应过程包括：审查(inspect)策略执行点的能力以将它们与服务的任何策略需求匹配；基于商业策略将特定运行时策略与策略执行点相关联；以及将运行时策略部署在适当的策略执行点上。根据一些实施例，在供应过程中的一些或所有步骤可以被高效地自动化。然而，供应服务本质上不是简单了当的，并且没有单一的、简单的、预先定义的自动化方法可以被直接应用来实现供应服务。通常在供应过程中的每个步骤中包括多个约束和挑战，所以期望自动化(或半自动化)方法应该灵活并且能够动态地适应其本身可能变化的这些约束。

[0019] 供应过程中的不同参与者都会提出挑战。每种服务可以具有在导出运行时策略时需要考虑的其自己的单独属性。例如，如果服务使用Java消息服务(JMS)作为接受消息的入站机制，则供应引擎不能盲目地应用传输安全策略以保障服务的安全；在这种情形下，需要应用消息级安全策略来保护引入的消息。

[0020] 类似地，尽管任何给定的策略执行点可以具有各种能力来实现期望的商业策略实施，但是一些方法相对于其它方法来说可能是优选的。例如，PEP可能能够在消息级和传输级两者保护服务，然而消息级安全比传输级安全可能给出更有利的对策。

[0021] 同样，组织的商业策略的复杂性和多样性提出挑战。可能存在执行商业策略的大量方式，例如商业策略可能可通过策略A和策略B的组合执行，或者它可以通过执行单一的策略C来实现，等等。结果，在商业策略和技术策略之间不存在可以被简单地盲目自动化的直接的、一般的、可普遍应用的映射。

[0022] 图1示出具有面向服务的体系架构的计算机系统的框图。该计算机系统包括根据实施例的策略供应引擎10。该计算机系统包括若干服务，例如服务A 31和服务B 32。使得服务客户端20可以经由两个策略执行点(PEP)(PEP1 41和PEP2 42)获得这些服务。提供策略供应引擎10以用合适的运行时策略配置PEP。该配置步骤是一种脱机过程，也就是说，策略供应引擎可以运行一次，并且此后它不需要与PEP进行通信。该一次通信由图1中的虚线指示。当然，例如当新的服务或策略执行点被添加到该系统时或者在商业策略变化的情况下，策略供应引擎可以再次运行配置过程来提供新的运行时策略。

[0023] 可选地提供储存库50。储存库可以存储关于服务31、32和/或PEP41、42的信息。在这种情况下，储存库50是用作服务和策略执行点伪像(artifact)的持久介质的中央单元(central location)。策略供应引擎10可以查阅储存库50以发现PEP 41、42的能力以及每个服务31、32的细节。注意，储存库50还可以通过还使得服务客户端20能够发现可用服务31、32而在计算机系统的正常操作中起作用。

[0024] 每个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为它管理的服务执行各种运行时策略。这些运行时策略可以包括例如安全策略或审计策略。

[0025] 策略供应引擎10导出适当的运行时策略以供每个PEP执行。这些策略基于组织的整体商业策略。供应引擎10将这些单独的运行时策略部署在相应的PEP上。通过集中地协调运行时策略的供应，系统可以优选地根据商业策略来确保一致的运行时管控。

[0026] 图2更详细地示出了供应引擎10的逻辑结构。供应引擎包括知识库(knowledge base)12、计划模块14、推理引擎16、以及供应模块18。知识库存储描述组织的商业策略的数据。该信息通常包括规则集以及用于表达这些规则的某种概念模型，所述规则是由商业策略设置的条件。商业策略中的概念模型例如可以是本体。关于商业策略的知识被计划模块14用来导出适当的且优选最优的运行时策略。

[0027] 计划模块14负责基于从知识库12获得的商业策略的约束以及从储存库50获得的关于每个PEP的能力和每个服务的需要的信息来计划运行时策略。例如，计划模块14可以选择在储存库50中登记的给定服务；基于包含在知识库中的商业策略来标识施加于该服务的使用上的需求；以及然后为一个或多个PEP开发合适的运行时策略来管理对该服务的访问。

[0028] 以此方式开发运行时策略可以包括使用所有可用的信息和约束来进行逻辑推理。计划模块14使用推理引擎16来实施这样的推理。

[0029] 当计划模块14开发了适当的运行时策略时，供应模块18被用于将这些运行时策略传送到它们相应相关的PEP 41、42。例如作为语义web服务(as semantic web services)，每个策略执行点暴露(expose)支持策略的供应的操作。PEP还可以支持用于自动发现PEP能力的功能。也就是说，供应引擎10可以直接询问每个PEP来确定其能力。这可以是在储存库50中存储PEP描述的替换方案或除了将PEP描述存储在储存库50中之外还可以这样做。

[0030] 注意，图2中被示为包括在供应引擎10中的一些组件可以可替换地从外部提供或以不同的分组提供。例如，知识库12可以处于供应引擎10的外部(如在图1和图2中示出的储存库50)。

[0031] 如上所述，关于用来描述商业策略的概念的信息可以以本体的形式存储在知识库12中。如本领域技术人员将所公知的那样，本体是概念集以及概念间关系的结构化表示。
本体可以用来支持逻辑推理。图3示出了对“敏感服务”61的概念建模的本体的示例。该本体表示存在特定种类的服务(被称为“敏感服务”)的知识，根据商业策略所述服务可以由“消息安全策略”66或由“传输安全策略”68保障安全。

[0032] 图4示出了不同类型的策略的层级的示例。本体捕获下面的关系。“安全策略”72是“策略”70。“传输安全策略”68和“消息安全策略”66是“安全策略”72的两个示例。“基于证书的HTTPS互相认证策略”76是一种“传输安全策略”68。这种策略由HTTPS协议78支持。“X.509证书令牌简档策略”74是一种类型的“消息安全策略”66。这种策略由HTTP和HTTPS协议79两者支持。

[0033] 根据在图3和图4中示出的本体，推理引擎16可以推断敏感服务61类型的服务可以通过HTTPS上的“传输安全策略”68来保障安全，或者它可以通过HTTP或HTTPS上的“消息安全策略”66来保障安全。这一非常简单的示例在原理上示出了逻辑推理如何可以用来在更广阔的范围上使用存储在本体中的域特定的知识来推理出可能的运行时策略。它还示出了如何可以以机器可读且可处理的格式表示通常以自然语言记载的商业策略的概念。例如，本体可以以可扩展标记语言(XML)或者其它适合的语言或格式表示。

[0034] 根据实施例，商业策略的规则还能以机器可读的形式表示。此外，可以以机器可读的形式例如在储存库50中或者通过供应引擎10直接询问PEP和服务来提供每个PEP的能力和每个服务的描述。

[0035] 诸如在图1和图2中示出的那些实施例的实施例可以用来在若干阶段中供应适合的运行时策略。第一阶段是商业策略建模阶段。在该阶段中，如上面所描述的，使用本体来捕获和建模包含在一个或多个商业策略中的知识。生成语义规则，智能软件组件可以使用所述语义规则以及本体来自动生成将管控服务的运行时策略。商业策略建模阶段可以包括该商业策略信息的人工录入。例如，在商业策略建模阶段期间，语义规则和本体优选地以机器可处理的格式捕获域知识以及相关联的约束。因为本体支持逻辑推理，所以包含在本体内的知识随后可以被利用来设计供应对策。

[0036] 下一阶段是能力发现阶段。在该阶段中，检查在储存库中登记的策略执行点的能力。由PEP支持的用来供应具有适当策略的服务的操作也被检查。该信息可以由供应引擎10用来确定每个策略执行点如何可以根据商业策略来参与服务的管理。可选地，与每个PEP有关的能力数据可以被合并到由知识库12维护的一个或多个本体中。这可以包括创建新的本体或者更新那些已经存在于该知识库中的本体。

[0037] 在计划阶段中，供应引擎10选择要供应的给定服务。存储在储存库50中的该服务的描述被检查以评估由商业策略施加的哪些约束适用于该服务。使用推理引擎16来执行逻辑推理，计划模块14将限定商业策略的规则和本体与关于每个策略执行点的能力的信息相结合，以得到用于该服务的一个或多个有效的运行时策略。这些计划表示就该服务而言商业策略的需求可以由可用PEP满足的可能方式。如果多于一个的可能性集合是可行的，则系统设计者可以在它们之间选择。可替换地，知识库12可以包括与其它可能性相比偏好一些可能性的知识。这可以优选地使得计划模块14能够基于所有可用的约束和偏好来设计最优的运行时策略。如果计划模块14确定在给定的情况下不可能满足商业策略需求，则供应引擎10可以提醒系统设计者注意该问题。

[0038] 在实行(execution)阶段中，被认可的计划被传送到相关的PEP。这可以通过每个PEP上的一系列web服务调用(call)来进行。该阶段将所计划的运行时策略应用于PEP，该PEP然后准备好在计算机系统的正常使用中适当地管理服务。可以对系统中的每个服务重复计划和/或实行阶段。当服务、PEP或商业策略变化时，可以重复一些或所有阶段。

[0039] 图5示出了根据实施例的方法的流程图。在步骤80中，计划模块14从知识库12接收在商业策略建模阶段中捕获的规则。

[0040] 在步骤81中，从储存库50接收被供应的一个或多个服务31、32的细节。该服务信息可以包括每个服务的需求的明确细节，或者可以包括标识服务类型的信息，以使得可以例如根据已经在知识库12中捕获的知识来推理出其需求。作为对从储存库50接收服务信息的替换，服务31、32本身可以将该信息直接或间接地提供给供应引擎。在任何一种情况下，该信息使得供应引擎能够确定哪个或哪些规则与任何给定的服务有关。也就是说，基于该信息，供应引擎能够确定商业策略的哪些方面可应用于给定的服务。

[0041] 还注意，在一些情形中步骤81可以是可选的：运行时策略将不一定总是依赖于服务需求--例如在系统中的所有服务都具有相同的已知标准需求的普通情况下。

[0042] 然后在步骤82中接收每个PEP的能力信息。该能力信息可以从PEP本身接收或者还可以从储存库50接收。在步骤84中，计划模块14控制推理引擎16来执行逻辑推理。这推断出对于感兴趣的一个或多个给定服务而言满足商业策略的可能方式，从而使得计划模块14能够在步骤86中导出完整的运行时策略。在步骤88中该运行时策略被传送到一个或多个合适的PEP并且应用于所述PEP。

[0043] 图6示出了由PEP实行的根据实施例的方法的流程图。在步骤90中，PEP 41、42从供应引擎10接收对与其策略执行能力有关的信息的请求。作为响应，在步骤92中，PEP41、42将关于其能力的机器可读信息提供给供应引擎10。在供应引擎10已为该PEP(以及系统中潜在的其它PEP)计划了合适的策略之后，供应引擎10将该策略传送到该PEP，其中在步骤94中接收该策略。此后，该PEP应用该策略以控制每个服务客户端20与由该PEP管理的服务的交互。

[0044] 现在将通过简单的具体示例来说明这些一般过程。在该示例中，公司希望使得股票报价服务31作为web服务对其顾客以及商业伙伴可用。对该服务的所有请求都通过策略执行点，策略执行点通过在运行时执行各种策略来提供对管理服务的管控。存在两个策略执行点41和42。PEP141是第一类型，而PEP2 42是第二类型。

[0045] 我们假定，例如商业策略规定“与可从外部访问的服务的所有通信必须在安全的环境中发生”。为了设计满足上面规定的商业需求的供应对策，供应引擎使用语义规则和本体来捕获必要的知识。该过程使得供应引擎能够解释预先定义的知识并且设计适当的供应对策。

[0046] 根据当前说明性的示例，限定具有类别Service的简单的本体。限定检验服务是否可从外部访问的运算符isExternallyAccessible。令SusceptibleService成为Service的子类。在商业策略建模阶段期间，系统设计者写出捕获该商业策略的语义规则。这可以使用语义Web规则语言(SWRL)来完成。该语言由在http://www.w3.org/Submission/SWRL可得到的“SWRL：A Semantic Web Rule Language，W3C Member Submission21 May 2004”限定。使用该语言，如下可以使用简单规则来限定特定商业策略需求：

[0047] Service (？someService)^isExtemallyAccessible(？someService)＝＞[0048] SusceptibleService(？someService)

[0049] 该规则规定：由变量？someService表示的任何Service如果可从外部访问则意味着它是SusceptibleService。现在，如果使用如图3所示的本体来对敏感服务概念建模，则供应引擎可以通过使用简单的查询来断定可以通过执行消息安全策略或通过执行传输安全策略来保障敏感服务的安全。因此，应该使用这两种类型策略中的一种或另一种来保障满足规则的任何服务的安全。这说明该供应如何可以使用语义规则和本体来制定开发合适的供应对策所需的合适决策。

[0050] 在策略执行点能力发现阶段期间，供应引擎发现所登记的策略执行点41和42的能力，并且建立所述能力以及其属性的语义模型。供应引擎发现下列方面：

[0051] 可以由给定的PEP执行的策略：

[0052] ·PEP1 41可以执行基于证书的HTTPS互相认证策略。

[0053] ·PEP2 42可以执行基于证书的HTTPS互相认证策略和X.509证书令牌简档策略。

[0054] 所支持的策略类型：

[0055] ·基于证书的HTTPS互相认证策略是传输安全策略。

[0056] ·X.509证书令牌简档策略是消息安全策略。

[0057] 每个所支持的策略的属性：

[0058] ·X.509证书令牌简档策略支持HTTP、HTTPS。

[0059] ·基于证书的HTTPS互相认证策略仅支持HTTPS。

[0060] 在当前说明性的示例中，供应引擎使用在能力发现阶段中发现的信息能够建立如图4所示的策略层级的语义模型。

[0061] 现在供应引擎具有为自动生成供应对策所需的所有信息：

[0062] ·(在设计商业策略时输入的)来自商业策略建模阶段的语义规则和知识。

[0063] ·(在运行供应引擎时自动和/或交互式发现的)来自策略执行点能力发现阶段的关于PEP的能力的知识。

[0064] 使用在商业策略建模阶段中得到的知识，供应引擎了解到如果服务被暴露到外部世界则它是敏感服务；它还了解到可以通过执行消息安全策略或者传输安全策略来保障该敏感服务的安全。供应引擎还从策略执行点能力发现阶段认识到：类型1的PEP 41支持基于证书的HTTPS互相认证策略的执行，而类型2的PEP 42支持基于证书的HTTPS互相认证策略以及X.509证书令牌简档策略的执行；以及基于证书的HTTPS互相认证策略是传输安全策略，而X.509证书令牌简档策略是消息安全策略。

[0065] 最后，供应引擎能够制订出满足需求的两个计划：

[0066] 计划-A

[0067] ·服务31可以被部署在类型1的PEP1 41上；基于证书的HTTPS互相认证策略提供传输级安全，并且可通过HTTPS访问该服务。

[0068] ·服务31可以被部署在类型2的PEP2 42上；基于证书的HTTPS互相认证策略提供传输级安全，并且可通过HTTPS访问该服务。

[0069] 计划-B

[0070] ·服务31可以被部署在类型1的PEP 141上；基于证书的HTTPS互相认证策略提供传输级安全，并且可通过HTTPS访问该服务。

[0071] ·服务31可以被部署在类型2的PEP2 42上；X.509证书令牌简档策略提供消息级安全，并且可通过HTTP访问该服务。

[0072] 在这两种情形中，或者通过消息级安全或者通过传输级安全来实现安全通信的目标。

[0073] 如果知识库知道与其它可能性相比偏好一些可能性，则系统可以在所提议的计划之中推荐最优的计划。例如，假如在消息级安全和传输级安全之间选择，组织可能喜欢消息级安全胜过传输级安全，因为消息级安全准许仅加密包含敏感信息的部分消息而不是加密整个消息。这可以显著地降低加密的处理时间。如果该知识被包含在供应引擎中，则它可以将计划-B排级高于计划-A。然后可以将计划-B作为选项之间的最优计划选择建议给系统设计者。这可以去除系统设计者的进一步的负担。

[0074] 策略供应引擎10的组件：计划模块14、推理引擎16和供应模块18；该系统的任何其它软件组件；以及策略供应引擎10的数据和指令可以被存储在相应的存储设备中，所述存储设备被实施为一个或多个计算机可读或计算机可用存储介质。该存储介质可以包括不同形式的存储器，包括诸如动态或静态随机存取存储器(DRAM或SRAM)、可擦除且可编程只读存储器(EPROM)、电可擦除且可编程只读存储器(EEPROM)以及闪存之类的半导体存储器设备；诸如固定盘、软盘和可移动盘之类的磁盘；包括磁带的其它磁介质；以及诸如紧致盘(CD)或数字视频盘(DVD)之类的光学介质。注意，上面讨论的软件的指令可以被提供在一个计算机可读或计算机可用存储介质上，或者可替换地，可以被提供在分布在可能具有多个节点的大系统中的多个计算机可读或计算机可用存储介质上。这样的一个或多个计算机可读或计算机可用存储介质被认为是物品(或制造物品)的一部分。物品或制造物品可以指的是任何制造的单个组件或多个组件。

[0075] 因此，策略供应引擎可以由一个或多个物理计算设备来实施或实现。例如，知识库12和/或储存库50可以被提供为存储在存储介质上的数据。这样的存储介质可以包括已经在前面的段落中提及的不同形式的存储器。因此，例如可以提供存储器来存储商业策略的语义规则、描述PEP的运行时策略执行能力的数据、以及关于服务需求的信息。

[0076] 可以控制计算设备中的处理器以执行用于履行供应引擎的功能的指令，所述功能包括计划模块、推理引擎以及供应模块中的任一或全部的功能。

[0077] 如所公知的那样，物理计算设备可以具有各种类型的输入和输出装置。输入装置可以被用来接收要被存储在一个或多个存储器中且由供应引擎使用的数据，例如包括商业策略的规则和模型、PEP能力或服务细节。输出装置可以被用来将所导出的运行时策略从该供应引擎传送到PEP。输入和输出装置可以包括适合用于计算机的各种各样的常规输入/输出设备中的任何一种。如本领域技术人员将会认识到的那样，这些包括(但不限于)有线或无线网络连接；诸如通用串行总线(USB)之类的其它光学或电通信接口；以及可移动(或静态)存储介质。在商业策略建模阶段中，商业策略信息(例如语义规则和/或本体)可以由系统设计者通过诸如键盘或鼠标之类的输入装置或者任何其它人机接口人工地输入。

[0078] 尽管已经在本文中处于说明的目的描述了特定实施例，但是各种其它修改对本领域技术人员来说是显而易见的并且可以在不偏离本发明的范围的情况下完成。