Section 6.3. Architectural Concepts

6.3. Architectural Concepts

WSDL is designed around a few core concepts. These core concepts are discussed next.

6.3.1. Extensibility

It is easy to get carried away with a machine-processable language for describing a service. Some things are absolutely critical, such as the format of the data to be exchanged, the way those messages should be sent, and their destination. Going beyond such minimalist thinking, you could argue that a description language worth its weight should allow you to describe how much it costs to use the service, what the security characteristics are, and so on. The problem, of course, is where to stop.

WSDL avoids this problem by limiting itself to being a language to describe a few key aspects of a service: the message formats, the message interaction patterns, the way the messages should be represented "on the wire," and where those messages should be sent. Everything else is left out.

However, those elements are not omitted forever. WSDL (and, in fact, many of the Web services specifications) carefully supports the notion of extensibility. That is, someone who wants to indicate the price for using the service can do so with WSDL. He must invent the appropriate language syntax and insert it at the right place in WSDL. The problem of how to indicate the price for an arbitrary service is left for others to solve.

Thus, the principle of extensibility in WSDL has allowed it to be as tightly defined as possible without excluding many other (perfectly valid and interesting) description capabilities.

6.3.2. Support for Multiple Type Systems

Within the world of XML schema definition languages are several candidates, including Document Type Definitions (DTDs), W3C XML Schema, and RelaxNG. Today, W3C XML Schema is a W3C recommendation and clearly the dominant XML schema definition language. However, in the days of WSDL 1.0, XML Schema was still a work in progress, and an even wider array of choices was available.

Coming from the NASSL legacy, it was WSDL's intent to be able to describe services whose data representation had nothing to do with XML. WSDL has even been used to describe services offered by mainframe computers in which the data is structured using COBOL copybooks. It has also been used to describe services whose data is structured using the widely popular MIME type system. In such cases, describing the services by first generating an XML representation of the data and then describing the XML form is a secondary form of description.

WSDL holds as a fundamental tenet that the messages the service can consume or produce might be described in just about any schema (or structure definition) language. As illustrated later, this tenet is achieved by the flexibility that is designed into the <types> and <message> elements of WSDL 1.1 and the Description and Interface Operation components of WSDL 2.0.

At the same time, to support the creation of an interoperable universe of Web services, WSDL directly supports the W3C XML Schema language. If a service is to be offered for public consumption, it should be described using W3C XML Schema, because that greatly increases the likelihood that an interested consumer will understand the service description.

6.3.3. Unifying Messaging and RPC

The world of system integration can be broken down into two broad camps: those that believe distributed object systems are the key, and those that believe message-oriented middleware is the key. Web services, as a unifying integration architecture, has to support both. That is, the description language has to support describing services that are of the RPC flavor in addition to those that are of the messaging flavor. In addition to implications for how the messages are defined, this requirement brings additional complexity in terms of the kinds of interactions that occur between the client and the server.

RPC systems are rather straightforward to describe. They are perfectly good languages for describing such systems that exist in the form of OMG IDL and MS IDL, for example. Messaging systems by themselves are also relatively straightforward to describe. The challenge is to cover both in one language without being overly clumsy. WSDL 1.1 and 2.0 have taken different approaches in solving this problem. WSDL 1.1 uses the <message> construct, and WSDL 2.0 prefers to layer the RPC interaction as a pattern of usage of a pure message system. Later sections of this chapter explain these in some detail.

6.3.4. Separation of "What" from "How" and "Where"

The first thing a client needs to know about a service is what it does. Then it needs to know how to use a service and where it is offered. That is the basic principle behind the way WSDL is structured. It separates what the service does (expressed in the form of <portType> in WSDL 1.1 and <interface> in WSDL 2.0) from how the service is to be interacted with (expressed in the form of <binding> in WSDL 1.1 and 2.0) and where the service is offered (expressed in the form of <port> in WSDL 1.1 and <endpoint> in WSDL 2.0).

This separation allows one description of what a service does to be offered in different forms of interaction at different locations. By describing the service first in terms of what it does (which is called the abstract service description) and then in terms of how to interact with it and where it is available, you maximize the opportunity to reuse the abstract service description and even the description of how to interact with a service.

6.3.5. Support for Multiple Protocols and Transports

Although many people think of SOAP as the only message format in Web services, WSDL carefully supports multiple ways to interact with a service. For example, the same service might be available over SOAP messages sent via HTTP at one location and over RMI/IIOP messages sent over TCP at another location.

The <binding> construct of WSDL exists to support this separation. A binding tells how to access a service via a specific communication protocol. WSDL does not restrict the set of protocol and transport bindings. It provides an extensible architecture to support any number of them. Even the protocol and transport bindings that are part of the standard specification are expressed using this extension architecture.

6.3.6. No Ordering

Services that WSDL describes typically offer some number of operations. However, the description does not indicate in what order to execute the operations. For example, if the operations are to log in, execute a query, and log out, only the human semantics of those words indicate the order in which to invoke the operations.

Such ordering is sometimes called the public process or abstract process of the Web service. WSDL does not address that problem. Business Process Execution Language for Web services, or BPEL (see Chapter 14, "Modeling Business Processes: BPEL"), includes the concept of abstract processes, which you can use for this purpose.

6.3.7. No Semantics

The scope of WSDL as a language for describing services is carefully limited to expressing what the service does only at a structural level. There is no attempt to capture service semanticsthat is, nothing is said about what the service does with the information that is sent. For example, if a service offers an operation called getQuote, just looking at the WSDL, you don't know whether this operation returns stock quotations, insurance quotations, or quotations for building a house.

The motivation for omitting semantics completely was that the field of semantic description is only at a research stage. What WSDL contains directly are things that are concrete and that have practical and well-defined usage patterns. Although semantic descriptions are omitted from WSDL accordingly, they are not left out forever because of extensibility.