Connecting with Web services

WEB SERVICES ARE A SPECIES of componentized software. As such, the usual design patterns apply. Components need well-specified interfaces, and they must be reusable. More so than most conventional components, however, Web services tackle business processes that are widely distributed both in time and space. The new design pattern that arises in response to this challenge is called loose coupling.

Everyone in the Web services industry agrees that services are going to have to be loosely coupled. Exactly what that means and how we will get there remains open to interpretation. At the O'Reilly Emerging Technology Conference last month, BEA's Adam Bosworth demonstrated two important ways in which WebLogic Workshop achieves loose coupling. One uses XML mapping, which adds a stable interface layer that abstracts away from mutable underlying implementations; the other uses asynchronous messaging, done in a conversational style that begins to exploit the intrinsic one-way messaging capability of SOAP -- the feature that makes SOAP more than just CORBA with angle brackets. Both approaches exemplify key trends that will play out during the next few years. Loose coupling will certainly matter. What's unclear is how much of it we will need and what we will trade away to get it.

Most SOAP toolkits today don't explicitly support XML mapping. WSDL auto-generators tend to expose local namespaces directly as public interfaces -- a recipe for brittleness. First-generation toolkits, Bosworth said, make tight coupling too easy and attractive. The response from Microsoft's Dave Stutz, during the following panel discussion, was, "Guilty as charged," but with an explanation. Visual Studio .Net, he pointed out, aims to energize a broad base of developers. It is doing so, and we should all be grateful. In other words, brittle interfaces would arguably be a good problem to have because it would mean there were enough of them to matter. And if the "CORBA-with-angle-brackets" analogy helps Web services reach critical mass, then it will have served its purpose.

Mapping and messaging

The generic version of XML mapping, everyone on Bosworth's panel agreed, is a style of SOAP messaging called doc/literal. In the prevailing RPC (Remote Procedure Call) style, which supports the familiar pattern of method calls with named and typed inputs and outputs, XML is not a first-class data type. Rather, RPC-style SOAP works with standard programming-language data types such as strings, numbers, and compound structures built from these primitives. To travel as data, XML has to be encapsulated. The alternative doc/literal style, which is in fact preferred by Visual Studio .Net, simply exchanges XML documents. The specification for the .Net My Services (aka Hailstorm) API is one of the most complete examples of what a programming system built on this principle would look like.