[Fix Pack 1 or later]


Configuring the client policy to use a service provider policy from a registry

An application that is a Web service client can obtain the policy configuration of a Web service provider from a registry, such as WebSphere Service Registry and Repository (WSRR), and use this information to establish a policy configuration that is acceptable to both the client and the service provider.

Before you begin

You have developed a Web service client that contains all the necessary artifacts, and deployed your Web services application into your application server instance. If you require them, you have attached the policy sets and managed the associated bindings.

The Web Services Description Language (WSDL) for the policy of the service provider, and its corresponding policies and policy attachments, are stored in a registry such as WSRR. That policy must contain its policy configuration in WS-PolicyAttachments format. The client must be able to support those provider policies.

The registry must support the use of HTTP Get requests to publish WSDL that contains WS-Policy attachments, for example WSRR Version 6.2 or later.

For a list of WS-Policy assertion specifications and WS-Policy domains that are supported, see Learning about WS-Policy.

About this task

You can administer the client to configure itself dynamically at run time, based on the policy of a service provider that is held in a registry. You can administer the client to apply dynamically the provider policy that it obtains from a registry at the service level. Endpoints and operations inherit their policy configuration from the relevant service. You cannot administer the client to apply dynamically the provider policy that it obtains from a registry at the application level.

You can configure the client policy to use a service provider policy that is stored in a registry by using the administrative console. You can also configure the client policy to use a service provider policy that is stored in a registry by using wsadmin commands.

Procedure

  1. From the navigation pane of the administrative console, click Applications > Application Types > WebSphere enterprise applications .
  2. Click the Web service client application that you want to configure.
  3. Click [Web services properties] Service client policy sets and bindings.
  4. In the row for the service where you want to apply the policy, click the link in the Policies Applied column. You cannot apply the policy at application level. The Policies Applied pane is displayed.
  5. Select one of the following options from the drop-down list:
    • Provider policy only. Configure the client based solely on the policy of the service provider. This option is available when a client policy set is not attached.
    • Client and provider policy. Configure the client based on both the client policy set and the policy of the service provider. This option is available when a client policy set is attached.
    The other options in the list do not apply to this task.
  6. Click HTTP GET request.
  7. Click Specify request target, then enter the URL for the location of the provider policy in the field, that is, the address in the repository for the WSDL and policy. For information about using WSRR to retrieve a WSDL document with embedded policies, and therefore obtain the required URL, see the WSRR documentation. The following example shows a typical URL:
    https://www.wsrr.host/WSRR/6.2/PolicyService/
    WSDL?bsrURI=3b9b493b-278f-4f64.ba3f.dabd30da3f7e
  8. Click OK.
  9. Optional: If there is a secure connection that uses the Secure Sockets Layer (SSL) protocol between the client and the registry, ensure that trust is established between the application server and the registry server. To access the registry, the client uses the SSL transport policy that is part of its service-level application policy. For example, for WSRR, you can enter the URL for the WSRR server in a browser window. If the WSRR server is not already trusted, a message is displayed stating that the security certificate is not trusted. To establish trust, use the following steps:
    1. Retrieve and store the X509 certificate from the WSRR server. Use the options on the message to view details of the certificate and save those details to a file, using distinguished encoding rules (DER) encoded binary format.
    2. Find out the key store that the client uses, that is, the key store that is shown by the SSL security transport bindings of the client application policy set. See Configuring the SSL transport policy. For example, the key store might be the default trust store for the node.
    3. Add the signer certificate that you saved in step a. to the key store that the client uses. See Adding a signer certificate to a keystore.
  10. Optional: To access the registry, the client uses the transport policy that is part of its service-level application policy. If the registry requires authentication using the HTTP protocol, configure a valid user name and password as part of the application-level transport policy binding configuration. It is advisable to secure any authorization credentials, because they are used for interactions with both the Web service endpoint and the registry.
    1. Ensure that the client has a policy set that contains the HTTP transport policy attached to the application or service level. See the relevant steps in Managing policy sets and bindings for service clients at the application level using the administrative console.
    2. Configure the HTTP transport client bindings for the binding named Client sample and enter the user name and password that the registry requires to authenticate outbound service requests. See the relevant steps in Configuring the HTTP transport policy.
  11. Save your changes to the master configuration.

Results

The Web application client-side policy is calculated when it is required at run time, based either on the policy of the service provider, or on the client policy set and the policy of the service provider, depending on which option you selected. This calculated policy is known as the "effective policy" and is cached as a runtime configuration. The effective policy is used for subsequent outbound Web service requests to the endpoint or operation for which the dynamic policy calculation was performed. The policy set configuration of the client does not change.

The provider policy that the client holds for a service is refreshed the first time that the Web service is invoked after the application is loaded. After that, the provider policy is refreshed when the application restarts, or if the application explicitly invokes a refresh. When the provider policy is refreshed, the effective policy is recalculated.




In this information ...


Related reference

IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic Task topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Jun 11, 2013 8:40:09 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=v701sca&product=was-nd-mp&topic=twbs_wsp_client_wsrr
File name: twbs_wsp_client_wsrr.html