This chapter is from the book
This chapter is from the book
This chapter is from the book
3.4 Service Description
Service description defines metadata that fully describes the characteristics of services that are deployed on a network. This metadata is important, and it is fundamental to achieving the loose coupling that is associated with an SOA. It provides an abstract definition of the information that is necessary to deploy and interact with a service.
3.4.1 WSDL
Web Services Description Language (WSDL) is perhaps the most mature of metadata describing Web services. It allows developers to describe the "functional" characteristics of a Web service—what actions or functions the service performs in terms of the messages it receives and sends. WSDL offers a standard, language-agnostic view of services it offers to clients. It also provides noninvasive future-proofing for existing applications and services and allows interoperability across the various programming paradigms, including CORBA, J2EE, and .NET.
WSDL is an XML format for describing (network) services as a set of endpoints that operate on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate.
A WSDL document has two parts: abstract definitions and concrete descriptions. The abstract section defines SOAP messages in a language- and platform-independent manner. In contrast, the concrete descriptions define site-specific matters such as serialization.
WSDL provides support for a range of message interaction patterns. It supports one-way input messages that have no response, request/response, and one-way sends with or without a response. The last two patterns enable a service to specify other services that it needs. WSDL is discussed in detail in Chapter 6, "Web Services Description Language."
3.4.2 Policy
Although WSDL and XML Schema describe what a service can do by providing a definition of the business interface (including business operations such as open/close account, debit/credit/transfer, and so on), they do not provide information about how the service delivers its interface or what the service expects of the caller when it uses the service. How the service implements the business interface, the sort of permissions or constraints it expects of or provides to requesters, and what is expected or provided in a hosting environment is incredibly important in ensuring the correct interaction with and execution of the service. For example, does the service require security, and if so, what specific scope and type? Does it support transactions? What outcome protocols are supported? To achieve the promise of an SOA, it is important to extend the current Web service interface and message definitions to include the expression of the constraints and conditions that are associated with the use of a Web service.
Although you can use inherent extensibility of XML and WSDL to achieve some of these requirements, a much better approach is to define a common framework for Web services constraints and conditions that allows a clear and uniform articulation of the available options. Such a framework must enable those constraints and conditions associated with various domains (such as security, transactions, and reliable messaging) to be composeable, so that Web service providers and consumers are not burdened with multiple domain-specific mechanisms. Also, such a framework can provide support for determining valid intersections of constraints and conditions, where multiple choices are possible. Although the programming that is implementing the business logic of the Web service can deal explicitly with the conditions and constraints, providing a declarative model for this factors such issues out of business logic, thereby providing an important separation of concerns. This allows for more automated implementation by middleware and operating systems, resulting in significantly better reuse of application code by the organizations that provide, deploy, and support Web services. The WS-Policy family of Web services specifications provides an extensible framework that is intended to specifically deal with the definition of these constraints and conditions.
The WS-PolicyAttachments specification offers a flexible way to associate policy expressions with Web services. The WS-Policy specification defines a common framework for services to annotate their interface definitions to describe their service assurance qualities and requirements in the form of a machine-readable expression containing combinations of individual assertions. The WS-Policy framework also allows the use of algorithms to determine which concrete policies to apply when the requester, provider, and container support multiple options. WS-Policy is critical to achieving interoperability at the higher-level functional operation of the service. Security, transactions, reliable messaging, and other specifications require concrete WS-Policy schema. This allows services to describe the functional assurance that they expect from and provide to callers.
The WS-Policy specifications are discussed in detail in Chapter 7, "Web Services Policy."