1 Introduction

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 Overview

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.

3 Framework Model

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>

</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:

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.

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">

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">

<wsp:PolicyAttachment>

<!-- policy expression and policy subject for

"transport" alternative -->

...

</wsp:PolicyAttachment>

<wsp:PolicyAttachment>

...

</wsp:PolicyAttachment>

</qualifier>

<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.

<! --- policy attachment for body encryption à

</qualifier>

<! --- policy attachment for whole message àencryption

</qualifier>

</intentMap>

</qualifier>

<! --- 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">

</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">

<wsp:PolicyAttachment>

<!-- policy expression and policy subject for "transport"

alternative -->

...

</wsp:PolicyAttachment>

<wsp:PolicyAttachment>

...

</wsp:PolicyAttachment>

</qualifier>

<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>

...

</wsp:PolicyAttachment>

<wsp:PolicyAttachment>

<!-- policy expression and policy subject for "transport"

alternative -->

...

</wsp:PolicyAttachment>

<wsp:PolicyAttachment>

...

</wsp:PolicyAttachment>

</qualifier>

<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 intents and policySets and their relationship to other SCA elements and how intents relate to policySets in these contexts.

4.1 Attachment Rules

Intents can be attached to any SCA element used in the definition of components and composites since an intent specifies an abstract requirement. The attachment is specified by using the optional @requires attribute. This attribute takes as its value a list of intent names. Intents can optionally be applied to interface definitions. For WSDL Port Type elements (WSDL 1.1) and for WSDL Interface elements (WSDL 2.0), the @requires attribute can be applied that holds a list of intent names that are required for the interface. Other interface languages may define their own mechanism for specifying a list of required intents. Any service or reference that uses an interface with required intents implicitly adds those intents to its own @requires list.

Because intents specified on interfaces can be seen by both the provider and the client of a service, it is appropriate to use them to specify characteristics of the service that both the developers of provider and the client need to know. For example, the fact that an interface is conversational is such a characteristic, since both the client and the service provider need to know about the conversational semantics.

For example:

<service> or <reference>…

<binding.binding-type requires="listOfQNames"

</binding.binding-type>…

</service> or </reference>

Similarly, one or more policySets can be attached to any SCA element used in the definition of components and composites. The attachment is specified by using the optional @policySets attribute. This attribute takes as its value a list of policySet names.

For example:

<service> or <reference>…

<binding.binding-type policySets="listOfQNames"

</binding.binding-type>…

</service> or </reference>

The SCA Policy framework enables two distinct cases for utilizing intents and PolicySets:

· It is possible to specify QoS requirements by specifying abstract intents utilizing the @requires element on an element at the time of development. In this case, it is implied that the concrete bindings and policies that satisfy the abstract intents will not be assigned at development time but the intents will be used to select the concrete Bindings andPolicies at deployment time. Concrete policies are encapsulated within policySets that will be available in a deployment environment. The intents associated with a SCA element is the union of intents specified for it and its parent elements subject to the detailed rules below.

· It is also possible to specify QoS requirements for an element by using both intents and concrete policies contained in policySets at development time. In this case, it is possible to configure the policySets, by overriding the default settings in the specified policySets using intents. The policySets associated with a SCA element is the union of policySets specified for it and its parent elements subject to the detailed rules below.

When computing the policySets that apply to a particular element, the @appliesTo attribute of each relevant policySet is checked against the element. If the policySet is attached directly to the element and does not apply to that element an error is raised. If a policySet that is attached to an ancestor element does not apply to the element in question, it is simply discarded.

These two different approaches of specifying policies will be illustrated in detail below. We also discuss how intents are used to guide the selection and application of specific policySets.

4.2 Usage of @requires attribute for specifying intents

As indicated, a list of intents can be specified for any SCA element by using the optional @requires attribute.

Stating intents with the @requires attribute of an element means that those intents are additionally required by every relevant element descendent. For example, specifying

requires=”confidentiality” on a <composite> element is the equivalent to adding the same intent to the @requires list of every service and reference that is contained within that composite, including the services and references inside components. Therefore, the computed intents that apply to a specific element is the union of all intents that are present in the @requires attribute values of its ancestors that apply to the specific type of element. This is equivalent to listing an intent in the @requires list of all of descendent elements that match one of the xs:QName values of the @constrains attribute of an intent, taking into account the presence of substitution groups.

When computing the intents that apply to a particular element, the @constrains attribute of each relevant intent is checked against the element. If the intent in question does not apply to that element it is simply discarded.

When intents are specified with @requires attribute values of an element during development and no policySets are attached to this element, the computed intents for the element are used to select appropriate policySets during deployment. The intents specified for an element are also used to determine a specific mapping/choice other than the default, should the selected policySet contain intentMaps. The developer in this case is not choosing policySets that apply as they will be determined, if possible, during a later deployment step.

Both qualified intents and their respective qualifiable intents, and profile intents, can be specified as values of a @requires attribute. In considering the set of intents that are computed for a specific element, however, the following rules must be observed.

· When the computed values of a @requires attribute includes both the qualified and unqualified form of a qualifiable intent, the unqualified form is ignored. For example, assume that the confidentiality intent uses confidentiality.transport as its default when specified as part of a PolicySet.

Consider the following composite:

<reference name="bar"

requires="confidentiality.message"/>

</composite>

In this case, the composite has declared that all of its services and references must guarantee confidentiality in their communication, but the “bar” reference would further qualify that requirement to specifically require message-level security. When the intent is matched with the appropriate policySet (by the assembler or deployer) to generate concrete policies that satisfies the intents, the “foo” service element will use the default qualifier specified by the PolicySet that is used at deployment time while the “bar” reference will use the confidentiality.message intent.

During policySet selection, it is only possible to override a qualifiable intent that doesn’t specify a qualifier. Thus, multiple qualifiers MUST NOT be specified for the same qualifiable intent as part of a computed intent set.

Consider this variation where a qualified intent is specified at the composite level:

<reference name="bar"

requires="confidentiality.message"/>

