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.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell Loose coupling Executive Summary: The new Web services mantra, loose coupling, can be interpreted in several different ways. Abstract XML interfaces and asynchronous messaging are first steps. SOAP routing, in the long run, may be a more general solution to loose coupling of Web services. Test Center Perspective: There's more than one way to perform loose coupling. BEA's WebLogic Workshop exemplifies two styles that will evolve during the next few years. One uses XML mapping to separate stable interfaces from mutable implementations. The other supports asynchronous messaging for business processes that can span days, weeks, or years.

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.

The transition to the doc/literal style will not be easy and may never be complete. The RPC pattern naturally fits what programmers do, but it does not necessarily imply tight coupling. A bit of extra discipline can insulate an RPC-style interface from changes in its underlying implementation. Of course, discipline is a scarce commodity. Software assistance, such as what BEA is providing in WebLogic Workshop, will be a checklist feature in the next generation of SOAP toolkits. It can also serve as a bridge from a procedural to a more declarative style of programming. In WebLogic Workshop, for example, a service is simply declared to be "conversational" in much the same way that a COM+ service can be declared to be transactional. The toolkit handles the plumbing, which can involve fire-and-forget messaging, registration of callback methods, or even automatic polling of end points that are firewalled and cannot directly receive callbacks.

When SOAP actors engage in this kind of conversation, it's not just the interface that is loosely coupled -- so is the messaging substrate itself. The latency and unreliability of the Internet dictate the need for asynchronous messaging, as do business processes that span days, weeks, and years. Binding SOAP to proprietary, message-oriented middleware is feasible today, and it's a powerful strategy for enterprise application integrators. For a while, loose coupling will mean abstract interfaces and asynchronous messaging, and there is much important work to be done according to these definitions.

Routing SOAP

Even as that work begins, a larger picture of loose coupling is coming into focus. Routing, the core technology of the Internet, is emerging as a way to coordinate interaction among SOAP actors on a global scale. SOAP routing is described in two of Microsoft's Global XML Architecture specifications. WS-Routing defines how to specify the route a SOAP message takes through a chain of intermediaries. WS-Referral empowers those intermediaries to modify the route. These proposals are thus far just trial balloons, but early products such as KnowNow's Event Router (see our Test Center Review " Flexible messaging ") anticipate a trend toward increasingly active intermediaries.

At the Emerging Technology Conference, KnowNow's Rohit Khare sketched out a model he calls "application-layer internetworking," in which SOAP routers enable the composition of systems that are loosely coupled in the broadest sense. In this view, services such as auditing or currency conversion are supplied by SOAP routers, just as VPN and anti-virus services are provided by today's IP-level routers. What's more, these SOAP routers can act on behalf of interests other than those of a pair of SOAP end points. Khare joked that the real integration challenge lies at "Layers 8 and 9 of the OSI stack: economic and political." The notion of injecting such interests directly into the fabric of Web services is exciting, scary, and maybe inevitable.

Questions abound, most notably about reliable messaging and the federation of trust. Today's message-oriented middleware, such as IBM MQSeries, Sun's Java Message Service, and Microsoft Message Queuing, is proprietary. IBM has proposed an HTTP derivative, HTTPR (Reliable HTTP), as an open way to guarantee exactly once delivery of asynchronous SOAP messages. But there's no consensus as to whether HTTP should be extended in this way.

Trust is the really thorny issue. The WS-Security specification jointly written by IBM and Microsoft addresses signature and encryption only, not ways to establish or verify trust. Microsoft and the Sun-backed Liberty Alliance are busily cooking up separate schemes to federate trust across sets of Web services. Grand Central Networks offers a short-term fix, routing Web services within a zone of trust that it creates. Before the dust settles, another chapter in the long and painful saga of PKI (public key infrastructure) may yet be written.

Developers newly converted to Web services may feel that loose coupling is a bait and switch -- that the rules are shifting before the game has really started. But loose coupling is a design style, not a technology. There's more than one way to do it. Although no one has all the answers, the approaches BEA has taken in WebLogic Workshop are important steps in the right direction.