Map SCA abstract intents and managing policy sets

WAS v8.5 > Administer applications and their environment > Administer web services (generally applicable) > Manage web services policy sets
Map SCA abstract intents and managing policy sets

Use this task topic to specify abstract intents that represent a quality of service (QoS) for a service or reference that uses the SCA web service binding. Most intents must be mapped to policy sets that can satisfy those intents during deployment to achieve the QoS required.

Before beginning this task, install an SCA application. Use the composite file to specify intents for web services bindings that represent quality of services (QoS).
Specify abstract intents using the requires attribute of the <binding.ws> element of the service or reference level of the component.
We can specify intents on the composite, component, service, and reference elements in the composite file, and they are propagated to any <binding.ws> elements that are contained within them. We can also specify intents in the implementation class using the @Requires annotation.
The following code example illustrates how to specify intents in a composite file:
<service name="AccountService" requires=”confidentiality”>   <binding.ws 
     requires="confidentiality.transport"
     ... /> </service>
Valid intents that we can use are:

confidentiality
confidentiality.message
confidentiality.transport
integrity
integrity.message
integrity.transport
authentication (OSOA composites only)
authentication.message (OSOA composites only)
authentication.transport (OSOA composites only)
clientAuthentication (OASIS composites only)
clientAuthentication.message (OASIS composites only)
clientAuthentication.transport (OASIS composites only)
serverAuthentication (OASIS composites only)
serverAuthentication.message (OASIS composites only)
serverAuthentication.transport (OASIS composites only)
propagatesTransaction

The following table describes intents that require the attachment of a policy set to achieve QoS.
Intents supported by different types of bindings. Intents and the supported bindings to achieve QoS.

Intents Required policy set attachments

authentication (OSOA)
authentication.message (OSOA)
clientAuthentication (OASIS)
clientAuthentication.message (OASIS)

Requires the attachment of a web service policy set and policy binding containing the WS¬Security policy type

confidentiality
confidentiality.message
integrity
integrity.message

Requires the attachment of a web service policy set and policy binding containing the WS¬Security policy type

authentication.transport (OSOA)
clientAuthentication.transport (OASIS)

Supports HTTP basic authentication only. A reference requires the attachment of a web service policy set and policy binding containing the HTTPTransport policy type. The HTTPTransport binding must supply a user ID and password. A service does not require any attachments.

confidentiality.transport
integrity.transport
serverAuthentication.transport (OASIS)

No attachments required
propagatesTransaction Requires the attachment of a web service policy set containing the WS-¬Transaction policy type

Mapping of these intents to a policy set can be done during deployment using the interactive addCompUnit command or the dmgr console. The Policy Set column in the dmgr console page provides hints as to which policy sets might best satisfy the intents. Choose to attach one of the suggested default policy sets or attach any other policy set defined in the product. Attaching no policy set is a valid choice. This might be the case when there are no satisfying policy sets or the intents are not valid.
Attach policy sets and bindings.
The policy sets referenced in this topic are defined for web services and apply to web service bindings. For an overview of policy sets, read web services policy sets.
We can attach policy sets and bindings at any of the levels in a composite file. WAS v8.5 provides some default policy sets, as well as a sample service and reference binding for the client. We can create additional policy sets and bindings using the web services dmgr console or scripting functionality. Refer to creating policy sets using the dmgr console or creating policy set attachments using wsadmin.
In a mixed cell environment, the following limitations apply to attachments to policy sets containing the CustomProperties policy:

You must not create attachments to policy sets containing the CustomProperties policy for applications deployed on an application server that is prior to WebSphere Application Server v8.0. The CustomProperties policy is only supported on v8.0 and later.
An application containing an attachment to a policy set containing the CustomProperties policy must not be deployed on an application server that is prior to WAS v8.0.
If an application that is deployed in a cluster environment contains an attachment to a policy set containing the CustomProperties policy, you must not add a member application server that is prior to WAS v8.0 to the cluster.
mixv
Policy sets and bindings can be specified for SCA services and references using one of three different methods.

Attach a policy set during deployment using the addCompUnit command.
Attached or update a policy set during post deployment using the web services policy set management pages in the dmgr console.
Specify a policy set and bindings directly in the composite file.

Attachments made using the addCompUnit command and the composite file are applied at the WSDL service level. We can apply policy set attachments using the web service policy set management pages at either the WSDL service level or the WSDL port level. SCA does not support operation level attachments.
Policy set management using commands
We can run the addCompUnit command in interactive mode to attach policy sets. After navigating to the AttachPolicySet step, the policy set to be attached can be specified for different resource IDs.
When running the addCompUnit command in batch mode, the policy set can be directly attached to a resource ID using the -AttachPolicySet step. The syntax of the command is:
AdminTask.addCompUnit('[-blaID … -AttachPolicySet[[<resourceID> .* .* .* <Policy set to attach>]]]')

