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.
Specifying
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.
Table 1. 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 WSSecurity 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 WSSecurity
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 WSTransaction policy type |
Supported; no configuration required |
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.
Attach policy sets and bindings. Important: 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. 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.
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 using the administrative console or commands.
Policy
set management using the administrative console
You 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, you must 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
You 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>