</composite>

In this case, both the confidentiality.transport and the confidentiality.message intent are required for the reference ‘bar’. If there are no bindings that support this combination, an error will be generated. However, since in some cases multiple qualifiers for the same intent may be valid or there may be bindings that support such combinations, the SCA specification allows this.

· If a component type includes a list of required intents on a service or reference, it is not possible for a component that uses that component type to remove any of those required intents. However, if any of the intents are qualifiable intents, the component MAY specify a qualifier for that intent.

It is also possible for a qualified intent to be further qualified. In our example, the

615 confidentiality.message intent may be further qualified to indicate whether just the body of a message is protected, or the whole message (including headers) is protected. So, the second-level qualifiers might be “body” and “whole”. The default qualifier might be “whole”. If the “bar” reference from the example above wanted only body confidentiality, it would state:

<reference name="bar"

requires="acme:confidentiality.message.body"/>

The definition of the second level of qualification for an intent follows the same rules. As with other qualified intents, the name of the intent is constructed using the name of the qualifiable intent, the delimiter “.”, and the name of the qualifier.

4.3 Usage of @requires and @policySet attributes together

As indicated above, it is possible to attach both intents and policySets to an SCA element during development. The most common use cases for attaching both intents and concrete policySets to an element are with binding and reference elements.

When the @requires attribute and the @policySets attributes are used together during development, it indicates the intention of the developer to configure the element, such as a binding, by the application of specific policySet(s) that are in scope for this element.

Developers using @requires and @policySet attributes in conjunction with each other must be aware of the implications of how the policySets are selected and how the intents are utilized to select specific intentMaps, override defaults, etc. The details are provided in the Section Guided Selection of PolicySets using Intents. The same algorithm applies whether the intents guide the selection of policySets during deployment or whether a developer uses intents to choose the best alternative in a set of policySets that may apply by configuring policySets.

4.4 Operation-Level Intents and PolicySets on Services & References

It is possible to specify intents and policySets for a single service or reference operation in a way that applies to all the bindings of a service or reference. In this case, the syntax is to specify the operation directly under the <sca:service> or <sca:reference> element. The following example illustrates the placement of the <sca:operation> element:

<operation name = "xs:string"

policySet="xs:QName"? requires="="listOfQNames"? />

</service> or </reference>

4.5 Operation-Level Intents and PolicySets on Bindings

The above mechanism for specifying operation-specific required intents and policySets may also be applied to bindings. In this case, the syntax would be:

<binding.binding-type

requires="list of intent QNames" policySets="listOfQNames">

<operation name = "xs:string" policySets="xs:QName" ?

requires="listOfQNames"? />*

</binding.binding-type>

</service> or </reference>

This makes it possible to specify required intents that are specific to one operation for a single binding. Similar to operations on implementations, the intents required for the operation are added to the effective list of required intents on the binding, and operation-level policySets override corresponding policySets specified for the binding (where a “corresponding” policySet @provides at least one common intent).

4.6 Intents and PolicySets on Implementations and Component Types

It is possible to specify required intents and policySets for a component’s implementation, which get exposed to SCA through the corresponding component type. How the intents or policies are specified within an implementation depends on the implementation technology. For example, Java can use the @requires annotation to specify intents.

The required intents and policySets specified within an implementation can be found on the

<sca:implementation.*> and the various <sca:service> and <sca:reference> elements of the component type, for example:

<implementation.* requires="listOfQNames"

policySets="="listOfQNames">

...

</implementation>

<service name="myService" requires="listOfQNames"

policySets="listOfQNames">

...

</service>

<reference name="myReference" requires="listOfQNames"

policySets="="listOfQNames">

...

</reference>

…

</componentType>

When applying policies, the intents required by the component type are added to the intents

required by the using component. For the explicitly listed policySets, the list in the component may override policySets from the component type. More precisely, a policySet on the componentType is considered to be overridden, and is not used, if it has a @provides list that includes an intent that is also listed in any component policySet @provides list.

4.7 BindingTypes and Related Intents

SCA Binding types implement particular communication mechanisms for connecting components together. See detailed discussion in the SCA Assembly specification [SCA-Assembly]. Some binding types may realize intents inherently by virtue of the kind of protocol technology they implement (e.g. an SSL binding would natively support confidentiality). For these kinds of binding types, it may be the case that using that binding type, without any additional configuration, will provide a concrete realization of a required intent. In addition, binding instances which are created by configuring a bindingType may be able to provide some intents by virtue of its configuration. It is important to know, when selecting a binding to satisfy a set of intents, just what the binding types themselves can provide and what they can be configured to provide.

The bindingType element is used to declare a class of binding available in a SCA Domain. It declares the QName of the binding type, and the set of intents that are natively provided using the optional @alwaysProvides attribute. The intents listed by this attribute are always concretely realized by use of the given binding type. The binding type also declares the intents that it may provide by using the optional @mayProvide attribute. Intents listed as the value of this attribute can be provided by a binding instance configured from this binding type.

The pseudo-schema for the bindingType element is as follows:

<bindingType type="NCName"

alwaysProvides="listOfQNames"? mayProvide="listOfQNames"?/>

The kind of intents a given binding might be capable of providing, beyond these inherent intents, are implied by the presence of policySets that declare the given binding in their @appliesTo attribute. An exception is binding.sca which is configured entirely by the intents listed in its @mayProvide and @alwaysProvides lists. There are no policySets with appliesTo="binding.sca".

For example, if the following policySet is available in a SCA Domain it says that the sca:binding.ssl can provide “reliability” in addition to any other intents it may provide inherently.

<policySet name="ReliableSSL" provides="exactlyOnce"

appliesTo="binding.ssl">

...

</policySet>

4.8 Treatment of Components with Internal Wiring

This section discusses the steps involved in the development and deployment of a component and its relationship to selection of bindings and policies for wiring services and references.

The SCA developer starts by defining a component. Typically, this will contain services and references. It may also have required intents defined at various locations within composite and component types as well as policySets defined at various locations.

