Building and Deploying a Custom Policy
A policy is an ordered set of assertions that describe the non-functional requirements or capabilities of a service. Policies describe the semantic requirements or capabilities that cannot be expressed by using structural contract languages such as XML Schema Definition (XSD) or the Web Services Description Language (WSDL).
You can define policies that operate across an entire service, and you can define policies that are specific to one or more operations in a service.
DCS provides policy definitions for many common aspects of a DCS service. These policies are:
- EncodingPolicy, which lets you specify how messages are encoded (W3C Message Transmission Optimization Mechanism [MTOM] or text), as well as set limits on the sizes of messages that can be read by a service. This is a service-level policy.
- IdentityPolicy, which lets you specify the Service Principal Name (SPN) to use to run a service. This is a service-level policy.
- ServiceBindingPolicy, which lets you specify the transport (HTTP or TCP) that a service endpoint uses to receive and send messages. This is a service-level policy.
- SecurityPolicy, which lets you specify the process for authenticating client requests. This is a service-level policy.
- BusinessLogPolicy, which lets you record information about request and response messages that pass between a client application and the service. This is an operation-level policy.
- CachingPolicy, which lets you require a service to implement response caching. This is an operation-level policy.
- ContextPolicy, which lets you specify whether DCS context information should be included in messages. This is an operation-level policy.
- ProtectionPolicy, which lets you specify how to protect messages by using encryption and signing. This is an operation-level policy.
A service must share the definitions of the policies that it implements with client applications that connect to the service. A client application can then examine the policy definitions to determine whether it can meet the requirements of the service. Depending on the configuration and capabilities of the client application, the client could use the service policy definitions to automate its support for the specified requirements and protocols. The WS-Policy specification uses a standard grammar that enables a service to specify the policies that it implements. Client applications that follow the WS-Policy specification can query and parse the policy information specified by a service, and configure themselves appropriately. However, publishing policies in a service and parsing them in a client application are not trivial tasks. Fortunately, DCS provides support for these tasks. You can use the DCS Management Services Console to specify a policy for a service, and you can use the binding elements provided with DCS to configure the policy importer components for a client application.. For more information about configuring the policies provided with DCS, see Configuring Policies for Services and Operations.
You can define custom policies if you need to implement additional non-functional requirements for services or operations. You can define policies at the service level and at the operation level. Service-level policies apply to an entire service. Operation-level policies apply to only selected operations in a service.
The steps to introduce a custom policy to a DCS service and client application are:
- Create the classes that implement and support the custom policy.
- Deploy the custom policy.
- Configure the service hosting environment to reference the policy.
- Configure the client applications that call the service to parse the policy and modify the behavior of the client applications.
The topics in this section describe these steps in detail.
In This Section
How DCS Implements Policy Assertions
Creating Classes that Implement and Support a Custom Policy
Deploying and Configuring a Custom Policy