RE: [soa-rm-ra] about contract for the Management Model section

[Ken Laskey <klaskey@mitre.org>]

 

 

---------------------------------------------------------------------------

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: Tuesday, March 22, 2011 6:07 AM
To: soa-rm-ra@lists.oasis-open.org
Subject: [soa-rm-ra] about contract for the Management Model section

 

Hello All,

here is the re-worded fragment of the Management Model section related to the contracts based on the recent e-mail exchange . Please, review it before I place it into the section text.

 

- Michael

 

As described in sections “Participation in a SOA Ecosystem view” and “Realization of a SOA Ecosystem view”, there are several types of contractual information in the SOA ecosystem. From the management perspective, three basic types of the contractual information 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 When a consumer prepares to interact with a service, the consumer and the service provider must come to agreement on service features and characteristics that will be provided by the service and available to the consumer; this agreement 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 consistent with identified real world effects as well as on the a commitment by a service consumer to interact with the service per specific means and per specified policies, where both consumer and provider actions are in the manner described in the service description.

 

[kjl] Michael, this paragraph mixes two things and I’m don’t have time right now to work a polished set of suggestions.  Basically, the service description may identify alternatives.  This is independent of whether we end up with an implicit or explicit contract.  The actions of the participants can indicate the alternative chosen without an explicit contract.

The service description provides the basis for the service contract and, in some situations, a service description may be used as an implicit default service contract.  In addition; in other situations, the service description may be set as a mandatory service contract, e.g. for security services or may specify acceptable alternatives. In the case of business services, it is anticipated that the service contract may take an explicit form and the agreement between business consumer and business service provider is formalized. Formalization requires up-front interactions between service consumer and service provider. For instance, As an example of alternatives, 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. 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.  In each of these cases, the actions of the participants are consistent with an implicit service contract without the existence of a formal agreement between the participants. 

 

In the case of business services, it is anticipated that the service contract may take an explicit form and the agreement between business consumer and business service provider is formalized. Formalization requires up-front interactions between service consumer and service provider. In many business interactions, especially between business organisations within or across corporate boundaries, a consumer needs a contractual assurance from the provider or wants to use only a subset of the business functionality offered by the service and pay a prorated cost for this, which is possible to set via an explicit contract.

 

So, an implicit service contract is an agreement (1) on the consumer side with the terms, conditions, features and interaction means specified in the service description "as is" or (2) a selection from alternatives that are made available through mechanisms included in the service description, and neither of these that do not require any a priori interactions between the service consumer and the service provider. An explicit service contract always requires a form of up-front interaction between the service consumer and the service provider regarding the choice or selection of the subset of the elements of the service description or other alternatives introduced through the formal agreement process that would be applicable to the interaction with the service and affect related joint action.

 

[kjl] This misses the point that the coupling is traditional and may be needed under certain conditions but most of life is implicit.  Even your return example is implicit because requiring identification has not been explicitly agreed in advance and the consumer providing ID is just following through on the implicit agreement.

Any form of explicit contract couples service consumer and provider. While explicit contract may be necessary or desirable in some cases like in the supply chain management, there is a model that mixes implicit and explicit contracts. Particularly, a service provider may offer (via service description) a conditional shift from implicit to explicit contract. That is, a consumer has a choice whether to stay operate with implicit contract or to meet the condition and enter into an explicit contract that may be associated with certain fees to pay. For example, Twitter offers an implicit contract on the use of its APIs to any application with the limit on the amount of service invocations; if the application needs to use more invocations, one has to enter into the explicit contract with the provider. A well-known business example is when a consumer buys some goods in a shop using implicit contract, i.e. being agree with the shop policies and prices. However, when the purchased goods are returned, the shop enters into the explicit contract with the consumer requiring its identity and address submission.

 

smime.p7s