Both for ease of development as well as for deployment, the wiring constraints to relate services and references need to be determined. This is accomplished by matching constraints of the services and references to those of corresponding references and services in other components.

In this process, the required intents, the binding instances, and the policySets that may apply to both sides of a wire play an important role. It must be possible to find binding instances on each side of a wire that are compatible with one another. In addition, concrete policies must be determined that satisfy the required intents for the service and the reference and are also compatible with each other. For services and references that make use of bidirectional interfaces, the same determination of matching bindings and policySets must also take place for the callbackReference and callbackService.

Determining compatibility of wiring plays an important role prior to deployment as well as during the deployment phases of a component. For example, during development, it helps a developer to determine whether it is possible to wire services and references when the bindings and policySets are available in the development environment. During deployment, the wiring constraints determine whether wiring can be achievable. It does also aid in adding additional concrete policies or making adjustments to concrete policies in order to deliver the constraints. Here are the concepts that are needed in making wiring decisions:

· The set of required wiring intents that individually apply to each service or reference.

· When possible the intents that are required by the service, the reference and callback (if any) at the other end of the wire. This set is called the required intent set and is computed and MAY be used only when dealing with a wire connecting two components within the SCA Domain. When external connections are involved, from clients or to services that are outside the SCA domain, intents are only available for the end of the connection that is inside the domain. See Section "Preparing Services and References for External Connection" for more details.

· The binding instances that apply to each side of the wire.

· The policySets that apply to each service or reference.

There may be many binding instances specified for a reference/service. If there are no binding instances specified on a service or a reference, then <sca:binding.sca> is assumed.

The set of provided intents for a binding instance is the union of the intents listed in the

“alwaysProvides” attribute and the “mayProvides” list of of its binding type (although the capabilities represented by the “mayProvides” intents will only be present if the intent is in the list of required intents for the binding instance). When an intent is directly provided by the binding type, there is no need to use policy set that provides that intent.

The policySets that apply to a service or reference are determined by starting with the policySets that are explicitly specified on that service or reference, adding in the policy sets for any ancestor element, and then finding the smallest set of additional policySets that provide the required wiring intents that have not already been satisfied inherently by the binding instances. (Please refer to the Guided Selection of PolicySets using Intents for specifics of how the final set of policySets are determined. Selection of the policySets utilize the required wiring intents that are computed above.)

When bidirectional interfaces are in use, the same selection of binding instances and policySets that provide the required intent are also performed for the callback bindings.

4.8.1 Determining Wire Validity and Configuration

The above approach determines the policySets that should be used in conjunction with the binding instances listed for services and references. For services and references that are resolved using SCA wires, the bindings and policySets chosen on each side of the wire may or may not be compatible. The following approach is used to determine whether they are compatible and the wire is valid. If the wire uses a bidirectional interface, then the following technique must find that valid configured bindings can be found for both directions of the bidirectional interface.

Note that there may be many binding instances present at each side of the wire. The wiring

compatibility algorithm below determines the compatibility of a wire by a pairwise choice of a binding instance and the corresponding policySets on each side of the wire.

A potential binding pair is a pair of binding instances, one on each end of the wire, that have the same binding type. Each binding instance in the pair has a set of policy sets that were determined by the algorithm of the last section. If any potential binding pair has policySets on each end that are incompatible, then that pair of binding instances is removed as an option. The compatibility of policySets is determined by the policy language contained in the policySets. However, there are some special cases worth mentioning:\

· If both sides of the wire use the identical policySet (by referring to the same policySet by its QName in both sides of the wire), then they are compatible.

· If the policySets contain WS-Policy attachments, then the following steps are used to determine their compatibility:

1) The sca:policySet

2) Reference elements within the policySet elements are removed recursively by replacing each reference with an equivalent policy expression encapsulated with sca:policySet element.

3) The policy expressions within each policy set are normalized using WS-Policy normalization rules to obtain a set of alternatives on each side of the wire.

4) The resulting policy alternatives from each side of the wire are pairwise tested for compatibility using the WS-Policy intersection algorithm. WS-Policy’s strict compatibility should be used by default.

5) If the result of the WS-Policy intersection algorithm is non-empty, then the policy sets are considered compatible.

For other policy languages, the policy language defines the comparison semantics. Where such policy languages are standardized by the SCA specifications, the SCA specifications will reference the definition of the comparison semantics or, if no such definition exists, the SCA specifications will provide a definition.

4.9 Preparing Services and References for External Connection

Services and references are sometimes not intended for SCA wiring, but for communication with software that is outside of the SCA domain. References may contain bindings that specify the endpoint address of a service that exists outside of the current SCA domain. Composite services that are deployed to the virtual domain composite specify bindings that can be exposed to clients that are outside of the SCA domain. When web service bindings are used, these services also may generate WSDL with attached policies that can be accessed by external clients (as described in the SCA Web Service Binding specification).

Component services and references that have been promoted to composite services and references may connect to references and services in another SCA Domain or a non-SCA Domain. This section discusses the steps involved in the preparing such a service or reference for external connection.

Essentially, this involves generating a WSDL interface for the service/reference and attaching to it policies that reflect abstract QoS requirements specified using intents and specific requirements using attached policySets. This section will discuss only the generation of policies. Generation of the WSDL interface is discussed in specifications for the various bindings, for example, binding.ws.

Matching service/reference policies across the SCA Domain boundary will use WS-Policy compatibility (strict WS-Policy intersection) if the policies are expressed in WS-Policy syntax. For other policy languages, the policy language defines the comparison semantics. Where such policy languages are standardized by the SCA specifications, the SCA specifications will reference the definition of the comparison semantics or, if no such definition exists, the SCA specifications will provide a definition.

For external services and references that make use of bidirectional interfaces, the same

determination of matching policies must also take place for the callback.

The policies that apply to the service/reference are now computed as discussed in Guided Selection of PolicySets using Intents.

4.10Guided Selection of PolicySets using Intents

This section describes the selection of concrete policies that satisfy a set of required intents

