WebServices dot org

Why WSDL (Still) Works

Early Web Services toolkits encouraged developers to use SOAP (usually employing the SOAP-RPC convention) to invoke methods on remote objects in a classic client-server pattern as shown in Figure 1.

This familiar analogy was echoed by Web Services development toolkits. WSDL interfaces were used to generate class skeletons and stubs, WSDL operations were treated as being analogous to object methods, and Web Services development paralleled the development of distributed object systems.

However Web Services have evolved from being a platform independent RPC mechanism to a fully fledged global scale computing fabric. As experience grew and tooling improved, the consensus of opinion was that a move to service-orientation as the underlying architectural paradigm which, coupled with appropriate programming models, might avoid some of the problems associated with large-scale distributed object-based systems.

SOAP and WSDL are the two fundamental Web Services technologies have been around for the whole trip. While SOAP has managed is transition from RPC ugly duckling to message-format swan, WSDL has managed to keep a distinctly API-ish flavour even in its most recent iteration, WSDL 2.0. However, while WSDL has kept much of it API-oriented heritage, it is not necessarily a poor fit with modern Web Services practices. This article will explore some of the motivations behind the WSDL 2.0 specification and demonstrate that it can be used to support architectures based around message-passing.

Plain Old Message Passing

The legacy of the last few decades of distributed computing, where abstractions like “procedure calls” in RPC systems, “methods” in distributed object-based systems, “operations with uniform semantics” in REST, etc. has led to the assumption that Web Services must also support similar concepts, usually referred to as “calls”, “operations”, or “actions”. Put differently, there exists a false impression that services are “callable” entities and the fact that WSDL uses terms like “interfaces” and “operations” has helped to promote this view.

There is a significant faction within the community that follows the doctrine that Web Services support operations are real and tangible, have expected semantics, and whose behaviour can be reasoned about by external consumers. However, there is a similarly committed set of thinkers that believes in treating Web Services architecture as an instance of the message passing paradigm where the internals of a Web Service are treated as a black box and whose only externally visible aspect is the message exchanges it participates in.

Perhaps nowhere is the friction between these two faiths more obvious than in WSDL 2.0 whose operation versus message-exchange schizophrenia is only matched by type system versus document constraint language duality in XML Schema. However even with its strong syntactic emphasis on treating Web Services as entities with callable operations, WSDL 2.0 is still an important piece of equipment in the Web Services toolbox and, with a little thought, can in fact be used to promote the explicit message-passing approach that enables loose-coupling rather than the method-call view which shatters it.

Old Dog, New Tricks

While the syntactic elements used by WSDL are reminiscent of the Web Services as distributed objects approach (interface, operation), WSDL is itself independent of the implementation of the Web Services it describes (indeed some Web Services won’t even have a WSDL contract). With some imagination (or an XSLT stylesheet) WSDL can be conceptualised as a contract definition language – not something that defines methods and interfaces, but an article which defines messages and message exchange patterns. To clarify, consider the WSDL 2.0 fragment presented in Figure 2.

One interpretation of this interface might be that each operation is an explicitly callable entity, which can be distinguished from all other operations irrespective of the underlying message exchanges. Each operation has some semantics that the consumer demands must be executed. In order to achieve this, the WSDL contract needs some way of telling consumers how to encode which operation they want to invoke into the underlying message exchanges so that there is a shared of understanding between the Web Service and consumer. Under such a regime, a consumer might perceive the WSDL shown in Figure 2 as the moral equivalent of a set of methods:

However, conceptualising Web Services as objects with methods is sub-optimal. Web Services exist and evolve independently of their contracts. To couple a Web Service implementation to its contract by directly implementing the WSDL-defined operations in your Web Services code or by advertising your services internal dispatch mechanism (via mechanisms like soap:action) to enable explicit method selection makes little sense and adds to the maintenance burden.

So what does this pseudo-WSDL contract really mean?

The interface part of the contract should be read as a whole, not as a piecemeal operation-by-operation description. It means that if you send a MessageA to the Web Service, it will return to you a MessageX, a MessageY, or a MessageZ. The consumer application might prefer to receive a MessageX, in which case the MessageA it sent must be of the correct form and content to enable the service to produce its MessageX as a response (developers may need to read the service's documentation for that). However, all that consumers of a Web Service know is that they can expect MessageX, MessageY, or MessageZ in response to sending a MessageA. This could be reduced to the following pseudo-code:

This isn't a big deal either for humans or tools. The wsdl:interface section of the contract is examined to determine its constituent messages and message exchange patterns. From that it can be determined that after sending a MessageA, expect a MessageX, a MessageY, or a MessageZ in response. Of course a Web Service could advertise a WSDL contract which has a single operation which accepts a suitably constrained xsd:choice as its inputs and outputs. This would work too, but it would be preferable if WSDL just did the right thing.

Thus a Web Service is simply an actor that sends and receives messages. If the view of a “callable” entity is thought beneficial, then a service should be seen as an entity that supports a single logical operation, called “ProcessMessage.” This operation is responsible for taking delivery of the message from the network and making it available to the service for processing. This abstract operation exists only at the architectural level and has the uniform semantics across all services:

When a Web Services-based application is developed, the “ProcessMessage” operation is replaced by an appropriate mechanism from the underlying transport technology (e.g., socket receive(), SMTP commands, HTTP POST/GET, etc.) but the semantics of message transfer remain the same.

Conclusions

Web Services are an application of the explicit message-passing paradigm. The notion of treating Web Services as black boxes that accept and emit SOAP messages is appealing. Such a model allows Web Services-based systems to be designed in terms of high-level message exchanges that model business documents and corrals architects into thinking in business- rather than implementation-level abstractions. It also permits Web Services’ implementations to evolve independently of their consumers since they are mutually decoupled by the underlying message exchanges.

WSDL is a contract definition language which can be used by a Web Service to advertise the format of the messages it understands and the message-exchange patterns that it supports. This usage pattern initially requires careful thinking during its application since the keywords which WSDL uses are not conducive to thinking in such terms. However the benefits that such loose-coupling provides are worth any initial cognitive outlay in bending WSDL to suit message-passing.

Acknowledgements

Some parts of this article derive from a chapter of a forthcoming MIT press book “Readings in Service-Oriented Computing: the Web-Services Phenomenon. The chapter “Realising Service-Oriented Architectures with Web Services” was jointly authored with Savas Parastatidis (http://savas.parastatidis.name), who also provided valuable feedback during the preparation of this article