WebServices dot org

The Tail does not Wag the Dog: A Cautionary Tale for Contract First Development

Usually the description of the message exchanges that a service supports is captured in a contract which in turn is advertised or shared with potential integration partners. A good contract describes the externally observed behaviour of the service – the structure of messages and the patterns in which those messages are exchanged – without exposing any of the implementation details like type system or physical structure of the service. A good contract enables loose coupling since a consumer can only bind to the information that a Web Service advertises and not directly to any aspect of the implementation of that service.

In the Web Services domain, WSDL has long been the only choice for authoring contracts. However, WSDL has not been faithful to the vision of a service-oriented Web Services ecosystem. While SOAP has managed to escape its object-centric beginnings, WSDL has stuck resolutely to a very RPC-like view of a Web Service.

While it might be heretical to some, WSDL has failed to reach escape velocity and has settled into a distinctly object IDL orbit [1] . The Web Services community at large seems to have rallied behind the notion that exchanging literal documents rather than using SOAP-RPC is not RPC-like and is somehow implicitly loosely coupled, and in some cases this is a correct assertion - exchanging documents according to the patterns observed in a problem domain is a sensible metaphor for Web Services development.

However, the discontinuity between the ideal and the real is apparent when it comes to describing groups of message exchanges or protocols using WSDL. WSDL 1.1, the current stable version of the specification, is RPC-centric in nature because it describes Web Services with interfaces (portTypes) as collections of operations with in, out, and fault messages. That is, it supports four hardwired message exchange patterns or MEPs: input-output, output-input, input only and output only which comprise all of the options for exchanging messages using WSDL 1.1 described services. Clearly the question of what happens when there are three or more messages in an exchange is not addressed by the hardwired MEPs but is left as an exercise to the reader of a contract to piece together by combining two or more operations.

WSDL 2.0 tries to rectify this situation by allowing for more sophisticated message exchange patterns. At time of writing although WSDL 2.0 has an extensible mechanism for supporting MEPs, only eight MEPs are provided by default: In-Only, Robust In-Only, In-Out, In-Optional-Out, Out-Only, Robust Out-Only, Out-In, and Out-Optional-In. While this is certainly a richer set than was available in WSDL 1.1, the family resemblance is uncanny: WSDL 2.0 still cannot describe protocols in any greater depth than request-response.

In the remainder of this article, we’re going to explore what this means for contract-first Web Services development and discuss alternative approaches which bypass the limitations imposed by the WSDL model.

Contract First Considered Harmful?

The philosophy underpinning contract-first design is that the “interoperability surface” which Web Services expose is the most important facet of that service – after all a Web Service is all but useless if it cannot be interoperated with. Establishing the protocols (messages structure, and message exchanges) which a service supports neatly captures the requirements of that service.

In the Web Services arena, contracts have traditionally been expressed in WSDL. Using WSDL, a contract is created which specifies the messages and message exchanges that an associated service supports. The contract is expressed in terms of “operations” which declared input, output, and fault messages.

However, there are fundamental problems with an operation-oriented approach. Declaring an interface in terms of discrete operations is not sufficiently expressive to capture all possible messaging behaviours for a Web Service. Furthermore WSDL 2.0 it is not trivially extensible to support arbitrary messaging patterns which Web Services will need.

Working with such a restrictive contract description language is worrying from a contract-first development point of view. The concern is that contract-first development with WSDL corrals developers into creating contracts which are by definition operation-oriented which in turn might lead to RPC- rather than message-oriented services being built.

In a Web Services development, the primary artefact that is under consideration is the Web Service itself, not its contract. To restrict the behaviour of a service, or worse to make the service behave differently from the domain it is designed to automate, because of limitations in the contract language is a flawed approach. Web Services exist to enable business process automation, not the other way round.

A given Web Service will contain domain-specific logic, and domain-specific messages which may be sent and received in some domain- or service-specific order. The relationships between those messages may often span multiple message exchanges (or operations in WSDL parlance), yet the ability to express that is missing in WSDL. That is, while WSDL is useful for RPC style interactions it is difficult to scale WSDL to support messaging in the general case which is a hindrance to successful contract-first design.

Contract Killer

