Anatomy of a Web Service Contract

Page 2 of 5

What is a Web Service Contract?

A Web service contract is essentially a collection of metadata that describes various aspects of an underlying software program, including:

  • the purpose and function of its operations
  • the messages that need to be exchanged in order to engage the operations
  • data models used to define the structure of the messages (and associated validation rules used to ensure the integrity of data passed to and from the messages)
  • a set of conditions under which the operations are provided
  • information about how and where the service can be accessed

Figure 4.1 A Web service contract defines what a service offers and how and where it can be accessed.

Several different and cooperating technologies are required to formally define this metadata, as explained later in the Technologies Used to Create Web Service Contracts section.

Fundamental Structure

Web service contracts are organized into a basic structure that reflects a relatively clear separation of “what,” “how,” and “where” as follows:

  • What is the purpose of the service and its capabilities?
  • How can the service be accessed?
  • Where can the service be accessed?

When potential consumer program designers evaluate a service, they need to know what the service is capable of doing and under what conditions it can carry out its capabilities. If what’s offered is what consumer designers need, then they must be able to determine how and where to access the service.


Figure 4.2 An abstract description establishes the technical interface independent of implementation details. A concrete description adds deployment-specific details about how and where to access a service.

As illustrated in Figure 4.1, the service contract is organized into sections that individually address these three questions.

In addition to providing flexibility as to how a service can be located and consumed, this clean separation allows different parts of the contract to be owned and developed at different stages of the service delivery lifecycle by different members of a project team.

For example, architects and analysts can focus solely on the “what” part of a service when it is being conceptualized and designed. The “how” and “where” parts don’t usually become relevant until developers actually build and deploy the contract as part of the overall service implementation.

Abstract and Concrete Descriptions

There are formal terms used to represent the three fundamental parts we just covered. As shown in Figure 4.2, the “what” portion of the Web service contract is referred to as the abstract description. This part is essentially responsible for expressing the contract’s public interface (or API).


The terms “abstract description” and “concrete description” originated with the W3C, the standards organization responsible for developing most of the technologies covered in this book. From an implementation perspective, the abstract description is also very much concrete in that it ends up forming the actual physical interface that service consumer programs end up connecting to.

The balance of the Web service contract is represented by the concrete description, providing the implementation and communication details necessary for consumer programs to locate and use the service at runtime.

The concrete description encompasses the previously described “how” and “where” parts. An example of a characteristic that would be considered a “how” part is the wire format and protocol necessary to exchange messages with the service.


  • The term “abstract description” is commonly used to refer to the “what” part of the contract, whereas the term “concrete description” represents both the “how” and “where” parts.
  • Abstract and concrete descriptions are frequently created during different stages of the service delivery lifecycle by different members of the project team.
| 1 2 3 4 5 Page 2
ITWorld DealPost: The best in tech deals and discounts.
Shop Tech Products at Amazon