EXPERT RESPONSE
Policies specify the rules and constraints that govern interactions between service endpoints. Policies apply to any aspect of the interaction, such as authentication, authorization, auditing, data integrity, data confidentiality, privacy protection, routing, transformations, performance, latency, etc. Policies are specified and codified using some type of policy assertion language (PAL)--typically through a policy management administration (PMA) console. Policies can be associated with or attached to a service or interaction in a number of different ways. Policies are enforced at runtime by a policy enforcement point (PEP). A PEP is situated somewhere between the communicating endpoints. It intercepts an interaction and ensures that the rules defined by the policy have been obeyed. If the policies have not been obeyed, the PEP can either do something that brings the interaction into compliance, or it can terminate the interaction. In some cases the PEP may need to evaluate current context variables or rules to decide whether the policy has been obeyed. These decisions related to policy evaluation are performed by a policy decision point (PDP). (The PDP could be implemented in the same piece of software that provides the PEP, but logically they are separate roles.)
What I've described here is a generic model that can apply to any type of interaction system. Since you ask about WSDL, I assume you'd like more specific information regarding how it applies to an infrastructure based on WS-*.
The WS-Policy Framework provides a foundation for supporting a policy-driven infrastructure.
- WS-Policy describes the overarching framework and defines an XML language and syntax for expressing policies and policy groups
- WS-PolicyAttachment defines attachment mechanisms using WSDL 1.1, WSDL 2.0, and UDDI. The WS-Policy Framework does not preclude other attachment mechanisms
- Various WS-* specifications define domain-specific PALs, such as WS-SecurityPolicy, WS-RM Policy, WS-Transactions, and WS-Addressing Metadata. (Many more standard PALs are needed, though, e.g., for expressing routing, performance, and latency policies)
The WS-Policy Framework does not specify where or how PEPs should be deployed, which leaves lots of freedom to the SOA infrastructure products to support a variety of enforcement models. PEPs are typically deployed either as modules within the SOAP processing pipeline or as proxies/intermediaries. The most popular policy-driven infrastructure products include SOA management and XML gateway products. A small number of ESB and service platform products also support WS-Policy (although in many cases they only support WS-SecurityPolicy). These policy-driven SOA infrastructure products often provide an administrative console (a PMA) for defining policies, grouping policies, and attaching policies to services or service contracts. (A service contract defines the rules that apply to a specific relationship between a service consumer and a service provider.)
Some suggested reading
WS-Policy Primer
Guidelines for Policy Assertion Authors
WS-Policy specification
WS-PolicyAttachment specification
An informative article
|