The fact of the matter is that it is possible to build Web Services whose protocols cannot be comfortably accommodated within the constraints of the features provided by WSDL 1.1 and 2.0. While one solution is to view WSDL from a more holistic perspective (see: http://www.webservices.org/index.php/ws/content/view/full/45427 ), WSDL is simply underpowered for describing arbitrary protocols. The only long term solution to this problem is to move to a contract language that can deal with arbitrary message exchange patterns

The SSDL (SOAP Service Description Language, see http://www.ssdl.org ) has recently been released to the Web Services community to provoke discussion and experimentation with alternative contract languages. SSDL promotes the SOAP processing model as being the native architectural paradigm for Web Services, and SOAP messages as the fundamental abstraction for protocol-based integration. SSDL comes as a suite of specifications as shown in Figure 1 [2] .

SSDL is a significant departure from the WSDL model in a number of ways, not the least is the fact it is entirely focussed on the transfer of SOAP messages. That is SSDL is not generic like WSDL but instead assumes that Web Services use SOAP over arbitrary transports.

Firstly, SSDL does not allow for Web Services to expose a native CORBA binding for example, since to do so would increase the complexity of the language to WSDL-like proportions, and it might be argued needlessly since CORBA already has a contract description language. The trade off here is that assuming SOAP makes contracts much simpler since they can be described in terms which are consistent with the SOAP processing model, and that model provides the constraints within which application architectures can be developed. In some sense this parallels the REST model where hypermedia is the underlying application model and services are developed accordingly.

Secondly SSDL does not mandate a single, fixed model for describing protocols. This is a concept where there is no direct equivalent in WSDL. Where WSDL specifies the “interface” as the only means via which message exchanges are described, SSDL allows users to pick a description notation which suits their needs. That is, while SSDL provides a basic framework for describing messages and addressing, describing message-exchanges which endpoints support is left to other pluggable protocol frameworks.

At its inception, SSDL was released with four protocol plugin frameworks. These frameworks cover the spectrum of forms of contracts, from WSDL-like operations through to supporting long-running conversations. Some of the plugin frameworks have formal underpinnings and can be used to verify that, for example, protocols that services support will not deadlock.

With the exception of the WSDL-like MEP framework, the other SSDL frameworks allow message exchanges to be composed into protocols. That is, the frameworks all allow relations between message exchanges to be expressed and therefore to build up rich patterns of interaction which transcend the procedure-call abstractions supported by WSDL. This is shown in Figure 2.

Setting aside the SOAP-centricity of SSDL (which is a virtue, not a restriction!), the diagram shown in Figure 2 highlights the key difference between WSDL and most of the SSDL protocol framework plugins, namely that SSDL supports rich choreographical metadata. This metadata allows consumers of a service to understand the relationship between the various message exchanges that constitute the service’s supported protocol. The WSDL description, by contrast, has no such metadata and it is left as an exercise to the consumer of that service to figure out how WSDL individual operations are related.

Conclusions

Philosophically contract-first is a good idea because it elevates the exchange of business documents to be the primary artefact around which systems are built. Modelling such exchanges leads to integration at a high level and should in turn lead to solutions which are suitably loosely coupled.

However, pragmatically contract-first is hamstrung by the contract languages which Web Services practitioners have at their disposal. WSDL is cumbersome and provides the wrong set of abstractions, while WS-BPEL is heavyweight and relies on WSDL. Given the prevailing conditions, contract first is fraught with difficulty when contract languages are brittle and unwieldy.

Using WSDL as the contract language for contract-first development may require some creativity at best. At worst the contract language will constrain the underlying service implementation resulting not so much with a robust Service-Oriented Architecture but a rather limp RPC-ish one. If that is the case, then it makes sense to drop WSDL in favour of some other contract language whether that is SSDL, BPEL, or simply schemas and natural language descriptions of message exchanges. Ultimately it boils down to the fact that the services are there to support the business and the contract language must be able to capture business interactions. A contract language should enable rather than constrain business protocols: the tail, after all, does not wag the dog.

Acknowledgements

With thanks to Savas Parastatidis ( savas@parastatidis.name ) for his feedback during the preparation of this article.

[1] This heresy courtesy of one of the co-authors of “WSDL is not yet another Object IDL”

[2] Diagram from The SOAP Service Description Language: A High Level Overview ( http://www.ssdl.org/overview.html ), Parastatidis, S. and Webber, J. 2005.