expressed for an element. The purpose of the algorithm is to construct the set of concrete policies that apply to an element taking into account the explicitly declared policySets that may be attached to an element as well as the policySets available in the SCA Domain that are selected to match a required intent.

Note: In the following algorithm, the following rule is observed whenever an intent set is computed.

When a profile intent is encountered in either a @requires or @provides attribute, it is assumed that the profile intent is immediately replaced by the intents that it is composed by, namely by all the intents that appear in the profile intent’s @requires attribute. This rule is applied recursively until profile intents do not appear in an intent set. [This is stated generally, in order to not have to restate this processing step at multiple places in the algorithm].

Algorithm for Matching Intents and PolicySets:

A. Calculate the required intent set that applies to the target element as follows:

1. Start with the list of intents specified in the element's @requires attribute.

2. Add intents found in any related interface definition.

3. Add intents found in the @requires attribute of each ancestor element.

4. If the element is a binding instance and its parent element (service, reference or callback) is wired, the required intents of the other side of the wire may be added to the intent set when they are available. This may simplify, or eliminate, the policy matching step later described in step C.

5. Remove any intents that do not include the target element's type in their @constrains attribute.

6. If the set of intents includes both a qualified version of an intent and an unqualified version of the same intent, remove the unqualified version from the set.

* The required intent set now contains all intents that must be provided for the target element.

B. Remove all directly supported intents from the required intent set. Directly supported intents are:

· For a binding instance, the intents listed in the @alwaysProvides attribute of the binding type definition as well as the intents listed in the binding type’s @mayProvides attribute that are selected when the binding instance is configured.

· For a implementation instance, the intents listed in the @alwaysProvides attribute of the implementation type definition as well as the intents listed in the implementation type’s @mayProvides attribute that are selected when the implementation instance is configured.

* The remaining required intents must be provided by policySets.

C. Calculate the list of explicitly specified policySets that apply to the target element.

In this calculation, a policySet applies to a target element if the XPath expression contained in the policySet’s @appliesTo attribute is evaluated against the parent of the target element and the result of the XPath expression includes the target element. For example,

@appliesTo=”binding.ws[@impl=’axis’]” will match any binding.ws element that has an @impl attribute value of ‘axis’.

The list of explicitly specified policySets is calculated as follows:

1. Start with the list of policySets specified in the element's @policySets attribute.

2. If any of these explicitly listed policySets does not apply to the target element (binding or implementation) then the composite is invalid. The point of this rule is that it must have been a mistake to have explicitly listed a policySet on a binding or implementation element that cannot apply to that element.

3. Include the values of @policySets attributes from ancestor elements.

4. Remove any policySet where the XPath expression in that policySet’s @appliesTo attribute does not match the target element. It is not an error for an element to inherit a policySet from an ancestor element which doesn’t apply.

A policySet matches a required intent if any of the following are true:

1. The required intent matches a provides intent in a policySet exactly.

2. The provides intent is a parent (e.g. prefix) of the required intent (in this case the policySet must have an intentMap entry for the requested qualifier)

3. The provides intent is more qualified than the required intent.

D. Remove all required intents that are provided by the specified policySets.

* The remaining required intents, if any, are provided by finding additional matching policySets within the SCA Domain.

E. Choose the smallest collection of additional policySets that match all remaining required intents.

* All intents should now be satisfied.

F. If no collection of policySets covers all required intents, the configuration is not valid.

G. If there is not one unique smallest collection of policySets that satisfy all required intents, then the composite definition document is not valid. The composite definition must be changed so that either it has enough explicit policySets declared that the ambiguity is removed or additional intents are added to remove the ambiguity.

H. If a required intent is unqualified and matches a policySet that is also unqualified, then the intentMap entry for the qualifier that is marked with default=”true” should be used.

When the configuration is not valid, it means that the required intents are not being correctly satisfied. However, an SCA Domain may allow a deployer to force deployment even in the presence of such errors. The behaviors and options enforced by a deployer is not specified.

5 Implementation Policies

The basic model for Implementation Policies is very similar to the model for interaction policies described above. Abstract QoS requirements, in the form of intents, may be associated with SCA component implementations to indicate implementation policy requirements. These abstract capabilities are mapped to concrete policies via policySets at deployment time. Alternatively, policies can be associated directly with component implementations.

The following example shows how intents can be associated with an implementation:

<implementation.* …

requires="listOfQNames">

…

</implementation>

…

</component>

If, for example, one of the intent names in the value of the @requires attribute is ‘logging’, this indicates that all messages to and from the component must be logged. The technology used to implement the logging is unspecified. Specific technology is selected when the intent is mapped to a policySet (unless the implementation type has native support for the intent, as described in the next section). A list of required implementation intents may also be specified by any ancestor element of the <sca:implementation> element. The effective list of required implementation intents is the union of intents specified on the implementation element and all its ancestors.

In addition, one or more policySets may be specified directly by associating them with the

implementation of a component.

<implementation.*

policySets="="listOfQNames">

…

</implementation>

…

</component>

If any of the explicitly listed policy sets includes an intent map, then the intent map entry used will be the one for the appropriate intent qualifier(s) listed in the effective list of required intents. If no qualifier is specified for an intent map’s qualifiable intent, then the default qualifier is used.

The above example shows how intents and policySets may be specified on a component. It is also possible to specify required intents and policySets within the implementation. How this is done is defined by the implementation type.

The required intents and policy sets are specified on the <sca:implementation.*> element within the component type. This is important because intent and policy set definitions need to be able to specify that they constrain an appropriate implementation type.

<implementation.* requires="listOfQNames" policySets="listOfQNames">

…

</implementation>

…

</componentType>

When applying policies, the intents required by the implementation are added to the intents required by the using component. For the explicitly listed policySets, the list in the component may override policySets from the component type. More precisely, a policySet on the componentType is considered to be overridden, and is not used, if it has a @provides list that includes an intent that is also listed in any component policySet @provides list.

5.1 Natively Supported Intents

