Policies and Contracts - notes for currrently posted document

[michael.poulin@uk.fid-intl.com]

Hello, 
unfortunately, I will not be able to participate in the next telcon (28 Feb.) but would like to offer a few comments for the Policies and Contracts doc posted under 
TheArchitecture/ServiceView/PoliciesAndContracts
This is a long message but, I think, it is better to discuss it first and then publish in Wiki.

In Section 1 - Policies and Contracts  relationships between policies, contracts and service description is contradictive to some degree. In one place, the doc says:
"Policies and contracts may be associated with a service through the service description as defined in the visibility section of the RA architecture." In another place, the Visibility Section requires that the service description and policy  or at least a suitable subset thereof  be available..., that is Policy may exist outside of the description.

If we accept the first statement, we can say that service description may contain only policy(ies) or only contract. However, Service Contract is the agreement between service provider and concrete service consumer. Since a SOA service exists independently from consumers, there should be a form of description, which does not contain a contract, and, from another hand, if a contract with a consumer exists, it has either to refer to the service description (and policies) or include it (and policies).

Thus, the relationships I would like to propose are:
1)	Service Description is a self-contained and consistent entity which describes different aspects of the SOA service (for the sake of logic here, I have postponed the description of these aspects)
2)	If a service provider exposes any number of policies onto the service consumers for particular SOA service, all such policies are available/accessible/referenced via the Service Description only
3)	For each service consumer, a Service Contract is identified. The Contract contains references to a subset of applied providers policies, as well as functional, operational, and run-time characteristics listed in the Service Description  all adopted to particular consumers needs. Plus, the Contract includes and/or references to all policies exposed by the consumer onto the service provider. There may be one Contract for many consumers or each consumer may have individual Contract.

Finally, a Service Description should include:
1)	business and/or programmatic interfaces that may be exposed to the consumer; the  Service Contract lists only those interfaces that are agreed upon with particular consumer
2)	service versions that may be exposed to the consumer; the  Service Contract includes only those versions that are agreed upon with particular consumer
3)	Policies applied by service provider
4)	Service behavior characteristics in normal conditions
A Service Contract may include:
1)  Policies required by service consumer
2)  agreed QoS characteristics  performance expectations (expected response time, throughput, etc.), scalability, failover, error handling and alerts, business (process) exceptions (different from technical exceptions), pre-known conditions (like delivery schedule) 
3)	service priority  different for different categories of the customers 
4)	additional provider obligations to the consumer(s) 


In Section 1.1 -  Policy/Contract Language  A policy and/or contract language is defined by a policy/contract language model. 
I suggest the contract language model has to encapsulate policy language model. 


In Section 1.2 - Mechanisms Supporting Policies and Contracts  The common policy architectural elements that are provided in this section are based on the minimal mechanisms required to provide policy guided delivery across distributed services within an ownership domain and between ownership domains. The same mechanisms can provide compliance assurance and/or auditing of contractual obligations between participants. 
I would agree with this if ALL elements/entries of the Contract are represented in the form of a policy. Otherwise, the statement is argumentive.  


Cheers,
- Michael Poulin