How DCS Applies Policy to Services and Clients

Policy determines how a service manages the nonfunctional aspects of communicating with that service, such as the security requirements of the service, how messages should be encoded, whether the service supports response caching, and so on. DCS complies with the WS-Policy specification to enable a service to specify its policy requirements in a standard, interoperable manner.

A client application that sends request messages to a service must follow the policies defined for that service. However, these policies might vary over time (an administrator might change them to improve security, for example). Therefore, when a client application connects to a service, it should perform a WS-MetadataExchange operation to query the current policies for the service. The policy definitions are returned in a WSDL document. The client can parse this document, extract the policy definitions, and then apply these policies when it communicates with the service. The following image shows this process.

Dd632013.b42d7b3e-8d42-4930-b8d1-f58acf69ce66(en-us,MSDN.10).png

Retrieving policy information from a service instance

Defining and implementing policies for a service, and then querying them and applying them to a client application are not trivial tasks. However, the DCS runtime provides a mechanism that can automate much of the process.

You can use the DCS Management Services console to define and edit policies for a service. The console uses the PolicyAdminService (one of the Management Services) to store the policy definitions in the ServiceConfiguration database. When a service instance starts, the DCS runtime uses the PolicyAdminService to retrieve the policy definitions for that service from the ServiceConfiguration database, and then applies them to the service instance. DCS lets you deploy multiple instances of a service to different physical locations, and ensures that the same policies are applied consistently across all instances. However, if the policies for a service change while one or more instances of that service are running, the policies are not applied retroactively to those service instances. A service instance retrieves the updated policies only when it stops and restarts.

For more information about how to use the DCS Management Services console to manage policy for a service, see Configuring Policies for Services and Operations.

Dd632013.note(en-us,MSDN.10).gifNote:
DCS provides a small set of commonly used policies that you can apply to a service. For a complete list of these policies, see Policies Provided with DCS. You can build your own custom policies and integrate them into DCS. For more information, see Building and Deploying a Custom Policy.

When a client application sends its first message to a service instance after performing the discovery process, the client proxy sends a WS-MetadataExchange request to query the policies implemented by the service instance. It examines the WSDL definition returned by the service instance, and then applies the policies to the client application. The client proxy uses custom policy importer components provided with DCS to perform this task. The proxy makes sure that all subsequent communications with the service instance comply with the policies.

Dd632013.note(en-us,MSDN.10).gifNote:
Some policies require an administrator to configure the appropriate components on the computer that is running the client application. For example, if a service implements a security policy that requires a specific set of certificates to identify and authenticate the user who is using the client application, then an administrator must make sure that these certificates have previously been installed in the certificate store on the client computer.

Service policy is only queried when a client application sends its first request to a service instance. This is because the policy cannot change while that service instance is still running. However, if communications with the service instance is lost and the client is connected to a different service instance, the proxy sends another WS-MetadataExchange request to retrieve the latest version of any policies required by the service and reconfigures the client accordingly.

The WS-MetadataExchange protocol adds a significant overhead to the first request sent by a client application to a service instance. To reduce this overhead, the client proxy can cache the policy metadata retrieved from a service instance locally, in a SQL Server Compact Edition database on the client computer. You can achieve this by configuring the metadata cache in the client configuration file. You can configure the expiration period of data in the metadata cache, and you can also encrypt the cached metadata for security.

If the policy for a service changes while the information in the metadata cache has not expired, a request sent from the client application to a service instance might fail. In this situation, the client proxy silently sends another WS-MetadataExchange request to the service instance to retrieve the updated policy details, caches them, and reconfigures the client application, before it sends the failed request again.

For more information about how to configure the Metadata Cache, see Configuring a DCS Client Application.

In versions of DCS earlier than DCS Service Pack 1, the client proxy uses HTTP transport to request the metadata from a service instance over a channel that is unprotected and not encrypted. In DCS Service Pack 1, the client proxy connects to metadata endpoints that can only be accessed by using a binding that is configured to help provide security. This is by default. You can change the application configuration file for the client and change the metadata binding configuration to use an unsecured binding for services that do not expose secure metadata endpoints. For more information, see Configuring a DCS Client Application.

Dd632013.note(en-us,MSDN.10).gifNote:
DCS Service Pack 1 also supports metadata exchange over the TCP transport.

Show: