Making SOAP Protocol-Independent: WS-Routing

As I explained in the January 24, 2002, edition of .NET UPDATE, Simple Object Access Protocol (SOAP) isn’t a complete protocol in itself. Although the protocol can identify the elements of a SOAP message that are intended for various recipients, the protocol doesn’t have a mechanism that specifies how those elements will travel to their destination. To route messages from sender to recipient, SOAP must use another protocol: Most often, SOAP uses HTTP but can potentially use SMTP. This routing method works, but it also requires successful SOAP transmissions to rely on a routing protocol to get messages from point A to point B—and to points C, D, and E along the way.

Web Services Routing Protocol (WS-Routing), the Global XML Web Services protocol originally named SOAP-RP, makes SOAP more protocol-independent by specifying placement of destination addresses in the message header to create a route for the message to take. WS-Routing also lets the recipient of a SOAP message reply to or acknowledge the message, although it doesn’t provide for reliable or secure messaging.

WS-Routing’s capabilities come from a new SOAP header and processing model. The new header, called "path," contains a "to" element that identifies the ultimate recipient, and a "fwd" element that lists the forward message path. This path lets the SOAP message hit several intermediary recipients before arriving at its final destination. WS-Routing identifies every intermediate recipient with a "via" element. Optionally, the path header might also contain a "rev" element that describes the reverse message path and lets any intermediate message recipient easily send a reply to the original sender by backtracking along the sending path. Another optional element in the header is a "from" element that identifies the message’s originator. In addition to these elements, the header must contain an "action" element that points to a Uniform Resource Identifier (URI) explaining the message’s intent, and an "id" element that identifies the message.

WS-Routing works similarly to sending a houseguest who is a stranger to your city out to run errands for you. You arrange a list of errands in an order that makes sense given the nature of the errands. For example, because one errand requires buying fresh fish, you place that errand last on the list. You also write your name on the list of errands. Using the information on the list, your houseguest knows the order in which to perform the errands, can backtrack to find his or her way back to your house, and can also prove to the fish seller that he or she is picking up the fish you ordered. Since each action element of the errand list identifies the purpose of the trip, you can count on your houseguest not to get sidetracked and stop somewhere for a triple latte.

In effect, the addition of WS-Routing makes SOAP messaging closer to being protocol-independent. WS-Routing is designed to bind to HTTP, as well as to TCP and UDP with the help of Dynamic Internet Messaging Encapsulation (DIME), a form of MIME that works with XML Web services. According to its specifications, WS-Routing can also potentially work with other protocols such as Secure Sockets Layer (SSL) or SOCKS. A SOAP message that uses WS-Routing can even use one protocol for one portion of a route and another protocol for another portion, if the situation demands (e.g., if UDP forwarding is cut off for one part of the route, necessitating the use of TCP to get through).

For more information about WS-Routing, check out the specification and the Microsoft overview in the following Microsoft articles.

"Web Services Routing Protocol (WS-Routing)"

"WS-Routing Specification Index Page"

"Web Services Specifications"