Each implementation type (e.g. <sca.implementation.java> or <sca.implementation.bpel>) has an implementation type definition within the SCA Domain. The form of the implementation type definition is as follows:

<implementationType type="NCName"

alwaysProvides="listOfQNames"? mayProvide="listOfQNames"?/>

The @type attribute should specify the QName of an XSD global element definition that will be used for implementation elements with of that type (e.g. sca:implementation.java). There are two lists of intents. The intents in the @mayProvide list are provided only for components that require them (they are present in the effective list of required intents). The intents in the @alwaysProvides list are provided irrespective of the list of required intents.

5.2 Operation-Level Intents and PolicySets on Implementations

It is also possible to declare implementation policies that apply only to specific operations of a service, rather than all of them, by associating intents and policySets with individual operations contained within implementations. The syntax is analogous to that proposed above. See the pseudo-schema below:

<implementation.* policySets="listOfQNames"

requires="list of intent xs:QNames">

…

<operation name="xs:string" service="xs:string"?

policySets="listOfQNames"?

requires="listOfQNames"?/>*

…

</implementation>

…

</component>

As in the pseudo-schema displayed earlier, the intents associated with the operation appear as the value of the optional @requires attribute. PolicySets may also be explicitly associated with the operation by using the optional @policySets attribute. If a policySet that is listed in @policySets provides a qualifiable intent that also is listed in the effective required intent list, then the qualifier is used to override the default qualifier in the policySet.

Operations are identified by names which are xs:string values. The operation names will be names defined by the interface definition language. For example, for Java interfaces they will be Java names. For WSDL, they will be WSDL1.1 identifiers. See[WSDL -IDs] or WSDL 2.0 Component Identifier names See [WSDL]. If more than one service implemented by this implementation has an operation with the same name, then the @service attribute is required in order to disambiguate them. However, if more than one operation within a single service has the same name (i.e. it is overloaded) then the values of the attributes @requires and @policySet are associated with all operations with that name. SCA does not currently provide a means for disambiguating overloaded operations.

The algorithm for mapping of intents to policySets is described in Section Guided Selection of PolicySets using Intents.

5.3 Writing PolicySets for Implementation Policies

The @appliesTo attribute for a policySet takes an XPath expression that is applied to a binding or an implementation element. For implementation policies, in most cases, all that is needed is the QName of the implementation type. Implementation policies may be expressed using any policy language (which is to say, any configuration language). For example, XACML or EJB-style annotations may be used to declare authorization policies. Other capabilities could be configured using completely proprietary configuration formats.

For example, a policySet declared to turn on trace-level logging for some fictional BPEL executions engine would be declared as follows:

<policySet name=”loggingPolicy” provides="acme:logging.trace"

appliesTo="sca:implementation.bpel" …>

<acme:processLogging level="3"/>

</policySet>

PolicySets or intent map entries may include PolicyAttachment elements. A PolicyAttachment element has a child-element called AppliesTo followed by a policy expression. The AppliesTo indicates the subject that the policy applies to. In the SCA case, the policy subject is indicated by where the policySet is attached and so, this will generally be omitted. (This AppliesTo element should not be confused with the @appliesTo attribute for a policySet. They have quite different meanings.)

Following the AppliesTo is a policy expression. In WS-Policy [WS-Policy] this can be a WS-Policy expression or a WS-PolicyReference, For SCA, we need to generalize this to contain policy expressions in other policy languages.

5.3.1 Non WS-Policy Examples

Authorization policies expressed in XACML could be used in the framework in two ways:

1. Embed XACML expressions directly in the PolicyAttachment element using the extensibility elements discussed above, or

2. Define WS-Policy assertions to wrap XACML expressions.

For EJB-style authorization policy, the same approach could be used:

1. Embed EJB-annotations in the PolicyAttachment element using the extensibility elements discussed above, or

2. Use the WS-Policy assertions defined as wrappers for EJB annotations.

6 Roles and Responsibilities

There are 4 roles that are significant for the SCA Policy Framework. The following is a list of the roles and the artifacts that the role creates:

· Policy Administrator – policySet definitions and intent definitions

· Developer – Implementations and component types

· Assembler - Composites

· Deployer – Composites and the SCA Domain (including the logical Domain-level composite)

6.1 Policy Administrator

An intent represents a requirement that a developer or assembler can make, which ultimately must be satisfied at runtime. The full definition of the requirement is the informal text description in the intent definition.

The policy administrator’s job is to both define the intents that are available and to define the policySets that represent the concrete realization of those informal descriptions for some set of binding type or implementation types. See the sections on intent and policySet definitions for the details of those definitions.

6.2 Developer

When it is possible for a component to be written without assuming a specific binding type for its services and references, then the developer uses intents to specify requirements in a binding neutral way.

If the developer requires a specific binding type for a component, then the developer can specify bindings and policySets with the implementation of the component. Those bindings and policySets will be represented in the component type for the implementation (although that component type might be generated from the implementation).

If any of the policySets used for the implementation include intentMaps, then the default choice for the intentMap can be overridden by an assembler or deployer by requiring a qualified intent that is present in the intentMap.

6.3 Assembler

An assembler creates composites. Because composites are implementations, an assembler is like a developer, except that the implementations created by an assembler are composites made up of other components wired together. So, like other developers, the assembler can specify required intents or bindings or policySets on any service or reference of the composite.

However, in addition the definition of composite-level services and references, it is also possible for the assembler to use the policy framework to further configure components within the composite. The assembler may add additional requirements to any component’s services or references or to the component itself (for implementation policies). The assembler may also override the bindings or policySets used for the component. See the assembly specification’s description of overriding rules for details on overriding.

As a shortcut, an assembler can also specify intents and policySets on any element in the composite definition, which has the same effect as specifying those intents and policySets on every applicable binding or implementation below that element (where applicability is determined by the @appliesTo attribute of the policySet definition or the @constrains attribute of the intent definition).

6.4 Deployer

A deployer deploys implementations (typically composites) into the SCA Domain. It is the

