| 非功能性需求的获取和表达是服务定义的一个重要部分,在组件和构件的生命周期中对SCA有重要的影响。从组件设计到具体部署,SCA提供了一个框架来支持约束、性能和QoS期望的规范。此规范描述这个框架和它的用法。
1. 策略框架(Policy Framework)
简介(Introduction)
非功能性需求的获取和表达是服务定义的一个重要部分,在组件和构件的生命周期中对SCA有重要的影响。从组件设计到具体部署,SCA提供了一个框架来支持约束、性能和QoS期望的规范。此规范描述这个框架和它的用法。
具体来讲,这部分描述了SCA策略相关框架,这个框架允许使用WS-Policy [6]和WS-PolicyAttachment [7]以及其它策略语言来指定与SCA组件相联系的策略和策略主题。
此文档应该和SCA 组装规范[2]结合阅读。具体策略域的策略细节参见1.7、1.8和1.9。
1.1.1 XML命名空间
此规范使用大量的命名空间前缀,它们在下面列出。注意,任何一个命名空间前缀的选择是任意的,在语义上不是很重要。
|
|
此规范用到的前缀和命名空间
|
|
|
前缀
|
XML命名空间
|
规范
|
|
sca
|
http://www.osoa.org/xmlns/sca/1.0"
This is assumed to be the default namespace in this
specification. xs:QNames that appear without a prefix are
from the SCA namespace.
|
[SCA]
|
|
Acme
|
Some namespace; a generic prefix
|
|
|
wsp
|
http://www.w3.org/2006/07/ws-policy
|
[WS-Policy]
|
|
xs
|
http://www.w3.org/2001/XMLSchema
|
[XML Schema Datatypes]
|
概况(Overview)
1.2.1 策略和策略集
术语Policy用来描述一些能力或约束,这些能力或约束应用于服务组件或服务组件(由服务和引用表示)之间的交互。Policy的一个例子是,一个服务客户机与一个被加密的服务提供者之间的消息交换,因此这个交换是秘密的,它不能被截取会话的人阅读。
在SCA中,服务和引用都可以应用策略,这些策略会影响发生在运行时的交互形式。它们被称为交互策略。
服务组件也可以应用其它的策略,这些策略会影响组件本身在运行时容器里如何运转。它们被称为实现策略。
如何提供特殊的策略依赖于实现策略运行时容器的类型和交互策略的绑定类型。一些策略可以作为容器或绑定的固有部分被提供,比如,使用https协议的绑定将一直提供引用和服务之间消息的加密。其它策略可以通过一个容器或一个绑定来提供。下面的情况也是可能的,即一些容器或绑定根本就不能提供特殊的策略。在SCA中,多个策略被放在策略集中,策略集可以包含一个或多个策略,这些策略表示为一些具体形式,如WS-Policy断言。每一个策略都会指向一个具体的绑定类型或一个具体的实现类型。
通过附在组件或构件上的配置信息,策略集可用来对一个组件应用特殊的策略,也可用来对服务或引用的绑定应用特殊的策略。
举例来说,一个服务可以应用这样一个策略,它要求所有与此服务的交互都被加密。连接到此服务的一个引用如果想正确使用这个服务,那么它必须能够支持使用特定的加密技术来发送和接收消息。
总之,一个服务表示一个交互策略的集合,这个服务要求引用使用这些策略。相反,每一个引用也有一个策略集合,这个集合定义了此引用如何与它连接的服务进行交互的。一个实现或组件可以通过一个附在它上面的实现策略描述它的需求。
1.2.2 描述组件、服务和引用的需求的意图
SCA意图(intents)用来描述一个组件的抽象的策略需求,或由服务和引用表示的组件之间的交互需求。意图独立于运行时和绑定的详细配置(属于应用部署人员的角色),为开发人员和集成人员以高层次的抽象形式来陈述这些需求提供了一个方法。意图支持特殊SCA绑定中服务和引用的后期绑定,因为它们可以协助部署人员选择合适的绑定和具体的策略,这些绑定和策略可以满足用意图表示的抽象需求。
在SCA中,通过绑定和策略集的配置,在组装创建的任何时候直接将策略附于一个服务或引用或组件是可能的。组件开发人员可以在组件编写或部署后被完成“附于”。对于一个特殊组装来说,如果绑定和具体的策略在部署时被决定,SCA建议后期绑定。SCA喜欢这种后期绑定是因为它提升了组件的可重用性。它允许在新的应用上下文中使用组件,新的应用上下文可能需要使用不同的绑定和不同的具体策略。早期对绑定和策略做出决策可能会限制可重用,还有可能限制在新的上下文中使用组件。
比如在授权的情况下,一个服务要求它的消息被授权,那么它可以有一个标记为“authentication”的意图。这个意图标记此服务要求消息授权而不用说明它是如何完成的。在部署时期,当为服务(如HTTP上的SOAP)选择绑定的时候,部署人员可以对服务应用合适的策略,此服务提供WS-Security的方面以及提供一组授权技术。
意图可以被看成部署时期的约束选择。如果一个服务标记为confidentiality意图,那么部署人员必须使用一个策略集提供对消息的加密。
开发人员核组装人员可以获得的意图集可以被管理员任意扩展。SCA策略框架规范定义了一个意图集,这个集合提供安全可靠的消息传递这方面的基础能力。
1.2.3 确定应用于特殊连线的策略
对于一个引用,为了连接到一个特殊的服务,此引用的策略必须与服务的策略相交。
多个策略可以被附于服务以及引用。在有多个策略的地方,它们被组织到策略域里,这里每一个域处理交互的一些特殊方面。策略域的一个例子时confidentiality,它覆盖了引用核服务之间消息发送的加密。一个特殊域存在多个策略时,这些策略表示在域里接触需求的不同方法。比如消息整合的情况,可以有一个策略集,每一个处理一个特殊的安全记号:X509,SAML,Kerberos。这些记号中的任何一个都可以被使用,它们都能保证消息整合可以完成。
为了使一个服务被更广范围的客户机访问,在一个特殊域里支持多个可选择的策略是一个良好习惯。因此,如果一个服务要求消息加密,取代使用一个具体的加密技术,此服务可以有一个策略集,这个策略集拥有很多可供选择的加密技术,其中的任何一个对服务都是可接受的。等价地,一个引用可以有一个策略集,它定义了一个可以使用的加密技术的范围。典型地,对于一个给定的域来说,这个被使用的策略集合将影响绑定(用在服务和引用上)和运行时的性能。
当一个服务核一个引用被连接到一起的时候,策略集声明的每一个连线的末尾的策略要彼此匹配。SCA没有定义策略匹配如何实现,但是把它委托给绑定使用的策略语言(如WS-Policy)。比如,在WS-Policy作为策略语言使用的地方,匹配过程在策略集合里的每一个域上查看,寻找1个或多个服务和引用之间共有的策略。如果只找到一个匹配,那个策略将使用。如果找到多个匹配,那么SCA运行时可以选择使用它们之中的任何一个。没有匹配意味着那个连线不能被使用,将出现错误。
1.3 框架模型(Framework Model)
SCA策略框架模型由intents和policySets组成。intents表示抽象的声明,PolicySets包含具体的策略,这些策略可以被应用于SCA绑定和实现。这个框架描述了intents如何与policySets相关联的。同时也描述了intents和policySets如何被使用来表达一个约束,这个约束管理SCA绑定和实现的行为。Intents和policySets可以用来制定服务和引用的QoS需求。
下面的章节描述此框架模型并说明如何使用交互策略。实现策略紧跟着这一基本模型,在1.5部分讨论。
1.3.1 意图(Intents)
如在前面讨论的一样,意图是一个关于特定QoS特征的抽象声明,这个特征独立于任何一个特殊的实现技术。一个意图用来描述一个SCA结构期望的运行时特征。典型地,意图由一个策略管理员定义。参见【Policy Administrator】获得SCA规则中关于策略概念以及它们的定义和使用的更详细描述。意图的语义不可能总是标准地可用,但可以使用可用的且可访问的文档表达。
比如,一个叫做integrity的意图可能被指定来表示:通信应该被保护来防止篡改。这个指定的意图可能被声明作为一些SCA部件(比如一个引用)的一个需求。注意,这个意图可以通过多种绑定以及多种绑定配置来满足。这样,此引用(把这个意图当作一个需求)最终使用一个web service绑定(HTTP上的SOAP)或一个EJB绑定(通过RMI/IIOP通信的EJB)被连接。
意图可以用来表达交互策略或实现策略的需求。上面例子里的integrity意图用来表达一个交互策略。交互策略是典型地应用于一个服务或引用的意图。它们管理一个客户机和一个服务提供者之间的通信。意图可以像实现策略一样应用于SCA组件实现。这些意图指定了服务的性质,当容器运行组件的时候,服务应该由此容器提供。这种意图的一个例子可以是这样的一个需求:组件必须运行在一个事务里。
意图可以使用下面的pseudo-schema定义:
<intent name="NCName"
constrains="listOfQNames"
requires="listOfQNames"? >
<description>
<!-- description of the intent -->
</description>
</intent>
为了方便和简明,经常期望声明一个简单的,高层次的意图来表示一个需求,这个需求可以由低层次的意图之一满足。比如,confidentiality意图需要消息层的加密或传输层的加密。这些都是抽象的意图,因为这两种加密必要的配置表示在不同绑定中是不同的,且每一个都要求附加的配置参数。
|