Network Deployment (Distributed operating systems), v8.0 > Administer applications and their environment > Administer web services (generally applicable) > Manage web services policy sets


Map abstract intents and managing policy sets

Use this task topic to specify abstract intents in the Service Component Architecture (SCA) composite file or with annotations to achieve a quality of service (QoS) for a service or reference when you are working with web services policy sets and bindings. The intents in the composite file must be mapped to policy sets that can satisfy those intents during deployment to achieve the QoS that is required.

Before you begin this task, install an Service Component Architecture (SCA) application.

Use the composite file to specify intents and policy sets for web services bindings to achieve quality of services (QoS).

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

mixv


Procedure

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

    You can specify intents at any level in the composite file using a required attribute. The intent inheritance rules specified in the SCA Policy specification is enforced in the product. The following code example illustrates how to specify intents in a composite file.

    Specify intents in a composite file 

    <service name="AccountService" requires=”authentication”>
<binding.ws
     requires="confidentiality.transport"
     ... />
</service>

    Valid intents that can be mapped to a policy set are:

    confidentiality
    confidentiality.message
    confidentiality.transport
    integrity
    integrity.message
    integrity.transport
    authentication
    authentication.message
    authentication.transport
    propagatesTransaction

    The table provides a list of intents and the supported bindings to achieve QoS.

    Intents supported by different types of bindings. Intents and the supported bindings to achieve QoS

    Intent binding.ws binding.ejb and binding.sca
    authentication.message Intent requires the attachment of a web service policy set and policy binding that contains the WS­Security policy type Not supported; CSIv2 can be configured to use basic auth or security token (LTPA, Kerberos)
    confidentiality.message and integrity.message Both intents require the attachment of a Web service policy set and policy binding that contains the WS­Security policy type Not supported
    authentication.transport Basic auth only. Reference requires the attachment of a web service policy set that contains the HTTPTransport policy type. Service does not require any attachments. Intent is not supported. CSIv2 can be configured to use client certificates for authentication.
    confidentiality.transport and integrity.transport Requires the attachment of a web service policy set that contains the SSLTransport policy type Intent is not supported. CSIv2 can be configured to require SSL.
    propagatesTransaction Requires the attachment of a web service policy set that contains the WS­Transaction policy type Supported; no configuration required

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

    Annotations are not supported with web services policy sets.

    The policy sets referenced in this article 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. We can create additional policy sets and bindings using the web services administrative console or scripting functionality. Refer to creating policy sets or creating policy set attachments using wsadmin.

    Policy sets and bindings can be specified for SCA services and references using one of three different methods.

    • Specify a policy set and bindings directly in the composite file.
    • 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 panels in the administrative console.

    Policy set management using commands

    The addCompUnit command can be run 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 ID's.

    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 ID's: 

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

    Policy set management

    We can also attach policy sets to your business level applications using the administrative console during deployment and post deployment. During deployment, the policy set can be configured in the Attach policy set panel that shows up when you are adding a composition unit. To view the Attach policy set panel, be deploying a business-level application that uses web services. This panel does not exist in post deployment. During post deployment, the policy can be configured using the service provider and the service client panels under the Services menu. For additional information on using the administrative console to attach policy sets, see attach policy set settings document.

    Policy set management using composite file

    We can specify wsPolicySet attribute for policy sets at the composite, component, service, reference, and binding.ws levels. The actual attachment happens only at the binding.ws level and policy sets specified at the other levels are inherited down to the bindings level. The inheritance rules are described in the next task step. Similar to the wsPolicySet, you can specify the wsServicePolicySetBinding and wsReferencePolicySetBinding attributes. First create the policy sets and the bindings using web services 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 composite file with a wsPolicySet mapping. 

    <?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>
  3. Define policy set inheritance.

    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 composite file shown in this task step, the policy set attached for the binding for EchoService1 is LTPA WSSecurity default but the bindings at EchoService2 inherits the WSHTTPS default policy set from the composite level.

    Define policy set inheritance 

    <?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="WSHTTPS 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.


What to do next

We can proceed to configure application specific bindings.
Web services policy sets
Create policy sets
Create policy set attachments using wsadmin
Attach a policy set to a service artifact
Create application specific bindings for policy set attachment
Manage policy sets


Related


Attach policy set settings
BLAManagement command group using wsadmin.sh

+

Search Tips   |   Advanced Search