Concept: Service
The service concept can be used to model generic systems, as well as ones that are specialized to IT.
Relationships
Main Description

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.