Connecting with Web services

There's more than one way to perform loose coupling, and they're evolving

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.