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

between a service requester and a service provider; other items of metadata
describe the network address for the service, the operations it supports,
and its requirements for reliability, security, and transactional integrity.
However, developing a service is quite different from developing an object
because a service is defined by the message it exchanges with other services,
rather than a method signature. A service usually defines a coarse-grained
interface that accepts more data in a single invocation than an object because
of the need to map to an execution environment, process the XML, and often
access it remotely. Services are executed by exchanging messages accord-
ing to one or more supported message exchange patterns (MEPs), such as
request/response, one-way asynchronous, or publish/subscribe. Services are
meant to solve interoperability problems between applications and for use
in composing new applications or application systems, but not meant like
objects to create the detailed business logic for the applications.
From a business perspective, services are IT assets that correspond to
real-world business activities or identifiable business functions that can be
accessed according to the service policies related to
• Who is authorized to access the service
• When can the service be accessed
• What is the cost of using the service
• What are the reliability levels of using the service
• What are the performance levels for the service
A service is normally defined at a higher level of abstraction than an object
because it is possible to map a service definition to a procedure-oriented lan-
guage, such as COBOL or PL/1, or to a message queuing system such as JMS
or MSMQ, as well as to an object-oriented system such as J2EE or the .NET
Framework. Whether the service's execution environment is a stored proce-
dure, message queue, or object does not matter; the data are seen through
the filter of a Web Service, which includes a layer that maps the Web Service
to whatever execution environment is implementing the service. The use of
XML in Web Services provides a clear separation between the definition of
a service and its execution so that Web Services can work with any software
system. The XML representation of the data types and structures of a service
via the XML schema allows the developer to think solely in terms of the data
being passed between the services without having to consider the details
of the service's implementation. This is quite in contrast to the traditional
nature of the integration problem that involves figuring out the implementa-
tion of the service in order to be able to talk to it.
One of the greatest benefits of service abstraction is its ability to eas-
ily access a variety of service types, including newly developed services,
wrapped legacy applications, and applications composed of other newer and
legacy services.