Michael,
This captures a lot of the extended discussion we had last Thursday. A couple other points come to mind:
- Something on the order of the following needs to be said:
One of the often espoused benefit of applying SOA principles is the loose coupling between the providers and consumers. The emphasis is often on the technical coupling and the specifics of the interface through which the consumer and provider communicate. However, there is an equal danger of tight coupling through service contracts that may be point-to-point, binding a specific consumer to a specific provider for a specific set of interactions. The SOA view of management must consider how to standardize the processes and specifics of service contracts or risk losing many of the benefits a SOA implementation is expected to deliver.
- A great blog that highlights the change in thinking – I especially like having a section titles of “Dorothy, you’re not in Kansas anymore” and “The best way to avoid failure is to fail constantly” – can be found at http://techblog.netflix.com/2010/12/5-lessons-weve-learned-using-aws.html
- Instead of “a consumer may be allowed to use a service description as an implicit default service contract”, I ‘d suggest “a service description may be used as an implicit default service contract”. That would follow well the previous italicized text in your write-up. It could be followed with something like (which got longer as I started writing)
“In some cases, the service description may identify alternatives that the consumer may use, e.g. which versions of a vocabulary will be recognized, and the specifics of the contract are satisfied when the consumer uses one of the alternatives. In other cases, the service description may indicate mandatory policies, e.g. for security purposes, and the consumer satisfies the service contract by abiding by those policies. Another alternative could have a consumer identifying a policy they require be satisfied, e.g. a standard privacy policy on handling personal information, and a provider that is prepared to accept a policy request would indicate acceptance as part of the service contract by continuing with the interaction. (Note, a consumer should not assume such a request is accepted unless the service description indicates such requests can be accepted.) Numerous other alternatives are possible and are likely to evolve as variety of use of the SOA ecosystem grows.”
- The idea of “An explicit service contract alway always requires a form of up-front interaction” needs to be softened a bit to be consistent with the examples I gave above. The consumer is certainly aware a priori of the vocabulary alternatives and decides it is possible to comply, but the provider doesn’t know about the consumer’s decision until the moment of the interaction with the service. There is no real need for the consumer to announce this in advance.
- There are certainly situations where an explicit contract is appropriate in advance, and nothing I’ve said above is meant to preclude that. However, that does result in tight coupling through the contract and the participants really need to consider to what degree that is necessary or how a different approach may lead to a more robust solution.
- A nit: priory should be replaced with a priori
Ken
---------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
From: mpoulin@usa.com [mailto:mpoulin@usa.com]
Sent: Saturday, March 19, 2011 10:35 AM
To: soa-rm-ra@lists.oasis-open.org
Subject: [soa-rm-ra] service contract
Hi All,
executing the assigned action set in the last meeting, let me represent a fragment of Management Model section related to the service contract. It sets 3 types of the contracts (that discussed later in the section) and 3 definitions that are the key to the rest of related discussions
So, here is the fragment:
As described in sections “Participation in a SOA Ecosystem view” and “Realization of a SOA Ecosystem view”, there are several types of contracts in the SOA ecosystem. From the management perspective, three basic types of the contracts relate to:
· relationship between service provider and consumer;
· communication with the service;
· control of the quality of the service execution.
Before a service is invoked the first time, SOA ecosystem assumes that the consumer gets into agreement with the service provider about the service features and characteristics that will be provided by the service and available to the consumer; this contract is known as a service contract:
a service contract is an implicit or an explicit and documented agreement between the service consumer and service provider about the use of the service based on the commitment by a service provider to provide service functionality and results, and realize real world effects as well as on the commitment by a service consumer to interact with the service in the manner described in the service description.
In some situations, a consumer may be allowed to use a service description as an implicit default service contract; in other situations, the service description may be set as a mandatory service contract, e.g. for security services. In the case of business services, it is anticipated that the service contract is explicit and the agreement between business consumer and business service provider is formalized. So, an implicit service contract is an agreement on the consumer side with the terms, conditions, features and interaction means specified in the service description "as is" that do not require any priory interactions between the service consumer and the service provider. An explicit service contract alway requires a form of up-front interaction between the service consumer and the service provider regarding the choice or selection of the subset of of the elements of the service description that would be applicable to the interaction with the service and affect related joint action. The examples of the explicit service contracts are: 1) a consumer can choose which one of the offered policy alternatives or interface alternatives the consumer wants to use in the service interaction; 2) a consumer wants to use only a subset of the business functionality offered by the service and pay a prorate cost for this.
Please, send me your comments that I would be able to incorporate them into the materials for the next meeting.