内容


深入理解 WS-Policy 处理

探究 WS-Policy 中的交集、融合和标准化

Comments

引言

Web 服务策略框架 (WS-Policy) 规范为服务请求者和服务提供者定义了语法和语义来描述他们的需求、首选项和性能。语法为以 策略的形式表述每个领域的需求提供了一种灵活简洁的方法。领域在本文中指的是关系到服务重要性的通用描述,如下所示:

  • 安全
  • 隐私
  • 应用程序优先权
  • 用户帐户优先权
  • 传输控制

规范还描述了这些策略的处理模型,处理模型是独立于领域的。对于处理策略定义了 3 种操作: 标准化, 融合交集。本文讨论了这些功能,重点说明了这些处理的潜在意义。

有必要花一些时间来讨论以下 WS-Policy 框架规范所使用的一些基本术语。术语 断言替代在本文中大量使用,因此在下面这一部分主要介绍这些术语以便让用户熟悉它们。

断言

断言是策略的基本单元。对于策略处理基础架构来说,可以将其看作一条指令。例如,断言可以声明消息是被加密的。这种断言的实际定义将包含在 WS-Security 策略域规范中。

因此,每个断言的意义是特定于各领域的,可以通过它们自己单独的规范来识别,各特定领域断言的详细信息都超出了 WS-Policy 框架的范围。但是,WS-Policy 框架将每个断言看作 opaque。

每个断言可以通过它们的 限定名 ( QName) 来识别。断言可以是一个简单的字符串或带多个子元素和属性的复杂对象。但是,任何 WS-Policy 框架处理中只涉及到 XML 的根元素 QName

替代

策略是由断言和操作符 <wsp:All><wsp:ExactlyOne> 的嵌套组合以及 可选 属性构成的。对于给定的 Web 服务调用,利用该策略语法来描述可接受的断言组合,最终形成策略处理基础架构的完整指令集。每组断言集在术语上称为 替代

注意,只有包含 可选属性或 <wsp:ExactlyOne> 操作符的策略才有多个替代。换句话说,只包含一个断言和 <wsp:All> 操作符的策略可以解析为一个替代。

下面的部分涉及到可以应用到策略上的每种处理类型。

标准化处理

灵活的 Web 服务策略框架语法可能会产生潜在的复杂策略。定义策略的 标准 格式以简化策略的操作和阐明对其的理解。正是基于 标准 格式的策略来执行策略处理的基本操作的。

为对策略进行 融合交集 操作,必须首先把策略简化为 标准格式。 标准格式只包含一个可选操作符 <wsp:ExactlyOne>。下面通过简单的 XML 格式定义了 标准格式的策略,其模式如 清单 1 所示。

清单 1. 标准格式策略实例
<wsp:Policy ... >
   <wsp:ExactlyOne>
    [<wsp:All> [ <assertion ...>... </assertion>]* 
     </wsp:All> ]*
   </wsp:ExactlyOne>
</wsp:Policy>

注意在 标准化策略中, <wsp:ExactlyOne> 出现且只出现一次。从效果上看, <wsp:ExactlyOne> 操作符内的每个元素都是策略替代。每个策略替代都被封装在 <wsp:All> 操作符内。

要 2 个 标准策略的专门实例无任何意义。 第一个是空策略,如 清单 2 所示。

清单 2. 空策略
<wsp:Policy ... > 
   <wsp:ExactlyOne>
      <wsp:All/>
   </wsp:ExactlyOne>
</wsp:Policy>

<wsp:All/> 表示的单个空策略替代表明不需要任何断言。这说明策略基础架构不需要采取任何行动。空替代出现在标准化策略中用来连接其它非空策略,它只是说明不采用任何行动是正确的。

标准化策略的第二个特例是 null 策略。

清单 3. null 策略
<wsp:Policy ... >
   <wsp:ExactlyOne/>
</wsp:Policy>

null 策略说明没有合法的替代。对于 Web 服务的任何调用尝试都不会成功,这是由于根据请求环境不存在已经定义的策略。例如服务提供方要求采用一种特殊的加密方法,而服务请求方没有支持这种加密方法的安全基础架构。在这种情况下,策略框架判定兼容策略为 null ,服务的调用将不会成功。

