Constraints and Capabilities Workshop Oracle Position Ashok Malhotra Greg Pavlik

Background  Position based on lessons learned: – Product implementation experiences. – Work on WSDL 2.0 Features and Properties, WS- Reliability as well as WS-Policy.  While we agree that a declarative, assertion- based design is desirable, we think F&P and WS-Policy have shortcomings. WS-Policy allows composition of assertions from different domains. F&P needs compositors.

Summary  A policy is a collection of domain expressions.  Domain functionality cannot be combined.  Two distinct varieties of domains that must be treated differently: – Domains that influence message content. – Domains that convey information about the service.

Domains  A domain is an orthogonal axis of functionality.  A policy is a collection of independent domain expressions.  Functionality for a domain is expressed using domain-specific formalisms and syntax.

Domain Dichotomy  Two kinds of domains…  Some domains influence message content (headers and bodies). – e.g. Security, Reliability  Other domains convey information about the service and may be in various ways e.g. used to decide whether to use the service. – Privacy (P3P) – Auditing/Logging

Domains that Influence Message Content  For example: security, reliability, transactions.  Functionality expressed as assertions connected by operators (compositors) such as all, choice, exactlyOne.  Client and server must agree on/select message policy.  Domain functionality may be ‘required’ or ‘supported’.

Domains that Influence Message Content (continued)  Client is configured or generated to conform to selected policy alternative.  Messages need to indicate which policy alternative is followed.  Server verifies that policy is adhered to.

Informational Domains  Informational assertions do not affect message content. They convey information about the service that may be used in several ways.  Informational domains are not ‘required’ or ‘supported’.  In some cases the client may insist that some advertised policy be enforced and may verify this.

Informational Domains  Several service characteristics may influence whether a client will use a policy or not: e.g. legal contract, privacy policy.  Decision could be made by man (lawyer reads legal contract) or machine (EPAL, WSPL).  Such characteristics could be used as part of the service discovery process.

Policy Attachment and Access  The policy may be associated with a service in several different ways: attached to WSDL, UDDI, RDDL, WSIL, etc.  Several policies may apply to a service.  Policies may be managed as documents in a document library with change control etc.  Need a standard mechanism to: – Access the entire policy for a service endpoint. – Access the policy details for a particular domain.  This mechanism would return a policy that may be composed of policy fragments from several related sources.

Policy Attachment and Access  Policies will evolve and may change during a conversation.  Messages should identify the policy they adhere to and if the policy changes during the conversation a fault should be signaled.

Recapitulation  A policy is a collection of domain expressions.  A domain’s functionality is described (and combined) using a domain-specific formalism.  Functionality for different domains cannot be combined.  Domains that influence message content and domains that provide information about the service are fundamentally different and must be treated differently.