+

Search Tips   |   Advanced Search

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

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

    types of bindings. Intents and the supported bindings
    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 administrative console. The Policy Set column in the administrative console page provides hints as to which policy sets might best satisfy the intents. We can 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.

  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.

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

    In a mixed cell environment, the following limitations apply to attachments to policy sets containing the CustomProperties policy:

    • We 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 containing 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.

    .

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

    We can attach policy sets to the 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 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 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"

    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 later in this topic, 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 the SCA service artifact.


What to do next

We can proceed to configure application specific bindings.


Related concepts

  • Web services policy sets


    Related tasks

  • Manage policy sets using the administrative console
  • Create policy sets using the administrative console
  • Create policy set attachments
  • Attaching a policy set to a service artifact
  • Create application specific bindings for policy set attachment

  • Attach policy set settings
  • BLAManagement (AdminTask)