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
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.
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.
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.
SUMMARY OF KEY POINTS
- 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.