WS-Referral

In the sample code, we've seen how WS-Routing can be used to specify a route from a Web services client to the service itself. One observation you might have made is that in all the examples, the route was always defined by the client. By configuring the SOAP context, both the .NET and Java client specified the address of the intermediary and the address of the destination (endpoint). Had the samples shown multiple intermediaries, these would have had to be included here also.

While having the client define the route works for the samples, you'll encounter a number of cases where the route is not always known. If we revisit the load-balancing example outlined at the start of this chapter, we'll see that it's likely the route to the final Web service is not going to be known by the client ”instead, it will be determined by the intermediaries.

To enable a more dynamic approach for routing, there is a complimentary specification called WS-Referral. The specification, also created by Microsoft, and released at the same time as WS-Routing, outlines methods for inserting, deleting, and querying the routing entries in a SOAP router. The document itself, located at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-referral.asp , shows the format that a SOAP router can use for implementing referrals.

For example, the route of the sample code, as shown in Figure 15.5, is currently determined by the client.

Figure 15.5: Current route used by the sample code.

With WS-Referral, the intermediary (B) uses a referral configuration file, which is used to match destinations with the next route or set of routes the message should take. This referral configuration might look similar to the following:

 <r:ref xmlns:r="http://schemas.xmlsoap.org/ws/2001/10/referral">     <r:for>         <r:prefix>http://www.my.org/c</r:prefix>     </r:for>     <r:if/>     <r:go>         <r:via>http://www.another.org/route.asmx</r:via>     </r:go>     <r:refId>mailto:[e-mail]</r:refId> </r:ref> 

Here, any request for the destination that matches the < r:prefix > element causes the router to add an additional path ”to route the message through D first. Figure 15.6 shows how this would look as implemented with our sample.

Figure 15.6: How WS-Referral can dynamically set the route by using the referralCache.config file.

Notice also that the client requires only the address of the destination (C) and the address of the first router (B). The client can be oblivious to any additional routes that might be inserted or deleted once the router has processed the message.

With the < r:if / > statement in the referral, the router can determine the path based on a set of conditions. While these conditions are relatively open - ended, the WS-Referral specification does define two ”a TTL (Time To Live) and an invalidation . The TTL can be particularly useful in a situation where certain messages had to reach the destination in a given timeframe.

The sample code itself does not show WS-Referral in action, but the directory of the .NET intermediary (C:\Interoperability\Samples\Advanced\WS- Routing\dotNET\Intermediary) does contain a sample referralCache.config file, which can be enabled by adjusting the Web.config file in the same directory. If you wish to do this, I would recommend first familiarizing yourself with the samples that ship with Microsoft WSE 1.0 to appreciate how WS-Referral is implemented.