deployers job to make the final decisions about all configurable aspects of an implementation that is to be deployed and to make sure that all required intents are satisfied.

If the deployer determines that an implementation is correctly configured as it is, then the

implementation may be deployed directly. However, more typically, the deployer will create a new composite, which contains a component for each implementation to be deployed along with any changes to the bindings or policySets that the deployer desires.

1093 When the deployer is determining whether the existing list of policySets is correct for a component, the deployer needs to consider both the explicitly listed policySets as well as the policySets that will be chosen according to the algorithm specified in Guided Selection of PolicySets using Intents.

7 Security Policy

The SCA Security Model provides SCA developers the flexibility to specify the required level of security protection for their components to satisfy business requirements without the burden of understanding detailed security mechanisms.

The SCA Policy framework distinguishes between two types of policies: interaction policy and implementation policy. Interaction policy governs the communications between clients and service providers and typically applies to Services and References. In the security space, interaction policy is concerned with client and service provider authentication and message protection requirements. Implementation policy governs security constraints on service implementations and typically applies to Components. In the security space, implementation policy concerns include access control, identity delegation, and other security quality of service characteristics that are pertinent to the service implementations.

The SCA security interaction policy can be specified via intents or policySets. Intents represent security quality of service requirements at a high abstraction level, independent from security protocols, while policySets specify concrete policies at a detailed level which are typically security protocol specific.

The SCA security policy can be specified either in the SCDL or annotatively in the implementation code. Language-specific annotations are described in the respective language Client and Implementation specifications.

7.1 SCA Security Intents

The SCA security specification defines the following intents to specify interaction policy:

authentication, confidentiality, and integrity.

authentication – the authentication intent is used to indicate that a client must authenticate itself in order to use an SCA service. Typically, the client security infrastructure is responsible for the server authentication in order to guard against a "man in the middle" attack.

confidentiality – the confidentiality intent is used to indicate that the contents of a message are accessible only to those authorized to have access (typically the service client and the service provider). A common approach is to encrypt the message, although other methods are possible.

integrity – the integrity intent is used to indicate that assurance is required that the contents of a message have not been tampered with and altered between sender and receiver. A common approach is to digitally sign the message, although other methods are possible.

7.2 Interaction Security Policy

Any one of the three security intents may be further qualified to specify more specific business requirements. Two qualifiers are defined by the SCA security specification: transport and message, which can be applied to any of the above three intent’s.

7.2.1 Qualifiers

transport – the transport qualifier specifies the qualified intent should be realized at the transport layer of the communication protocol.

message – the message qualifier specifies that the qualified intent should be realized at the

message level of the communication protocol.

The following example snippet shows the usage of intents and qualified intents.

…

</composite>

In this case, the composite declares that all of its services and references must guarantee

confidentiality in their communication by setting requires="confidentiality". This applies to the "foo" service. However, the “bar” reference further qualifies that requirement to specifically require message-level security by setting requires="confidentiality.message".

7.2.2 Operation Level Intents

Intents may be specified at the operation level. The operation element does not distinguish operations with different arguments. Operation level intents override the service level intents of the same type. For example an operation level “confidentiality.message” intent would override service level “confidentiality” intent, but would not override other types of intents at service level such as “integrity” and “authentication” intents.

Use the following implementation as an example.

public interface HelloService {

String hello(String message);

}

import org.osoa.sca.annotations.*;

@Service(HelloServiceImpl.class)

