Services

In the every day world around us services are and have been commonplace for as long as civilized history has existed. Any person carrying out a distinct task in support of others is providing a service. Any group of individuals collectively performing a task in support of a larger task is also demonstrating the delivery of a service.

Figure 1 – Three individuals, each capable of providing a distinct service.

Similarly an organization that carries out tasks associated with its purpose or business, is also providing a service. As long as the task or function being provided is well defined and can be relatively isolated from other associated tasks it can be distinctly classified as a service.

Figure 2 – A company that employs these three people can compose their capabilities to carry out its business.

Certain baseline requirements exist to enable a group of individual service providers to collaborate in order to collectively provide a larger service. The above figure, for example, displays a group of employees that each provide a service for ABC Delivery. Even though each individual contributes a distinct service, for the company to function effectively, its staff also needs to have fundamental, common characteristics, such as availability, reliability, and the ability to communicate using the same language. With all of this in place, these individuals can be composed into a productive working team. Establishing these types of baseline requirements is a key goal of service-orientation.

Services in Business Automation

In the world of SOA and service-orientation the term “service” is not generic. It has specific connotations that relate to a unique combination of design characteristics. When solution logic is consistently built as services and when services are consistently designed with these common characteristics, service-orientation is successfully realized throughout an environment.

For example, one of the primary service design characteristics explored as part of this study of service-orientation is reusability. A strong emphasis on producing solution logic in the format of services that are positioned as highly generic and reusable enterprise resources gradually transitions an organization to a state where more and more of its solution logic becomes less dependent on and more agnostic to any one purpose or business process. Repeatedly fostering this characteristic within services eventually results in wide-spread reuse potential.

Consistently realizing specific design characteristics requires a set of guiding principles. This is what the service-orientation design paradigm is all about.

Services are Collections of Capabilities

When we discuss services, it is important to remember that a single service can provide a collection of capabilities. They are grouped together because they relate to a functional context established by the service. The functional context of the service illustrated in the figure below, for example, is that of “shipment.” Therefore, this particular service provides a set of capabilities associated with the processing of shipments.

Figure 3 – Much like a human, an automated service can provide multiple capabilities.

A service can essentially act as a container of related capabilities. It is comprised of a body of logic designed to carry out these capabilities and a service contract that expresses which of its capabilities are made available for public invocation.

Note that when we make reference to service capabilities on this site, we are specifically focused on those that are defined as part of the service contract. When services are implemented as components these capabilities are typically referred to as “methods,” and when they are expressed as part of a Web service contract, they are called “operations.”