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 this task, install an SCA application.
Use the composite file to specify intents for web services bindings that represent quality of services (QoS).
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:
The following table describes intents that require the attachment of a policy set to achieve QoS.
Intents | Required policy set attachments |
---|---|
authentication (OSOA) |
Requires the attachment of a web service policy set and policy binding that contains the WS¬Security policy type |
confidentiality |
Requires the attachment of a web service policy set and policy binding that contains the WS¬Security policy type |
authentication.transport (OSOA) |
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 |
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.
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.
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.
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>]]]')
<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
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.
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>
xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912"
xmlns:qos="http://www.ibm.com/xmlns/prod/websphere/sca/1.1"
<?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>
When you finish this task, you have mapped abstract intents to policy sets and attached policy sets to your SCA service artifact.
You can proceed to configure application specific bindings.