Dynamically Configuring SOAP Routing: WS-Referral

WS-Referral can dynamically change a SOAP message's routing path

In the April 4, 2002, edition of .NET UPDATE, I explained that Simple Object Access Protocol (SOAP) doesn't have any routing capabilities of its own but depends on an underlying protocol (often HTTP) for routing. Web Services Routing Protocol (WS-Routing) lets you add a new section to SOAP messages that specifies the routing path for the message, naming both the final recipient of the message and any intermediary recipients along the way. However, using WS-Routing doesn't require the sender of a SOAP message to completely fill in the routing path for the message. The sender needs to know only the final recipient of the message and the next SOAP node in the routing path on the way to the final recipient. The intermediary SOAP node must know both that it's an intended recipient of the message and where to send the message next. The message's ultimate recipient must know that it's the last stop on the SOAP message path (so that it doesn't try to send the message anywhere else).

Because SOAP routing paths don't have to be completely filled out ahead of time, the Global XML Web Services Referral Protocol (WS-Referral) can dynamically change the routing path—adding or removing nodes from the path—as needed. WS-Routing makes it possible to build a dynamic routing path that takes into account firewalls, load-balancing rules, and the discovery of resources that the original message doesn't identify. In the context of WS-Routing, SOAP nodes are known as SOAP routers because routing is the nodes' primary purpose in this protocol. The SOAP nodes that perform an action with the SOAP message are known as SOAP actors. The same SOAP node can be both router and actor.

WS-Referral's basic unit is the referral statement, which can contain five elements. The "for" element identifies the set of SOAP actors—a sender and a recipient—for which the referral statement is intended. The "if" element describes the conditions that must be met for the referral to take place. The "refId" element is the unique identifier for the referral, and the "go" element lists the available SOAP routers by which the sender can route the message to the SOAP actor that is the message's recipient. An optional "desc" element describes the statement and the sender and the statement's ultimate recipient, or some combination of these two elements, in case the SOAP router needs this information to accomplish the referral.

What happens with the referral depends on the identity of the SOAP actors and whether the conditions that the referral statement defines are met. If the SOAP actor's name in the referral statement matches any of the SOAP actors who are supposed to see the message on the way to its final recipient, then that name matches the WS-Referral statement. If the conditions that the "if" element outlines apply to the intended route, then the statement is satisfied and the message can be referred. If a router has indicated that it's willing to be a router for the SOAP message and accepts the statement, then that router can use the information in the referral statement and create a (potentially) new routing entry in the SOAP header. (WS-Routing has no mechanism for determining the identity or authority of a SOAP message—that's a task for protocols such as Web Services Security Language—WS-Security.)

So how do referral statements get to the SOAP routers? A referral statement can be part of the SOAP message for which it's creating a routing path; in this case, the referral header is part of the main message. Alternatively, a referral statement can be contained within separate SOAP messages by either a push or pull model. In the push model, register messages sent from the SOAP message source tell the recipient to use the referral statement. In the pull model, an actor can use a query message to ask a SOAP router for referrals. Register and query messages are intended for administrators who need to configure a set of SOAP routers on a path. SOAP messages that use the referral header are designed for dynamic environments that cache updates to message paths so that a SOAP message can change course in midstream if a better path presents itself.

For more information about WS-Referral, see the following Microsoft specification articles:

"Web Services Referral Protocol (WS-Referral)"

"WS-Referral Specification Index Page"