A service is an offer of value to another through a well-defined interface. A service results in work provided to
one by another.
Several organizations provide formal definitions of "service". Appendix B of the SoaML specification tabularizes
several of these, and includes this definition from the specification itself:
Service is defined as a resource that enables access to one or more capabilities. Here, the access is provided using
a prescribed interface and is exercised consistent with constraints and policies as specified by the service
description. A service is provided by an entity, called the provider, for use by others. The eventual consumers of the
service may not be known to the service provider and may demonstrate uses of the service beyond the scope originally
conceived by the provider.
An IT-centric definition might be as follows:
A service is a discoverable software resource with an externalized service specification. This service
specification is available for searching, binding, and invocation by a service consumer. The service provider realizes
the service specification implementation and also delivers the quality of service requirements to the service consumer.
Services shall be governed by declarative policies and thus support a dynamically re-configurable architectural
style.
The following paragraphs expand upon some key words in the above IT-centric description of the concept.
Discoverable
Services are not a part of a monolithic application architecture. They exist independently at run time from any and all
other services within a given solution. This means that we require a method for the registration and discovery of
services based on criteria such as the ServiceInterface it realizes, its service Participant, as well as other
business and technical classifications. This discovery process might take place during development time to match given
services to supporting services, or it might take place at run time to enable the dynamic provisioning of services
(mediated invocation). To be discoverable, a service must provide a set of meta-data that allows categorization. This
meta-data is a part of the external specification.
Externally Specified
The external specification allows for a service to publish its details such as interface, location, policies,
classifications, and so on without the need for a client to have access to the service itself. Such information is then
usually stored in a known location or specialized service registry that supports queries of the meta-data. Currently in
the Web Services world, the accepted standard for the description of service interfaces is WSDL (Web Services Description Language), which comes from the World Wide Web Consortium.
The service specification work product is actually a combination of three parts: the interface, behavior, and policy
specification. As such, the realization of these different aspects requires more than simply the interface definition
provided by WSDL.
Contract-Based
In the glossary definition above, we noted that the service specification provides a view for both the service provider
and the service consumer. These views correspond to two halves of a contract that enables the clear separation of
the specification from implementation.
The following table describes how the different aspects of a service specification affect both the provider and
consumer of the specification.
Role
|
Interface Specification
|
Behavior Specification
|
Policy Specification
|
Provider
|
Informs the set of operations and messages the service must respond to. All operations must respond to and
reply with the correct messages.
|
Informs as to the behavior this service must support. If such behavior specification is formal and
complete, an implementation can be tested for conformance to the specification.
|
Informs as to a set of constraints which the service implementation might work under as well as a set of
qualities of service that must be realized.
|
Consumer
|
Informs the set of operations that might be invoked.
|
Informs as to the protocol requirements that the consumer must realize (operation ordering, data flows, and
so on). Also indicates any operations the consumer must implement to support collaborations.
|
Informs as to constraints that the consumer must be cognizant of, such as security requirements, in
communicating with this service. It also identifies the qualities of service a consumer can get from a
given provider.
|
Such a service specification can be seen as an application of Design by Contract.
Business Alignment
In general, business models representing the operations of the business and the design models for supporting IT
applications have been at best loosely connected. In most cases, they have been completely disconnected. While the RUP
does provide guidance on the transition from business models to system use case models (see the guideline Going from
Business Models to Systems), the connection requires a number of transformations as the level of granularity and
abstraction changes from the business to IT perspectives.
One important aspect of SOA is that the level of granularity of services described in a service-oriented solution is
such that the operations provided by services can often be identified at a business level. This increase in the level
of granularity in supporting IT means that, in many cases, tasks identified in business-process models can be directly
realized as operations on services. Therefore, the business users of IT solutions become much more a part of the
analysis and design process.
|