我更感兴趣的是 可选属性的使用。如果一个策略只包含 2 个可选断言,那么将有 4 个有效组合,因此,正常情况下,策略将有 4 个替代。类似地,3 个可选断言将会产生 8 个替代。如果增加更多的断言,可以清楚地看到,替代的数量将指数级的增长。少数几个断言就会产生大量替代,多得都让人无法接受,因此,一定要谨慎使用 可选属性。

标准化用法实例

可以用一系列步骤来演示标准化流程,下面显示了流程中的各步骤,演示了它是如何运行的。考虑 清单 4 中的策略。

清单 4. 一个基本的标准化策略
<wsp:Policy ...>
   <wsp:All>
      <wsp:ExactlyOne>
         <nsSecurityAssertion wsp:Optional="true"/>
         <nsReliableMessagingAssertion/>
      </wsp:ExactlyOne>
      <nsTransactionAssertion/>
      <nsAuditAssertion/>
   </wsp:All>
</wsp:Policy>

步骤 1:扩展 @wsp:Optional 属性

首先,扩展 @wsp:Optional 属性。这意味对于每个可选断言将产生 2 个条目。一个条目包含断言,另一个条目,断言将是空的。为描述这两个选项,可以采用 <wsp:ExactlyOne>> 操作符。为描述没有出现断言的选项,可使用空策略语法。例如:

<nsSecurityassertion wsp:Optional="true"/>

将扩展为:

<wsp:ExactlyOne>
   <nsSecurityassertion/>
   <wsp:All/> 
</wsp:ExactlyOne>

因此,实例策略看起来如 清单 5 所示。

清单 5. 修改后的标准化策略
<wsp:All>
   <wsp:ExactlyOne>
      <wsp:ExactlyOne>
         <nsSecurityAssertion/>
         <wsp:All/>
      </wsp:ExactlyOne> <nsReliableMessagingAssertion/>
   </wsp:ExactlyOne>
   <nsTransactionAssertion/>
   <nsAuditAssertion/>
</wsp:All>

步骤 2: 处理策略操作符

接下来,您需要重复处理策略操作符直到只剩一个 <wsp:ExactlyOne> 操作符,该操作符包含了封装在 <wsp:All> 中的断言。 由于可能性有限,这一步骤不会像您想象的那么复杂。例如,由于关联规则, <wsp:All> 包含一个 <wsp:All>,或 <wsp:ExactlyOne> 包含一个 <wsp:ExactlyOne>,都处理为单一操作符。

下面的实例显示了如何开始断言和与外部协作。如果在该实例中,您抵消了 <wsp:ExactlyOne>,将得到如 清单 6 所示的结果。

清单 6. 处理操作符
<wsp:All>          
   <wsp:ExactlyOne>
      <nsSecurityAssertion/>
      <wsp:All/>
      <nsReliableMessagingAssertion/>
   </wsp:ExactlyOne>
   <nsTransactionAssertion/>
   <nsAuditAssertion/>
</wsp:All>

步骤 3. 重复处理流程直到统一

这种处理流程会一直重复直到只剩一个外部 <wsp:ExatclyOne> 操作符。在本实例中,唯一的技巧就是将操作符 <wsp:All><wsp:ExactlyOne> 进行转换。转换过程采用跨产品原则。

<wsp:ExactlyOne> 中取出单一断言并与外部 <wsp:All> 中的所有断言进行组合。

<wsp:ExactlyOne>
   <wsp:All>
      <nsSecurityAssertion/>
      <nsTransactionAssertion/>
      <nsAuditAssertion/>
   </wsp:All>
   <wsp:All>
      <wsp:All/> 
      <nsTransactionAssertion/>
      <nsAuditAssertion/> 
   </wsp:All>
   <wsp:All>
      <nsReliableMessagingAssertion/>
      <nsTransactionAssertion/>
      <nsAuditAssertion/>
   </wsp:All>
</wsp:ExactlyOne>

步骤 4. 最后的整理

为实现标准格式,最后还需要一些整理。 <wsp:All> 中的 <wsp:All>(空策略)可以移除。因为空断言说明该断言将不会执行。没有命名断言,不过它是隐式的。在本实例中,这是一个有效的可选安全断言。在这种情况下,断言没有出现。