public class HelloServiceImpl implements HelloService {

public String hello(String message) {

...

}

Consider the following composite document:

<service name="HelloServiceImpl"

requires="authentication integrity.transport confidentiality.transport">

<interface.wsdl interface="…#wsdl.interface(HelloService)"/>

<operation name="hello"

requires="authentication.message integrity.message"/>

<binding.ws/>

</service>

The effective QoS intent’s on the “hello” operation of the HelloService are “authentication.message”, “integrity.message”, and “confidentiality.transport”.

7.2.3 References to Concrete Policies

In addition to the SCA intent model’s late binding approach, developers can reference concrete policies explicitly by attaching policySets directly, as shown below:

<interface.wsdl interface="..." />

<binding.ws policySets="acme:CorporatePolicySet3"/>

</service>

It is possible to use the @requires attribute and the @policySets attributes together during

1184 development, it indicates the intention of the developer to configure the element, such as a binding, by the application of specific @policySets that are in scope for this element using the computed intents that apply to this element. The @requires attribute designates a configuration of concrete policies specified by the policySets overiding the defaults specified in the policySets.

7.3 Implementation Security Policy

SCA security model provides a policy reference mechanism which can specify security

implementation policy files external to the SCA composite document. Security implementation policy of component implementation such as EJB can be defined in J2EE deployment descriptor ejb-jar.xml which can be referred to by the policy reference document. Additionally SCA security model defines a security implementation policy that may be used by POJO component implementation as well as other type of component implementations.

7.3.1 Authorization and Security Identity Policy

Two policy assertions are defined which apply to implementations – Authorization and SecurityIdentity. Authorization controls who can access the protected SCA resources. A security role is an abstract concept that represents a set of access control constraints on SCA resources such as composites, components, and operations. The approach and scope of the mapping of role names to security principals is SCA runtime implementation dependent. Scope implies the set of artifacts contained by some higher-level artifact, so that a composite contains components, a component contains services and references, services and reference contain an interface, an interface contains operations.

Security Identity declares the security identity under which an operation will be executed. Both are represented as policy assertions that would be used within policySets created for implementations (i.e. implementation policies). The following policy assertions are defined:

When the <allow> element is included in a policySet used on a component, then that component can only be accessed by principals whose role corresponds to one of the role names listed in the @roles attribute. How role names are mapped to security principals is implementation dependent (SCA does not define this).

The <permitAll/> and </denyAll> policy assertions grant or deny access to all principals,

respectively.

The <runAs> policy assertion specifies the name of a security role. Any code so annotated will run with the permissions of that role. How runAs role names are mapped to security principals is implementation dependent.

7.3.2 Implementation Policy Example

The following is an example implementation, written in Java. The AccountServiceImpl implements the AccountService interface, which is defined via a Java interface:

package services.account;

@Remotable

public interface AccountService{

public AccountReport getAccountReport(String customerID);

}

The following is a composite that contains an AccountServiceComponent, which should be accessible by anyone with the “customer” role.

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"

name="AccountService">

<component name="AccountServiceComponent">*

<implementation.java class="services.account.AccountServiceImpl"

policySets="acme:allow_customers"/>

</component>

</composite>

The following is what the policySet definition looks like for this case.

</policySet>

7.3.3 SCA Component Container Requirements

SCA component containers MUST support the SCA policy intent model including annotated intent and policySets reference. Additionally SCA component containers MUST satisfy the following security management requirements.

7.3.4 Security Identity Propagation

SCA container MUST establish security identity when authentication is required based on the security intents before executing the SCA component implementation. The security identity under which the operation is executed is determined by the run-as security policy. It is either the user identity who invokes the SCA operation or the identity that represents the run-as security role. When an SCA operation invokes other SCA services, SCA component container must propagate the security identity along with the SCA request.

7.3.5 Security Identity Of Async Callback

In SCA async programming model, the security identity that executes the callback operation by default should be the same as security identity under which the original operation was executed.

7.3.6 Default Authorization Policy

It may happen that some operations are not assigned any security roles and are not marked as DenyAll or PermitAll. In the SCA deployment process, those operations must be assigned security roles or marked as DenyAll or PermitAll. At runtime time if any operations are not associated with any explicit authorization policy, no access control will be enforced on those operations, i.e., PermitAll.

7.3.7 Default RunAs Policy

Operations will be executed under authentication user identity if no RunAs role policy is explicitly specified.

8 Reliability Policy

Failures can affect the communication between a service consumer and a service provider.

Depending on the characteristics of the binding, these failures could cause messages to be

redelivered, delivered in a different order than they were originally sent out or even worse, could cause messages to be lost. Some transports like JMS provide built-in reliability features such as at least once and exactly once message delivery. Other transports like HTTP need to have additional layers built on top of them to provide some of these features.

The events that occur due to failures in communication may affect the outcome of the service invocation. For an implementation of a stock trade service, a message redelivery could result in a new trade. A client (i.e. consumer) of the same service could receive a fault message if trade orders are not delivered to the service implementation in the order they were sent out. In some cases, these failures could have dramatic consequences.

An SCA developer can anticipate some types of failures and work around them in service

implementations. For example, the implementation of a stock trade service could be designed to support duplicate message detection. An implementation of a purchase order service could have built in logic that orders the incoming messages. In these cases, service implementations don’t need the binding layers to provide these reliability features (e.g. duplicate message detection, message ordering). However, this comes at a cost: extra complexity is built in the service implementation. Along with business logic, the service implementation has additional logic that handles these failures.

Although service implementations can work around some of these types of failures, it is worth noting that is not always possible. A message may be lost or expire even before it is delivered to the service implementation.

Instead of handling some of these issues in the service implementation, a better way of doing it is to use a binding or a protocol that supports reliable messaging. This is better, not just because it simplifies application development, it may also lead to better throughput. For example, there is less need for application-level acknowledgement messages. A binding supports reliable messaging if it provides features such as message delivery guarantees, duplicate message detection and message ordering.

It is very important for the SCA developer to be able to require, at design-time, a binding or protocol that supports reliable messaging. SCA defines a set of policy intents that can be used for specifying reliable messaging Quality of Service requirements. These reliable messaging intents establish a contract between the binding layer and the application layer (i.e. service implementation or the service consumer implementation) (see below).

8.1 Policy Intents

Based on the use-cases described above, we define the following policy intents. It’s worth noting that SCA does not provide support for attaching an intent at a message level. Therefore, an intent attached at an operation level applies to all the messages in the operation (e.g. both request and response messages for a request/response message exchange pattern).

1) atLeastOnce - The binding implementation guarantees that a message that is successfully sent by a service consumer is delivered to the destination (i.e. service implementation). The message could be delivered more than once to the service implementation.

The binding implementation guarantees that a message that is successfully sent by a service implementation is delivered to the destination (i.e. service consumer). The message could be delivered more than once to the service consumer.

2) atMostOnce - The binding implementation guarantees that a message that is successfully sent by a service consumer is not delivered more than once to the service implementation. The binding implementation does not guarantee that the message is delivered to the service implementation.

The binding implementation guarantees that a message that is successfully sent by a service implementation is not delivered more than once to the service consumer. The binding implementation does not guarantee that the message is delivered to the service consumer.

3) ordered – The binding implementation guarantees that the messages are delivered to the service implementation in the order in which they were sent by the service consumer. This intent does not guarantee that messages that are sent by a service consumer are delivered to the service implementation.

The binding implementation guarantees that the messages are delivered to the service consumer in the order in which they were sent by the service implementation. This intent does not guarantee that messages that are sent by the service implementation are delivered to the service consumer.

4) exactlyOnce - The binding implementation guarantees that a message sent by a service consumer is delivered to the service implementation. Also, the binding implementation guarantees that the message is not delivered more than once to the service implementation.

The binding implementation guarantees that a message sent by a service implementation is delivered to the service consumer. Also, the binding implementation guarantees that the message is not delivered more than once to the service consumer.

NOTE: This is a profile intent, which is composed of atLeastOnce and atMostOnce.

This is the most reliable intent since it guarantees the following:

· message delivery – all the messages sent by a sender are delivered to the service implementation (i.e. Java class, BPEL process, etc.).

· duplicate message detection and elimination – a message sent by a sender is not processed more than once by the service implementation.

How can a binding implementation guarantee that a message that it receives is delivered to the service implementation? One way to do it is by persisting the message and keeping redelivering it until it is processed by the service implementation. That way, if the system crashes after delivery but while processing it, the message will be redelivered on restart and processed again. Since a message could be delivered multiple times to the service implementation, this technique usually requires the service implementation to perform duplicate message detection. However, that is not always possible. Often times service implementations that perform critical operations are designed without having support for duplicate message detection. Therefore, they cannot process an incoming

