Messaging with Web Services: WS-Routing, WS-Referral, and DIME
Web services are not just about remote method calls. Rather, the true value of Web services is in long-running business transactions using asynchronous messages—messages that are sent with no immediate reply. These messages allow for the ultimate in loosely coupled, distributed transactions. They also map very well to the actual business processes encountered in the real world.
In order to send asynchronous messages, you need to deal with the reality of multiple transports and multiple nodes through which a message may travel. In many ways, asynchronous messaging is what SOAP was designed for, but SOAP doesn't specify the routing and referral protocols needed to make asynchronous messaging happen in a standard manner. Even more important is the ability to send messages to logical names and transparently lift your Web service architecture above the physical network topology. In fact, it's important that the Web service architecture be very flexible.
WS-Routing and WS-Referral are two protocols for specifying message paths and the dynamic configuration of these message paths. They were developed because SOAP does not do explicit routing. SOAP also lacks an unambiguous way to determine the intent of a SOAP message—an issue that WS-Routing takes care of as well. With WS-Routing, you also can send messages to logical locations. The Web Services Enhancements for Microsoft .NET (WSE) enables you to use WS-Routing and WS-Referral with your .NET Web service applications. Several SOAP toolkits also now support WS-Routing.
This chapter examines WS-Routing and WS-Referral. It also examines DIME (Direct Internet Message Encapsulation), a protocol for sending SOAP messages with binary attachments.
|