如果将它与标准化策略的定义比较,可以发现,它现在已经是标准化格式了。有一个包含 <wsp:All> 操作符的 <wsp:ExactlyOne> 操作符。您可以看到该实例策略可以产生 3 个替代。

融合

融合是将多个子策略组合在一起形成一个单一策略的过程。这种操作是必须的,由于需要将多个片断策略组合成一个策略。例如,WS-PolicyAttachment 规范描述了如何将策略添加到 WSDL 的元素中。另外,WSDL 中的每个元素都有一个与它相关的策略列表。在策略处理过程中,需要将组合所有的策略形成一个单一混合策略。

融合过程发生在已经转化为 标准化格式的策略上。将各个子策略的替代组合为新的融合替代。组合过程遵循跨产品模式。从各策略提取替代直到枚举完所有的组合。清单 78 展示了如何在处理过程中融合 2 个策略。

清单 7. 策略 P1
<wsp:Policy wsu:id="P1"...>
   <wsp:ExactlyOne>
      <wsp:All>
         <nsSecurityAssertion/>
      </wsp:All>
      <wsp:All>
         <nsReliableMessagingAssertion/>
      </wsp:All>
   </wsp:ExactlyOne>
</wsp:Policy>

与下面的策略融合:

清单 8. 策略 P2
<wsp:Policy wsu:id="P2"...>
   <wsp:ExactlyOne>
      <wsp:All>
         <nsTransactionAssertion/>
      </wsp:All>
      <wsp:All>
         <nsAuditAssertion/>
      </wsp:All>
   </wsp:ExactlyOne>
</wsp:Policy>

要获取融合策略,将策略 P1 的每个替代与策略 P2 的每个替代进行组合。由于 P1 和 P2 已经是标准化格式,组合过程只是简单的从每个替代中取出断言,最后形成一个包含所有断言的新的替代。

清单 9. 融合策略 P1 和 P2
<wsp:Policy wsu:Id="P1 Merged with P2"...>
   <wsp:ExactlyOne>
      <wsp:All>
         <nsSecurityAssertion/>
         <nsTransactionAssertion/>
      </wsp:All>
      <wsp:All>
         <nsSecurityAssertion/>
         <nsAuditAssertion/>
      </wsp:All>
      <wsp:All>
         <nsReliableMessagingAssertion/>
         <nsTransactionAssertion/>
      </wsp:All>
      <wsp:All>
         <nsReliableMessagingAssertion/>
         <nsAuditAssertion/>
      </wsp:All>
   </wsp:ExactlyOne>
</wsp:Policy>

底层的策略基础架构负责判断引起断言重复的任何替代的意义。需要注意的是,如果每个源策略都有多个选择,融合策略的大小将急剧增加。考虑到这一点,对于 可选属性的使用要特别加以注意,因为它将导致数量的急剧膨胀。

交集

交集是比较用于公用替代的 2 个 Web 服务策略的过程。只有双方至少对一个策略替代达成一致,才会产生交集。当请求方以策略的形式表述性能和需求时通常采用这种操作。请求方策略可能断言本地运行基础架构能够进行处理。两个策略的交集给出 0 或多个双方一致同意的替代。

交集的处理并不像它首次出现那么易于理解。考虑如下问题:一个独立于领域的策略框架如何判定 2 个断言是否相同?断言的意义只有定义它们的领域才知道。要处理独立于领域的策略框架只能解决部分方面这个问题,需要领域知识完成流程。

两个策略都被扩展为 标准形式后才开始进行处理。然后 2 个标准化策略同时进行替代检查。第一阶段的目的是除去那些明显不同的替代。通过检查两个替代的 术语表完成这一任务。替代的 术语表是替代中断言的 QName 集。如果术语表不匹配,那么这两个替代明显不同,可从交集中除去。

注意,对术语表进行对比不考虑这些 QName 的副本。如果替代中不止一个断言具有相同的 QName ,它将与第二个替代中的所有具有同样 QName 的断言匹配。对比过程同样不考虑任何属性或断言可能具有的值。因此 2 个替代可能会共享同一术语表,但在某些方面却是截然相反的。例如: <nsAssertionvalue="on"/><nsAssertionvalue="off"/> 具有同样的 QName。对比过程实质上只是检查 2 个替代是否采用同样的语言进行表述。怎样进行排序是交集下一阶段的工作,排序会产生匹配的替代。

