RE: [soa-rm] Policies and Contracts - notes for currrently posted document

["Smith, Martin" <Martin.Smith@DHS.GOV>]

Michael -- 
 
A good discussion --thanks.  It gave rise to a couple of thoughts:
 
1.  Contracts are (typically) private between buyer and seller. Except that the contracts have to be made available to third parties (courts, arbitrators) for dispute resolution and enforcement.  I wonder if contract "instances" are a property of services at all. 
2.  "Internal" policies are private to an organization (or individual, if you like), and represent documented guidelines for doing business and/or goals, presumably subject to waiver or revision via internal decision processes. I don't see that they are of any particular relevance to the external (observable) behavior of a service.  And maybe not to the RA.
3.  "External" (advertised) policies are really just a starting offer to the public in negotiation of a contract. The car dealer may have a "policy" of a maximum 10% discount for cash, but the salesman's invisible manager can probably cut a deal if it's the end of the month.
4.  There seem to be several OASIS (and other) activities dealing with policies and contracts. We should try to figure out if we are doing anything special in SOA-RM that requires a distinct language, or which of the other efforts is best suited to RA needs.
 
Regards,
 
Martin
 
Martin F. Smith
Program Manager, Information Sharing & Identity Management
DHS CIO Office
202 447-3743 (New! as of 10/2006)
202 441-9731 cell
 

________________________________

From: soa-rm-return-310-martin.smith=dhs.gov@lists.oasis-open.org on behalf of michael.poulin@uk.fid-intl.com
Sent: Mon 2/19/2007 2:22 PM
To: soa-rm@lists.oasis-open.org
Subject: [soa-rm] Policies and Contracts - notes for currrently posted document



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