Section 1.3. What Is a Service?

1.3. What Is a Service?

In everyday life, you can point to many metaphors with which you can associate the concept of a service. These might include utilities such as water, gas, telephone, or electric, in addition to credit card services, transportation, travel agents, instant messaging, Internet service providers, search engines on the Web, and so on. These services represent some sort of publicized package of functionality. They are composeable. For example, a travel agent makes use of transportation (airline and rental car) and credit card services. Services are discoverable based on their descriptions, terms and conditions for use, and so on, based on metadata that fully describes the service. Actual use of a service is often based on an agreed-upon contract with the provider, including what in detail is provided and what the associated quality of services are, such as availability, cost, and other specified conditions that govern its use. Generally speaking, the user of the service requires little or no knowledge as to the specifics of how the service is implemented or how it is provided. The following sections relate these characteristics and apply them to software services.

1.3.1. Evolution of Major Software Granules

The idea of packaging software into artifacts that have a wider context, use, and applicability than a single application has been given a lot of attention since the early days of computing. This objective also relates to more flexible units of deployable software. Additional benefits are derived through separation of concerns, which leads to a significantly better understanding of the overall anatomy of complex software systems. This in turn enables improved software development methodologies necessary for tackling today's complex problems, in addition to improvements in software maintainability. Over the past decades, the ideas that have been applied to this problem have evolved quite significantly.

Functions and Packages

One of the first attempts to decompose software was centered on functional decomposition that resulted in functions or subroutines as individual software units. Such a unit offers coherent functionality that you can easily understand and build. This decomposition into functions enables modularization of software systems. However, this approach frequently brings about partial simplification that can only address simple problems. Added value comes with aggregations of related functions that help solve more complex tasks that are associated with a particular problem domain. Such approaches have, for example, been pioneered by Ada in the form of packages.

Objects and Classes

A package is a mere syntactic unit. To improve on and extend this concept further, the notion of a class evolved. A class describes the behavior of objects from a problem domain; therefore, it carries certain semantics in addition to being a syntactic unit combining functions and data. Classes, together with the concept of polymorphism and inheritance, have turned out to be a powerful concept for building software. Polymorphism allows the resulting software to become more flexible, whereas through inheritance, class lattices can be built that stimulate reuse and ease communication among developers within a given community.

Although classes represent objects and carry some semantics, a class lattice mostly captures syntaxnamely, the signature of the functions aggregated. The semantics that a class lattice captures are typically understood only within a limited community, such as a development team. Few class lattices are known, the semantics of which are shared across larger communities.

In contrast to this, services are described not only via their interfaces, but also via business terms. Thus, the semantics that a service description provides go beyond that of a class and a class lattice. As such, services support comprehension by much broader communities.

Components

Besides being coarser than objects and classes, components go further by dealing with deployment. Addressing the issue of deployment allows a component provider to focus specifically on application logic, while qualities of services are folded in by the runtime environment that is hosting the component. For that purpose, quality of service requirements are factored and parameterized by deployment descriptors [J2EE]. By setting appropriate values in the deployment descriptors, you specify the behavior of a component with respect to such things as transactions, security checking, state management, and so on. In addition, you can resolve dependencies on other components and resources (such as databases and queues) via deployment descriptors. Finally, you can set up values governing application-specific context (such as local tax rates) via deployment descriptors.

Dealing with these aspects of deployment eases customization. You can tailor a piece of application logic to a company's specific use by setting values in deployment descriptors accordingly. The container that is hosting the application logic interprets the deployment descriptors and ensures the specified behavior. For a customized context that the application logic requires, the deployment descriptor provides the standardized contract. Deployment descriptors enable components to become tradeable artifacts.

1.3.2. The Software Version of a Service

Services represent another step forward in the evolution of software packages. Services can provide an abstraction of specific component models, allowing users of these components to think only in terms of Web services and ignore specific details of the component model and how it its implemented. For example, services can hide the details about whether the component is a J2EE-based component or a .NET based component. This provides significantly enhanced interoperability between computing platforms that have programming models based on these differing component models, such as WebSphere and .NET.

Characteristics of a Service

A service is available at a particular endpoint in the network, and it receives and sends messages and exhibits behavior according to its specification. The service has specific functionality and is deployed with appropriate quality of service at the endpoint. (For example, the service is set up with certain transactional or security or reliable messaging behavior.) The functional aspects of a service are specified using WSDL, and the constraints and conditions that are associated with the use of the service are specified via policies that you can attach to various parts of the WSDL (see chapter 7). Interfaces and policies describe the terms and conditions that govern the use of the service. These are published so that potential users of the service can discover and be given all the information they need to bind (perhaps dynamically) to that service.

The information that is published about a service provides details of what the service is and does (its semantics). It further provides all the information that allows the environment hosting a potential user to access the service and successfully interact with it. This can include information about the transport protocols that can be supported and used to send a messages to the service, the wire format of this message expected by the service, whether and how the message has to be encrypted or signed.

Although the environment that is hosting needs this information, the requester doesn't need this kind of access information, and it certainly doesn't need to understand details about the implementation of the service. You can implement this service as an EJB, a database stored procedure, or a CICS or IMS transaction made available via a wrapper. The environment that is hosting the service and receiving the request message, often referred to as a container, must deal with that detail necessary to interact with a particular implementation. The requester can think in terms of using a Web service. In that sense, Web service technology is virtualization technology for making use of services, but an implementer of a service can use the technology he is acquainted with to build the service implementation.

SolutionsComposition of Services

One valuable aspect of the services model is that you can create new services from existing ones without leaving the service paradigm. A technology called choreography facilitates the composition and orchestration of the execution of existing services to create more powerful ones (see Chapter 14, "Modeling Business Processes: BPEL"). Choreographies support the idea of programming in the large (see [Ley 2004], [Ley 1997], [Wied 1992]), which fosters the creation of new functionality, in particular by non-IT personnel.

Using the terminology introduced earlier, a business process corresponds to the choreography of services designed to address a high-level business problem. The choreography specifies which services to use, in which order, and under which conditions. Services within the choreography correspond to an activity, some kind of well-identified step in the process. You can define the choreography as a service and incorporate it as an activity within another choreography, again, providing functions from the business domain of a company. Because the collection of services and the choreography that uses them solve a business problem, this collection is sometimes called a solution [BaS04]. Without examining the detail, note that a solution typically contains additional artifacts, such as user interfaces or more complex rules that the choreography uses (see Figure 1-3).

Figure 1-3. The concept of a solution.

Choreographies use services and render the results as services again. Therefore, one choreography can serve as a base for other choreographies, together with services that have been implemented based on other technologies. Thus, choreography provides a powerful technology for recursive composition of services.