Service-Oriented Architecture - Guide to Cloud Computing for Business and Technology Managers - page 159

consequently, the service contract is independent of any single service
implementation. The service contract is defined based on the knowledge of
the business domain and not so much on the service implementation. The
service contract is defined and managed as a separate artifact, is the basis
for sharing and reuse, and is the primary mechanism for reducing interface
coupling.
Changing a service contract is generally more expensive than modifying
the implementation of a service because while changing a service implemen-
tation is relatively a localized effort, changing a service contract may entail
changing hundreds or thousands of service requesters.
7.3.5 Standard Based
Services should be based on open standards as much as possible to the
following benefits:
• Minimizing vendor lock-in by isolating from proprietary, vendor-
specific technologies and interfaces
• Increasing the choice of service requesters for alternate service pro-
viders and vice versa
It is important to base the service-level data and process models on mature
business domain standards as and when they become available. This is in
addition to complying with technology standards like SOAP, WSDL, UDDI,
and the WS* specification.
7.3.6 Granularity of Services and Service Contracts
Services and service contracts must be defined at a level of abstraction that
makes sense to service requesters as also service providers. To achieve this,
services should perform discrete tasks and provide simple interfaces to
encourage reuse and loose coupling.
An abstract interface at the appropriate level of granularity promotes
ready substitutability, which enables any of the existing service providers to
be replaced by a new service provider without affecting any of the service
requesters.
7.3.7 Stateless
Services should be stateless because they scale more efficiently as any service
request can be routed to any service instance. In contrast, stateful interac-
tions do not scale efficiently because the server needs to track which service
is serving which client and cannot reuse a service until the conversation is
finished or a time-out has occurred.