message more than once.

Also, consider the scenario where a message is delivered to a service implementation that does not handle duplicates - the system crashes after a message is delivered to the service implementation but before it is completely processed. Should the underlying layer redeliver the message on restart? If it did that, there is a risk that some critical operations (e.g. sending out a JMS message or updating a DB table) will be executed again when the message is processed. On the other hand, if the underlying layer does not redeliver the message, there is a risk that the message is never completely processed.

This issue cannot be safely solved unless all the critical operations performed by the service

implementation are running in a transaction. Therefore, exactlyOnce cannot be assured without involving the service implementation. In other words, an exactlyOnce message delivery does not guarantee exactlyOnce message processing unless the service implementation is transactional. It’s worth noting that this is a necessary condition but not sufficient. The underlying layer (e.g. binding implementation, container) would have to ensure that a message is not redelivered to the service implementation after the transaction is committed. As an example, a way to ensure it when the binding uses JMS is by making sure the operation that acknowledges the message is executed in the same transaction the service implementation is running in.

8.2 End to end Reliable Messaging

Failures can occur at different points in the message path: in the binding layer on the sender side, in the transport layer or in the binding layer on the receiver side. The SCA service developer doesn’t really care where the failure occurs. Whether a message was lost due to a network failure or due to a crash of the machine where the service is deployed, is not that much important. What is important though, is that the contract between the application layer (i.e. service implementation or service consumer) and the binding layer is not violated (e.g. a message that was successfully transmitted by a sender is always delivered to the destination; a message that was successfully transmitted by a sender is not delivered more than once to the service implementation, etc). It is worth noting that

the binding layer could throw an exception when a sender (e.g. service consumer, service

implementation) sends a message out. This is not considered a successful message transmission.

In order to ensure the semantics of the reliable messaging intents, the entire message path, which is composed of the binding layer on the client side, the transport layer and the binding layer on the service side, must be reliable.

8.3 Intent definitions

<?xml version="1.0" encoding="ASCII"?>

<intent name="atLeastOnce"

appliesTo="sca:binding">

This intent is used to indicate that a message sent

by a client is always delivered to the component.

</description>

</intent>

<intent name="atMostOnce"

appliesTo="sca:binding">

This intent is used to indicate that a message that was

successfully sent by a client is not delivered more than once to the component.

</description>

</intent>

<intent name="ordered"

appliesTo="sca:binding">

This intent is used to indicate that all the messages

are delivered to the component in the order they were

sent by the client.

</description>

</intent>

<intent name="exactlyOnce"

appliesTo="sca:binding" requires="atLeastOnce atMostOnce">

This profile intent is used to indicate that a message

sent by a client is always delivered to the component.

It also indicates that duplicate messages are not

delivered to the component.

</description>

</intent>

</definitions>

9 Miscellaneous Intents

The following are standard intents that apply to bindings and are not related to either security or reliable messaging:

SOAP – The SOAP intent specifies that the SOAP messaging model should be used for delivering messages. It does not require the use of any specific transport technology for delivering the messages, so for example, this intent can be supported by a binding that sends SOAP messages over HTTP, bare TCP or even JMS. If the intent is required in an unqualified form then any version of SOAP is acceptable. Standard qualified intents also exist for SOAP.1_1 and SOAP.1_2, which specify the use of versions 1.1 or 1.2 of SOAP respectively.

JMS – The JMS intent does not specify a wire-level transport protocol, but instead requires that whatever binding technology is used, the messages should be able to be delivered and received via the JMS API.

NoListener – This intent may only be used within the @requires attribute of a reference. It states that the client is not able to handle new inbound connections. It requires that the binding and callback binding be configured so that any response (or callback) comes either through a back channel of the connection from the client to the server or by having the client poll the server for messages. An example policy assertion that would guarantee this is a WS-Policy assertion that applies to the <binding.ws> binding, which requires the use of WS-Addressing with anonymous responses (e.g. <wsaw:Anonymous>required</wsaw:Anonymous>” – see

http://www.w3.org/TR/ws-addr-wsdl/#anonelement).

BP.1_1 – This intent specifies the use of a binding that conforms to the WS-I Basic Profile version 1.1. Any binding or policySet that provides this intent should also provide the SOAP intent. However, the BP intent is not a profile intent, since it is not completely satisfied by the lower-level SOAP– there are additional semantic requirements.

Conversational - This intent is meant to be used on an interface, and indicates that the interface is "conversational" as defined in the SCA Assembly Specification [SCA-Assembly].

10 Conformance

A: Schemas

A.1 XML Schemas

<?xml version="1.0" encoding="UTF-8"?>

<schema xmlns="http://www.w3.org/2001/XMLSchema"

targetNamespace="http://www.osoa.org/xmlns/sca/1.0"

xmlns:sca="http://www.osoa.org/xmlns/sca/1.0"

xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"

elementFormDefault="qualified">

<import namespace="http://schemas.xmlsoap.org/ws/2004/09/policy"

schemaLocation="http://schemas.xmlsoap.org/ws/2004/09/ws-policy.xsd"/>

<element name="description" type="string" minOccurs="0"

maxOccurs="1" />

<any namespace="##other" processContents="lax"

minOccurs="0" maxOccurs="unbounded"/>

</sequence>

</complexType>

</choice>

</complexType>

</complexType>

</choice>

</complexType>

</choice>

</complexType>

</complexType>

</complexType>

</simpleType>

</schema>

B. Acknowledgements

C. Non-Normative Text

D. Revision History

[optional; should not be included in OASIS Standards]

Revision	Date	Editor	Changes Made
2	Nov 2, 2007	David Booz	Inclusion of OSOA errata and Issue 8
3	Nov 5, 2007	David Booz	Applied resolution of Issue 7, to Section 4.1 and 4.10. Fixed misc. typos/grammatical items.