The following are the valid resource IDs:
<composite name> <composite name>/<component name> <composite name>/<component name>/<service name> <composite name>/<component name>/<service name>/binding.ws
<composite name>/<component name>/<reference name> <composite name>/<component name>/<reference name>/binding.ws
The following is an example of the command:
AdminTask.addCompUnit ('[-blaID myBLA -cuSourceID echoService.jar -AttachPolicySet 
    [[EchoServiceWSComposite/EchoServiceWSComponent/EchoService/binding.ws .* .* .* "WSHTTPS default"]]]')
The command above attaches the WSHTTPS default policy set to the binding.ws under EchoService. The policy is fine tuned using the provider sample binding. The policy set attached during deployment can be changed at post-deployment using the dmgr console or commands.
Policy set management

We can attach policy sets to your business level applications using the dmgr console during deployment and after deployment. During deployment, the policy set can be configured in the Attach policy set page that displays when we are adding a composition unit. To view the Attach policy set page, you must be deploying a business-level application that uses web services. This page does not exist in post deployment. After deployment, the policy can be configured using the service provider and the service client pages under the Services menu. See information about the attach policy set settings.

Policy set management using composite file

We can use the wsPolicySet attribute to specify a web service policy set, the wsServicePolicySetBinding attribute to specify a general provider policy set binding for a service, and the wsReferencePolicySetBinding attribute to specify a general client policy set binding for a reference. First create the policy sets and the bindings using web service administrative tools, and then attach the policy set using one of the three methods described in this task step.
The following is an example of a OSOA composite file that uses the wsPolicySet attribute:
<?xml version="1.0" encoding="UTF-8"?> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0" 
           …
           xmlns:qos="http://www.ibm.com/xmlns/prod/websphere/sca/1.0/2007/06"
           name="EchoServiceWSComposite"> 
    <component name="EchoServiceWSComponent">         …
        <service name="EchoService">             <binding.ws 
                  qos:wsPolicySet="WSHTTPS default" qos:wsServicePolicySetBinding="Provider sample"

                  … />         </service>   
    </component> </composite>
An OASIS composite is identical except the namespace prefixes are declared as:
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912"
xmlns:qos="http://www.ibm.com/xmlns/prod/websphere/sca/1.1"
We can use the wsPolicySet, wsServicePolicySetBinding, and wsReferencePolicySetBinding attributes at the composite, component, service, reference, and binding.ws levels.
The actual attachment happens only at the binding.ws level and policy sets and bindings specified at the other levels are inherited down to the binding.ws level. Policy sets are inherited in a top-down format. However, a policy set specified at a lower level has precedence over what it inherits. For example, in the sample OSOA composite file shown below, the policy set attached for the binding for EchoService1 is LTPA WSSecurity default but the binding for EchoService2 inherits the Username WSSecurity default policy set from the composite level.
<?xml version="1.0" encoding="UTF-8"?> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
           …
           xmlns:qos="http://www.ibm.com/xmlns/prod/websphere/sca/1.0/2007/06"
           name="EchoServiceWSComposite" qos:wsPolicySet="Username WSSecurity default">   <component name="EchoServiceWSComponent">     …
    <service name="EchoService1">        <binding.ws
           qos:wsPolicySet="LTPA WSSecurity default"
           … />     </service>     <service name="EchoService2">        <binding.ws
           … />     </service>   </component> </composite>
Results

When you finish this task, we have mapped abstract intents to policy sets and attached policy sets to your SCA service artifact.

We can proceed to configure application specific bindings.

Related concepts:

Web services policy sets

Related

Manage policy sets
Create policy sets
Create policy set attachments using wsadmin
Attaching a policy set to a service artifact
Create application specific bindings for policy set attachment

Reference:

Attach policy set settings
BLAManagement command group for AdminTask using wsadmin.sh

+
Search Tips | Advanced Search

Intents	Required policy set attachments
authentication (OSOA) authentication.message (OSOA) clientAuthentication (OASIS) clientAuthentication.message (OASIS)	Requires the attachment of a web service policy set and policy binding containing the WS¬Security policy type
confidentiality confidentiality.message integrity integrity.message	Requires the attachment of a web service policy set and policy binding containing the WS¬Security policy type
authentication.transport (OSOA) clientAuthentication.transport (OASIS)	Supports HTTP basic authentication only. A reference requires the attachment of a web service policy set and policy binding containing the HTTPTransport policy type. The HTTPTransport binding must supply a user ID and password. A service does not require any attachments.
confidentiality.transport integrity.transport serverAuthentication.transport (OASIS)	No attachments required
propagatesTransaction	Requires the attachment of a web service policy set containing the WS-¬Transaction policy type