具有不同术语表的两个替代可看作是不兼容的。当两个替代具有匹配的术语表,可以组合产生交集策略的一个新替代。由于替代中的断言是组合形成的,得到的替代中将会包含多个重复的断言,可能还包含相互矛盾的断言。然而,更常见的是断言只在细节的表述上存在差别。例如,来自请求方策略的替代的断言可能只是简单说明它支持加密。因此它可能只包含一个根元素,而没有任何属性和值,而与此相对应的来自于服务提供方策略替代的断言可能包含加密使用的详细说明和一些详细属性。

以跨产品方式从 2 个策略进行结合替代流程。策略中的每个替代与另一个策略中的每个替代都进行比较。因此需要注意交集策略将会很大。源策略中存在越多的选择,潜在的组合数目将会越大。

定义如何来解释这些组合替代超出了 WS-Policy 框架规范的范围。需要领域知识来将新组合的替代合理地转化为对策略基础架构有意义的替代。例如,WS-Security 策略领域将是作为判断 2 个安全断言是互相矛盾的还是互为补充的唯一信息源。

将替代中具有同样 QName 的每个断言的重复出现处理为对基础架构有意义的单一指令,这需要与断言所在问题相关的知识。考虑如下问题:断言出现 2 次是否意味着基础架构要将断言定义的操作执行 2 次?要回答这个问题,前提是该问题必需是针对这里所描述的独立于领域的处理,答案必须源于特定领域的知识。

新产生的交集策略在确定可被 Web 服务交互双方支持和接受之前,可能还需要进一步处理。甚至有可能替代中包含矛盾,这对负责执行所需行为的底层基础架构没有意义,在这种情况下,调用将会失败。

同样需要注意交集对 null 策略或空策略实例的影响。任何策略与 null 策略的交集是 null 策略。任何策略与空策略的交集会导致带异常的 null 策略。如果两个空策略相交,结果是空策略。

实例

假设您有一个服务提供方策略和服务请求方策略。这些策略已经标准化,采用如下形式:

<wsp:Policy wsu:Id="Provider Policy"...>
   <wsp:ExactlyOne>
      <wsp:All> 
         <nsSecurityAssertion level="high"/> 
         <nsReliableMessagingAssertion/>
      </wsp:All>
      <wsp:All>
         <nsSecurityAssertion level="medium"/>
         <nsTransactionAssertion/>
      </wsp:All>
   </wsp:ExactlyOne>
</wsp:Policy>

请求端的策略为:

<wsp:Policy wsu:Id="Requester Policy"...>
   <wsp:ExactlyOne>
      <wsp:All>
         <nsSecurityAssertion/>
         <nsReliableMessagingAssertion timeout="100"/>
         <nsReliableMessagingAssertion retries="3"/>
      </wsp:All>
   </wsp:ExactlyOne>
</wsp:Policy>

交集处理从 <wsp:All> 操作符取出绑定的每个替代。只比较 QName 的断言。这意味着请求端的替代只与来自提供者策略的第一个替代进行匹配。这两个替代结合起来形成交互式替代。

<wsp:All>
   <nsSecurityAssertion level="high/>
   <nsSecurityAssertion/>
   <nsReliableMessagingAssertion timeout="100"/> 
   <nsReliableMessagingAssertion retries="3"/>
   <nsReliableMessagingAssertion/>
</wsp:All>

策略处理基础架构负责解释策略替代并将具有同样 Qname 的断言融合到对于处理模块具有意义的断言中。例如 ReliableMessagingAssertion 可很好地融合到下面的单个断言中:

 <nsReliableMessagingAssertion timeout="100" retries="3"/>

随着 Web 服务的交互越来越普遍,策略的使用将变得越来越明显,应用程序的开发者和发布者都将不可避免地受到策略处理的影响。基于当前的知识和经验,本文主要涉及到一些意义重大的问题。随着 Web 服务的不断进化和涉及到更深层次的问题,毫无疑问这是一个不断发展的主题,并将会不断出现新的变化。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=49283
ArticleTitle=深入理解 WS-Policy 处理
publish-date=12072004