[AIX Solaris HP-UX Linux Windows][z/OS]

Mapping 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 Service Component Architecture (SCA) web service binding. Most intents must be mapped to policy sets that can satisfy those intents during deployment to achieve the QoS that is required.

Before you begin

Before you begin this task, install an SCA application.

About this task

Use the composite file to specify intents for web services bindings that represent quality of services (QoS).

Procedure

  1. Specify abstract intents using the requires attribute of the <binding.ws> element of the service or reference level of the component.

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

    Table 1. 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 that contains the WS¬Security policy type

    confidentiality
    confidentiality.message
    integrity
    integrity.message

    Requires the attachment of a web service policy set and policy binding that contains 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 that contains 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 that contains 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 administrative console. The Policy Set column in the administrative console page provides hints as to which policy sets might best satisfy the intents. You can choose to attach one of the suggested default policy sets or attach any other policy set that is 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.

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

    You can attach policy sets and bindings at any of the levels in a composite file. The product provides some default policy sets, as well as a sample service and reference binding for the client. You can create additional policy sets and bindings using the web services administrative console or scripting functionality. Refer to creating policy sets using the administrative console or creating policy set attachments using the wsadmin tool.

    Mixed-version environment Mixed-version environment: 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 that are deployed on an application server that is prior to WebSphere® Application Server Version 8.0. The CustomProperties policy is only supported on Version 8.0 and later.
    • An application that contains an attachment to a policy set containing the CustomProperties policy must not be deployed on an application server that is prior to WebSphere Application Server Version 8.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 WebSphere Application Server Version 8.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 administrative 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. You 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
    You 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 by 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 administrative console or commands.

    Policy set management using the administrative console
    You can attach policy sets to your business level applications using the administrative console during deployment and after deployment. During deployment, the policy set can be configured in the Attach policy set page that displays when you 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
    You 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 that 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"
    You 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, you have mapped abstract intents to policy sets and attached policy sets to your SCA service artifact.

What to do next

You can proceed to configure application specific bindings.

Task topic    

Terms and conditions for information centers | Feedback

Last updated: April 20, 2014 08:46 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-nd-mp&topic=twbs_sca_intent_policyset
File name: twbs_sca_intent_policyset.html