Client-Controlled Routing

In the two examples we’ve looked at so far, the server has controlled how the message is routed and the client is unaware that the message has been routed. There is also a third form of routing available: client-controlled routing. Client-controlled routing allows the client to specify the Web service it wants to call and to specify the route that the message takes to the destination Web service.

The Web Service

The Web service we’ll use for this example is the same Web service we used for the server- controlled routing; it can be found at http://localhost/wscr/14/TellMe.asmx. It’s the route to this Web service that we’re interested in—not what the service does—so we can reuse the existing service without any problems.

Server Configuration

Configuration of a client-controlled router is similar to the configuration of a server-controlled router. We must add an HTTP handler to the web.config file for each router that we want to have available. In this example, we’ll make three routers available—RouterE.asmx, RouterF.asmx, and RouterG.asmx—and we’ll add three entries to the web.config file:

<!-- the TYPE attribute must be on one line  --> <add verb="*" path="RouterE.asmx"   type="Microsoft.Web.Services.Routing.RoutingHandler,Π  Microsoft.Web.Services, Version=1.0.0.0,Π  Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> <add verb="*" path="RouterF.asmx"   type="Microsoft.Web.Services.Routing.RoutingHandler,Π  Microsoft.Web.Services, Version=1.0.0.0,Π  Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> <add verb="*" path="RouterG.asmx"   type="Microsoft.Web.Services.Routing.RoutingHandler,Π  Microsoft.Web.Services, Version=1.0.0.0,Π  Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

In a difference from server-controlled routing, however, we don’t need to create entries in the referral cache. All of the routing details are contained in the incoming message, and the server has no knowledge of where an incoming message is to be routed next.

WSDL for the Routers

When we use client-controlled routing, we don’t have to provide any WSDL for the routers we’re using. The client application we’re using creates a reference only to the Web service that is the final destination of the message and, as you’ll see, it simply adds the routers that it wants to use to the forward path collection of the request’s SoapContext object.

The Client

The client application is where all of the work to use the routers actually takes place, and it is here that the message’s route to its final destination is configured. Within the RoutingClient application, we need to click on the Client tab, as shown in Figure 14-11.

Figure 14-11: The RoutingClient application showing the client-controlled routing tab

As you can see in Figure 14-11, we can specify the three routes that we want the message to take to reach the destination Web service. In each of the combo boxes, we have the choice of RouterE.asmx, RouterF.asmx, or RouterG.asmx for that stage in the route. If we want, we can even send the message through the same router three times.

Clicking the Execute button runs the click event handler code for the button; it is here that we add the routing details.

We first create an instance of the proxy class for the Web service just as we would for any other proxy class. We then have to add the routing details to the message.

As you saw when we looked at the Path object, the forward path is contained in the Fwd property. This is a collection of Via objects, and we add a new Via object to the Path for each router that we want to add to the route. The Via object constructor requires a Uri object, so we create one of these inline, passing in the URL that we want to route the request through:

// add the route to the message proxy.RequestSoapContext.Path.Fwd.Add(new Via(new     Uri("http://localhost/wscr/14/" + cboFirst.Text))); proxy.RequestSoapContext.Path.Fwd.Add(new Via(new     Uri("http://localhost/wscr/14/" + cboSecond.Text))); proxy.RequestSoapContext.Path.Fwd.Add(new Via(new     Uri("http://localhost/wscr/14/" + cboThird.Text)));

To track the path that the message takes to its final destination, we must add a <wsrp:rev> element to the routing header. As we pointed out earlier, the HTTP protocol already has an intrinsic reverse path; a reverse path is not added to the routing header by default. We can override this by forcing a reverse path to be added to the routing header, and once the routers see this element in the header, they will populate it correctly.

We can’t simply add an empty Via object to the Rev collection of the Path object because the ViaCollection that the Rev property exposes is not defined. We must create a new ViaCollection and set the Rev property.

// add a <wsrp:rev> element so that we can track the path proxy.RequestSoapContext.Path.Rev = new ViaCollection();

We can then make the request to the proxy in the normal manner, by calling the Echo method.

If we leave the default routing options selected and call the destination Web service, the message will be routed to TellMe.asmx. If you look at Figure 14-12, you’ll see that the message passes through RouterE.asmx, RouterF.asmx, and RouterG.asmx before it reaches its final destination.

Figure 14-12: Returned message showing the path that was taken to TellMe.asmx

The SOAP Messages

The routing header generated by the Routing output filter is similar to the routing headers we looked at when we discussed server-controlled and custom routing.

The client adds the route that the message takes to its final destination, so all of the details are present in the message that leaves the client. The <wsrp:to> element contains the final destination of the request, and the <wsrp:fwd> element contains a series of <wsrp:via> elements that contain the route that the message is to take. We also have an empty <wsrp:rev> element that will be populated as we pass through the routers. You can see this if you look at the message received by RouterE.asmx:

<wsrp:to>http://localhost/wscr/14/TellMe.asmx</wsrp:to>  <wsrp:fwd>   <wsrp:via>http://localhost/wscr/14/RouterE.asmx</wsrp:via>    <wsrp:via>http://localhost/wscr/14/RouterF.asmx</wsrp:via>    <wsrp:via>http://localhost/wscr/14/RouterG.asmx</wsrp:via>  </wsrp:fwd> <wsrp:rev />

RouterE.asmx forwards the message to RouterF.asmx and removes itself from the forward path. We have a <wsrp:rev> element, so it will add itself to the reverse path of the message. You can see this in the message received by RouterF.asmx:

<wsrp:to>http://localhost/wscr/14/TellMe.asmx</wsrp:to>  <wsrp:fwd>   <wsrp:via>http://localhost/wscr/14/RouterF.asmx</wsrp:via>    <wsrp:via>http://localhost/wscr/14/RouterG.asmx</wsrp:via>  </wsrp:fwd> <wsrp:rev>   <wsrp:via>http://localhost/wscr/14/RouterE.asmx</wsrp:via>  </wsrp:rev>

RouterF.asmx and RouterG.asmx perform the same task of moving themselves from the forward path to the reverse path and sending the message to the next router. RouterG.asmx forwards the message to the final destination service, which is contained in the <wsrp:to> element, because there are no more entries in the forward path, as you can see if you look at the routing header received by TellMe.asmx:

<wsrp:to>http://localhost/wscr/14/TellMe.asmx</wsrp:to>  <wsrp:rev>   <wsrp:via>http://localhost/wscr/14/RouterG.asmx</wsrp:via>    <wsrp:via>http://localhost/wscr/14/RouterF.asmx</wsrp:via>    <wsrp:via>http://localhost/wscr/14/RouterE.asmx</wsrp:via>  </wsrp:rev>