about contract for the Management Model section

[mpoulin@usa.com]

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 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 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 service description may be used 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 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, 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 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 on the consumer side with the terms, conditions, features and interaction means specified in the service description "as is" 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 that would be applicable to the interaction with the service and affect related joint action.

 

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.