The capture and expression of non-functional
requirements is an important aspect of service
definition and has an impact on SCA throughout
the lifecycle of components and compositions. SCA provides a framework to support
specification of constraints, capabilities and QoS expectations from component design
through to concrete deployment. This specification describes the framework and its
usage.
Specifically, this section describes the SCA
policy association framework that allows policies and policy subjects specified
using WS-Policy [WS-Policy] and
WS-PolicyAttachment [WS-PolicyAttach], as well
as with other policy languages, to be associated with SCA components.
This document should be read in conjunction
with the SCA Assembly Specification [SCA-Assembly]. Details of policies for specific policy domains can be found in
sections 7, 8 and 9.
1.1
Terminology
The key words “MUST”, “MUST NOT”,
“REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”,
“MAY”, and “OPTIONAL” in this document are to be interpreted as
described in [RFC2119].
1.2 XML
Namespaces
|
Prefixes and Namespaces used in this Specification |
|
|
Prefix |
XML Namespace |
Specification |
|
sca
|
docs.oasis-open.org/ns/opencsa/sca/200712
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] |
1.3 Normative References
[RFC2119]
S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC
2119, March 1997.
[SCA]
Service Component Architecture (SCA)
http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications
[SCA-Assembly]
Service Component Architecture Assembly Model
Specification
http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications
[WSDL]
Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language –
Appendix http://www.w3.org/TR/2006/CR-wsdl20-20060327/
[WSDL-Ids]
SCA WSDL 1.1
Element Identifiers – forthcoming W3C Note
http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/wsdl11elementidentifiers.html
[WS-Policy]
Web Services Policy
(WS-Policy)
http://www.w3.org/TR/ws-policy
[WS-PolicyAttach] Web Services Policy
Attachment (WS-PolicyAttachment)
http://www.w3.org/TR/ws-policy-attachment
[XML-Schema2] XML
Schema Part 2: Datatypes Second Edition XML Schema Part 2: Datatypes Second Edition, Oct.
28 2004.
http://www.w3.org/TR/xmlschema-2/
2.1
Policies and PolicySets
The term Policy is used to
describe some capability or constraint that can be applied to service 21 components or to
the interactions between service components represented by services and references. An
example of a policy is that messages exchanged between a service client and a service
provider be encrypted, so that the exchange is confidential and cannot be read by someone
who intercepts the conversation.
In SCA, services and references can have
policies applied to them that affect the form of the interaction that takes place at
runtime. These are called interaction policies.
Service components can also have other
policies applied to them which affect how the components themselves behave within their
runtime container. These are called implementation policies.
How particular policies are provided varies
depending on the type of runtime container for
implementation policies and on the binding
type for interaction policies. Some policies may be provided as an inherent part of the
container or of the binding – for example a binding using the https protocol will
always provide encryption of the messages flowing between a reference and a service.
Other policies may be provided by a container or by a binding. It is also possible that
some kinds of container or kinds of binding may be incapable of providing a particular
policy at all. In SCA, policies are held in policySets, which may contain
one or many policies, expressed in some concrete form, such as WS-Policy assertions. Each
policySet targets a specific binding type or a specific implementation type.
PolicySets are used to apply particular
policies to a component or to the binding of a service or reference, through
configuration information attached to a component or attached to a
composite.
For example, a service can have a policy
applied that requires all interactions (messages) with the service to be encrypted. A
reference which is wired to that service must be able to support sending and receiving
messages using the specified encryption technology if it is going to use the service
successfully.
In summary, a service presents a set of
interaction policies which it requires the references to use. In turn, each reference has
a set of policies which define how it is capable of interacting with any service to which
it is wired. An implementation or component can describe its requirements through a set
of attached implementation policies.
2.2
Intents describe the requirements of Components, Services and References
SCA intents are used to describe
the abstract policy requirements of a component or the
requirements of interactions between
components represented by services and references. Intents provide a means for the
developer and the assembler to state these requirements in a high-level abstract form,
independent of the detailed configuration of the runtime and bindings which is the role
of application deployer. Intents support the late binding of services and references to
particular SCA bindings, since they assist the deployer in choosing appropriate bindings
and concrete policies which satisfy the abstract requirements expressed by the
intents.
It is possible in SCA to directly attach
policies to a service, to a reference or to a component at any time during the creation
of an assembly, through the configuration of bindings and the attachment of policy sets.
Attachment may be done by the developer of a component at the time when the component is
written or later at deployment time. SCA recommends a late binding model where the
bindings and the concrete policies for a particular assembly are decided at deployment
time. SCA favors the late binding approach since it promotes re-use of components. It
allows the use of components in new application contexts which may require the use of
different bindings and different concrete policies. Forcing early decisions on which
bindings and policies to use is likely to limit re-use and limit the ability to use a
component in a new context.
For example, in the case of authentication, a
service which requires its messages to be authenticated can be marked with an intent
"authentication". This intent marks the service as requiring message
authentication capability without being prescriptive about how it is achieved. At
deployment time, when the binding is chosen for the service (say SOAP over HTTP), the
deployer can apply suitable policies to the service which provide aspects of WS-Security
and which supply a group of one or more authentication technologies.
In many ways, intents can be seen as
restricting choices at deployment time. If a service is marked with the
confidentiality intent, then the deployer must use a policySet that provides for
the encryption of the messages.
The set of intents available to developers and
assemblers can be extended arbitrarily by policy administrators. The SCA Policy Framework
specification does define a set of intents which address the infrastructure capabilities
relating to security reliable messaging.
2.3
Determining which policies apply to a particular wire
In order for a reference to connect to a
particular service, the policies of the reference must
intersect with the policies of the
service.
Multiple policies may be attached to both
services and to references. Where there are multiple policies, they may be organized into
policy domains, where each domain deals with some particular aspect of the interaction.
An example of a policy domain is confidentiality, which covers the encryption of messages
sent between a reference and a service. Each policy domain may have one or more policy.
Where multiple policies are present for a particular domain, they represent alternative
ways of meeting the requirements for that domain. For example, in the case of
message
integrity, there could be a set of policies,
where each one deals with a particular security token to be used: X509, SAML, Kerberos.
Any one of the tokens may be used - they will all ensure that the overall goal of message
integrity is achieved.
In order for a service to be accessed by a
wide range of clients, it is good practice for the service to support multiple
alternative policies within a particular domain. So, if a service requires message
confidentiality, instead of insisting on one specific encryption technology, the service
can have a policySet which has a host of alternative encryption technologies, any of
which are acceptable to the service. Equally, a reference can have a policySet attached
which defines the range of encryption technologies which it is capable of using.
Typically, the set of policies used for a given domain will reflect the capabilities of
the binding and of the runtime being used for the service and for the
reference.
When a service and a reference are wired
together, the policies declared by the policySets at each end of the wire are matched to
each other. SCA does not define how policy matching is done, but instead delegates this
to the policy language (e.g. WS-Policy) used for the binding. For example, where
WS-Policy is used as the policy language, the matching procedure looks at each domain in
turn within the policy sets and looks for 1 or more policies which are in common between
the service and the reference. When only one match is found, the matching policy is used.
Where multiple matches are found, then the SCA runtime can choose to use any one of the
matching policies. No match implies that the wire cannot be used - it is an
error.
The SCA Policy Framework model is comprised of
intents and policySets. Intents represent abstract assertions
and Policy Sets contain concrete policies that may be applied to SCA bindings and
implementations. The framework describes how intents are related to PolicySets. It also
describes how intents and policySets are utilized to express the constraints that govern
the behavior of SCA bindings and implementations. Both intents and policySets may be used
to specify QoS requirements on services and references.
The following section describes the Framework
Model and illustrates it using Interaction Policies. Implementation Policies follow
the same basic model and are discussed later in section 1.5.
3.1
Intents
As discussed earlier, an intent
is an abstract assertion about a specific Quality of Service (QoS) characteristic that is
expressed independently of any particular implementation technology. An intent is thus
used to describe the desired runtime characteristics of an SCA construct. Intents are
typically defined by a policy administrator. See section [Policy Administrator] for a more detailed description of the SCA roles with respect to Policy concepts,
their definition and their use. The semantics of an intent may not be always available
normatively, but could be expressed with documentation that is available and
accessible.
For example, an intent named integrity
may be specified to signify that communications should be protected from possible
tampering. This specific intent may be declared as a requirement by some SCA artifacts,
i.e. a reference. Note that this intent can be satisfied by a variety of bindings and
with many different ways of configuring those bindings. Thus, the reference where the
intent is expressed as a requirement could eventually be wired
using either a web service binding (SOAP over HTTP) or with an EJB binding that
communicates with an EJB via RMI/IIOP.
Intents can be used to express requirements
for interaction policies or implementation policies.
The integrity intent in the above example is used to express an interaction
policy. Interaction policies are intents that are typically applied to a service
or reference. They are meant to govern the communication between a client and a
service provider. Intents may be applied to SCA component implementations as
implementation policies. These intents specify the qualities of service
that should be provided by a container as it runs the component. An example of such an
intent could be a requirement that the component must run in a transaction.
An intent is defined using the following
pseudo-schema:
<intent name="NCName"
constrains="listOfQNames" requires="listOfQNames"? >
<description>
<!-- description of the intent
-->
</description>
</intent>
Where:
· @name attribute defines the name of the intent
· @constrains attribute (optional) specifies the SCA constructs (SCA binding
or
implementation) that this intent is meant to
configure. If a value is not specified, it is
assumed that this intent is a
qualified intent and inherits its constraint list from the qualifiable intent it is
qualifying (see below). This attribute does not define the valid attach points of the
intent.
Note that the “constrains”
attribute may name an abstract element type, such as sca:binding in our running example.
This means that it will match against any binding used within a SCDL file. A SCDL element
may match @constrains if its type is in a substitution group.
· @requires attribute (optional) defines the set of all intents that the referring
intent requires. In essence, the referring intent requires all the intents named to
be satisfied. This attribute is used to compose an intent from a set of other intents.
This use is further described in Section 3.2 below.
The confidentiality intent may be
defined as:
<intent name="confidentiality"
constrains="sca:binding">
<description>
Communication through this binding must
prevent
unauthorized users from reading the
messages.
</description>
</intent>
For convenience and conciseness, it is often
desirable to declare a single, higher-level intent to denote a requirement that could be
satisfied by one of a number of lower-level intents. For example, the
confidentiality intent requires either message-level encryption or transport-level
encryption.
Both of these are abstract intents because the
representation of the configuration necessary to realize these two kinds of encryption
could vary from binding to binding, and each would also require additional parameters for
configuration.
An intent that can be completely satisfied by
one of a choice of lower-level intents is referred to as a qualifiable intent. In
order to express such intents, an intent name may contain a qualifier, “.”.
An intent that includes the name of a qualifiable intent in its name is referred to as a
qualified intent,
because it is “qualifying” how the
qualifiable intent is satisfied. A qualified intent can only qualify one qualifiable
intent, so the name of the qualified intent includes the name of the qualifiable intent
as a prefix (separated by “.”), for example, authentication.message.
See Usage of @requires attribute
for specifying intents.
In general, SCA allows the developer or
assembler to attach multiple qualifiers for a single
qualifiable intent to the same SCA construct.
However, domain-specific constraints may prevent the use of some combinations of
qualifiers (from the same qualifiable intent). Because qualified intents include the name
of the qualifiable intent, the qualifiable intent definition does not need to list its
valid qualifiers. The set of all qualified intents defined for that qualifiable intent
determines the list of valid qualifiers. This is illustrated by adding two additional
intents to our example called confidentiality.transport and
confidentiality.message. Note that the original intent definition or
confidentiality does not change.
Further, the @constrains attribute of a qualified intent is
unnecessary because qualified intents inherit the @constrains attribute from the
qualifiable intent. It is an error to specify @constrains in the definition of a
qualified intent. The following are definitions of the transport and message
qualifiers of the confidentiality
intent.
<intent
name=”confidentiality.transport” />
<intent
name=”confidentiality.message” />
All the intents in a SCA Domain are defined in
a global, domain-wide file named definitions.xml. Details of this file are
described in the SCA Assembly Model [SCA-Assembly].
SCA normatively defines a set of core intents
that all SCA implementations are expected to support, to ensure a minimum level of
portability. Users of SCA may define new intents, or extend the qualifier set of existing
intents.
3.2
Profile Intents
An intent that is satisfied only by satisfying
all of a set of other intents is called a profile intent. It can be used in
the same way as any other intent.
The presence of @requires attribute in the
intent definition signifies that this is a profile intent. The @requires attribute may
include all kinds of intents, including qualified intents and other profile
Intents. However, while a profile intent can include qualified intents, it cannot
BE a qualified intent (so its name must not have “.” in it).
Requiring a profile intent is always
semantically identical to requiring the list of intents that are listed in its @requires
attribute.
An example of a profile intent could be an
intent called messageProtection which is a shortcut for specifying both
confidentiality and integrity, where integrity means to protect
against modification, usually by signing. The intent definition may look like the
following:
<intent
name="messageProtection"
constrains="sca:binding"
requires="confidentiality integrity">
<description>
Protect messages from unauthorized reading or
modification.
</description>
</intent>
3.3
PolicySets
A policySet element is used to
define a set of concrete policies that apply to some binding type or implementation type,
and which correspond to a set of intents provided by the policySet.The structure of the
PolicySet element is as follows:
· The
@name attribute declares a name for the policySet. The value of the @name attribute is a
xs:QName.
· The
@appliesTo attribute is used to determine which SCA constructs this policySet can
configure. The contents of the attribute must match the XPath 1.0 production
Expr.
· The
@provides attribute, whose value is a list of intent names (that may or may not be
qualified), designates the intents the PolicySet provides. Members of the list are
xs:string values separated by a space character “ “.
It contains one or more of the following
element children
· intentMap element
· policySetReference element
· wsp:PolicyAttachment element
· wsp:Policy element
· wsp:PolicyReference element
· xs:any extensibility element
Any mix of the above types of elements, in any
number, can be included as children of the policySet element including extensibility
elements. There are likely to be many different policy languages for specific binding
technologies and domains. In order to allow the inclusion of any policy language within a
policySet, the extensibility elements may be from any namespace and may be
intermixed. However, the SCA policy framework expects that WS-Policy will be a
common policy language for expressing interaction policies, especially for Web Service
bindings. For this reason, wsp:PolicyAttachment is explicitly included in the schema for
clarity.
The pseudo schema for policySet is shown
below:
<policySet
name="NCName"
provides="listOfQNames"
appliesTo="xs:string"
xmlns=http://www.osoa.org/xmlns/sca/1.0
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<policySetReference name="xs:QName"/>*
<intentMap/>*
<wsp:PolicyAttachment>*
<wsp:Policy>*
<wsp:PolicyReference>*
<xs:any>*
</policySet>
For example, the policySet element below
declares that it provides authentication.message and reliability for the
“binding.ws” SCA binding.
<policySet
name="SecureReliablePolicy"
provides="authentication.message exactlyOne"
appliesTo="sca:binding.ws"
xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsp:PolicyAttachment>
<!-- policy expression and policy subject
for
"basic authentication" -->
…
</wsp:PolicyAttachment>
<wsp:PolicyAttachment>
<!-- policy expression and policy subject for
"reliability" -->
…
</wsp:PolicyAttachment>
</policySet>
PolicySet authors should be aware of the
evaluation of the @appliesTo attribute in order to designate meaningful values for this
attribute. Although policySets may be attached to any element in the SCA design, the
applicability of a policySet is not scoped by where it is attached in the SCA
framework. Rather, policySets always apply to either binding instances or
implementation elements regardless of where they are attached to. In this regard, the SCA
policy framework does not scope the applicability of the policySet to a specific
attachment point in contrast to other frameworks, such as WS-Policy. Attachment is a
shorthand.
With this design principle in mind, an XPath
expression that is the value of an @appliesTo attribute designates what a policySet
applies to. Note that the XPath expression will always be evaluated within the context of
an attachment considering elements where binding instances or implementations are allowed
to be present. The expression is evaluated against the parent element of any binding
or implementation element. The policySet will apply to any child binding or
implementation elements returned from the expression. So, for example,
appliesTo=”binding.ws” will match any web service binding. If
appliesTo=”binding.ws[@impl=’axis’]” then the policySet would
apply only to web service bindings that have an @impl attribute with a value of
‘axis’.
For further discussion on attachment of
policySets and the computation of applicable policySets, please refer to Section
4.
All the policySets in a SCA Domain are defined
in a global, domain-wide file named definitions.xml. Details of this file are
described in the SCA Assembly Model [SCA-Assembly].
SCA may normatively define a set of core
policySets that all SCA implementations are expected to support, to ensure a minimum
level of portability. Users of SCA may define new policySets as needed.
3.3.1
IntentMaps
Intent maps contain the concrete policies and
policy subjects that are used to realize a specific intent that is provided by the
policySet.
The pseudo-schema for intentMaps is given
below:
<intentMap
provides="xs:QName"
default="xs:string">
<qualifier
name="xs:string">?
<wsp:PolicyAttachment>*
…
</wsp:PolicyAttachment>
<xs:any>*
<intentMap/> ?
</qualifier>
</intentMap>
When a policySet element contains a set of
intentMap elements, the value of the @provides attribute of each intentMap corresponds to
an unqualified intent that is listed within the @provides attribute value of the parent
policySet element.
If a policySet specifies a qualifiable intent
in the @provides attribute, then it MUST include an intentMap element that specifies all
possible qualifiers for that intent. If a qualified intent can be further qualified, then
the qualifier element must also contain an intentMap.
For each intent (qualified or unqualified)
listed as a member of the @provides attribute list of a policySet element, there may be
at most one corresponding intentMap element that declares the unqualified form of that
intent in its @provides attribute. In other words, each intentMap within a given
policySet must uniquely provide for a specific intent.
The @provides attribute value of each
intentMap that is an immediate child of a policySet must be included in the @provides
attribute of the parent policySet.
An intentMap element must contain qualifier
element children. Each qualifier element corresponds to a qualified intent where the
unqualified form of that intent is the value of the @provides attribute value of the
parent intentMap. The qualified intent is either included explicitly in the value of the
enclosing policySet’s @provides attribute or implicitly by that @provides attribute
including the unqualified form of the intent.
A qualifier element designates a set of
concrete policy attachments that correspond to a qualified intent. The concrete policy
attachments may be specified using wsp:PolicyAttachment element children or using
extensibility elements specific to an environment.
The default attribute of an intentMap must
correspond to a qualified intent that is named on one of the child qualifier elements.
This is used when the unqualified form of the intent has been specified as a requirement.
The relationship between intents and policySets, and their use within SCDL is explained
in more detail in section 1.5.
As an example, the policySet element below
declares that it provides confidentiality using the @provides attribute. The
alternatives (transport and message) it contains each specify the policy and policy
subject they provide. The default is “transport”.
<policySet
name="SecureMessagingPolicies"
provides="confidentiality"
appliesTo="binding.ws"
xmlns="http://www.osoa.org/xmlns/sca/1.0"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<intentMap
provides="confidentiality" default="transport">
<qualifier
name="transport">
<wsp:PolicyAttachment>
<!-- policy expression and policy subject
for
"transport" alternative -->
...
</wsp:PolicyAttachment>
<wsp:PolicyAttachment>
...
</wsp:PolicyAttachment>
</qualifier>
<qualifier
name="message">
<wsp:PolicyAttachment>
<!-- policy expression and policy subject
for
"message" alternative”
-->
...
</wsp:PolicyAttachment>
</qualifier>
</intentMap>
</policySet>
PolicySets can embed policies that are defined
in any policy language. Although WS-Policy is the most common language for expressing
interaction policies, it is possible to use other policy languages. The following is an
example of a policySet that embeds a policy defined in a proprietary language. This
policy provides “authentication” for binding.ws.
<policySet
name="AuthenticationPolicy"
provides="authentication"
appliesTo="binding.ws"
xmlns="http://www.osoa.org/xmlns/sca/1.0">
<e:policyConfiguration xmlns:e=”http://example.com”>
<e:authentication type =
“X509”/>
<e:trustedCAStore type=”JKS”/>
<e:keyStoreFile>Foo.jks</e:keyStoreFile>
<e:keyStorePassword>123</e:keyStorePassword>
</e:authentication>
</e:policyConfiguration>
</policySet>
The following example illustrates an intent
map that defines policies for an intent with more than one level of
qualification.
<policySet
name=”SecurityPolicy” provides=”confidentiality”>
<intentMap
provides=”confidentiality” default=”message”>
<qualifier
name=”message”>
<intentMap
provides=”message” default=”whole”>
<qualifier
name=”body”>
<! --- policy
attachment for body encryption à
</qualifier>
<qualifier
name=”whole”>
<! --- policy
attachment for whole message àencryption
</qualifier>
</intentMap>
</qualifier>
<qualifier name=”transport”>
<! --- policy
attachment for transport encryption à
</qualifier>
</intentMap>
</policySet>
3.3.2
Direct Inclusion of Policies within PolicySets
In cases where there is no need for defaults
or overriding for an intent included in the @provides of a policySet, the policySet
element may contain policies or policy attachment elements directly without the use of
intentMaps or policy set references. There are two ways of including policies directly
within a policySet. Either the policySet contains one or more wsp:policyAttachment
elements directly as children or it contains extension elements (using xs:any) that
contain concrete policies.
When a policySet element directly contains
wsp:policyAttachment children or policies using
extension elements, it is assumed that the set
of policies specified as children satisfy the intents expressed using the @provides
attribute value of the policySet element. The intent names in the @provides attribute of
the policySet may include names of profile intents.
3.3.3
Policy Set References
A policySet may refer to other policySets by
using sca:PolicySetReference element. This provides a recursive inclusion capability for
intentMaps, policy attachments or other specific mappings from different
domains.
When a policySet element contains
policySetReference element children, the @name attribute of a policySetReference element
designates a policySet defined with the same value for its @name attribute. Therefore,
the @name attribute must be a QName.
The @appliesTo attribute of a referenced
policySet must be compatible with that of the policySet referring to it. Compatibility,
in the simplest case, is string equivalence of the binding names.
The @provides attribute of a referenced
policySet must include intent values that are compatible with one of the values of the
@provides attribute of the referencing policySet. A compatible intent either is a value
in the referencing policySet's @provides attribute values or is a qualified value of one
of the intents of the referencing policySet's @provides attribute value.
The usage of a policySetReference element
indicates a copy of the element content children of the policySet that is being referred
is included within the referring policySet. If the result of inclusion results in a
reference to another policySet, the inclusion step is repeated until the contents of a
policySet does not contain any references to other policySets.
Note that, since the attributes of a
referenced policySet are effectively removed/ignored by this process, it is the
responsibility of the author of the referring policySet to include any necessary intents
in the @provides attribute if the policySet is to correctly advertise its aggregate
capabilities.
The default values when using this aggregate
policySet come from the defaults in the included policySets. A single intent (or all
qualified intents that comprise an intent) in a referencing policySet must only be
included once by using references to other policySets.
Here is an example to illustrate the inclusion
of two other policySets in a policySet element:
<policySet
name="BasicAuthMsgProtSecurity"
provides="authentication confidentiality"
appliesTo="binding.ws"
xmlns="http://www.osoa.org/xmlns/sca/1.0">
<policySetReference name="acme:AuthenticationPolicies"/>
<policySetReference name="acme:ConfidentialityPolicies"/>
</policySet>
The above policySet refers to policySets for
authentication and confidentiality and, by reference, provides policies and
policy subject alternatives in these domains.
If the policySets referred to have the
following content:
<policySet
name="AuthenticationPolicies"
provides="authentication"
appliesTo="binding.ws"
xmlns="http://www.osoa.org/xmlns/sca/1.0">
<wsp:PolicyAttachment>
<!-- policy expression and policy subject
for "basic
authentication" -->
…
</wsp:PolicyAttachment>
</policySet>
<policySet
name="acme:ConfidentialityPolicies"
provides="confidentiality"
bindings="binding.ws"
xmlns="http://www.osoa.org/xmlns/sca/1.0">
<intentMap
provides="confidentiality" default="transport">
<qualifier
name="transport">
<wsp:PolicyAttachment>
<!-- policy expression and policy subject
for "transport"
alternative -->
...
</wsp:PolicyAttachment>
<wsp:PolicyAttachment>
...
</wsp:PolicyAttachment>
</qualifier>
<qualifier name="message">
<wsp:PolicyAttachment>
<!-- policy expression and policy subject
for "message"
alternative” -->
...
</wsp:PolicyAttachment>
</qualifier>
</intentMap>
</policySet>
The result of the inclusion of policySets via
policySetReferences would be semantically equivalent to the following:
<policySet
name="BasicAuthMsgProtSecurity"
provides="authentication confidentiality" appliesTo="binding.ws"
xmlns="http://www.osoa.org/xmlns/sca/1.0">
<wsp:PolicyAttachment>
<!-- policy expression and policy subject
for "basic authentication" -->
...
</wsp:PolicyAttachment>
<intentMap
provides="confidentiality" default="transport">
<qualifier name="transport">
<wsp:PolicyAttachment>
<!-- policy expression and policy subject
for "transport"
alternative -->
...
</wsp:PolicyAttachment>
<wsp:PolicyAttachment>
...
</wsp:PolicyAttachment>
</qualifier>
<qualifier name="message">
<wsp:PolicyAttachment>
<!-- policy expression and policy subject
for "message"
alternative -->
...
</wsp:PolicyAttachment>
</qualifier>
</intentMap>
</policySet>
4 Attaching Intents and PolicySets to SCA
Constructs
This section describes how intents and
policySets are associated with SCA constructs. It describes the various attachment points
and semantics for
