[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm-ra] about contract for the Management Model section
Michael, see below From: mpoulin@usa.com
[mailto: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, results and SLA, 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 requirements. In
the case of business to business services, it is anticipated that the service contract may
take an explicit form and the agreement between different
businesses 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. The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]