Working Routers

The routers we’ve looked at so far have all met the standard definition of a router— receive a request and forward it on to a new destination. However, we introduced a little variety into this paradigm when we looked at custom routers—rather than simply routing the message to a predetermined location, we performed some processing to determine the route.

We still haven’t covered every possible scenario. When we looked at client-controlled routing, you saw that this approach would be pointless unless the routers actually did some work. Otherwise, we could just jump directly to the ultimate destination.

What we need is a new type of router, a “working router,” that performs a real processing task and uses routing information that is specified elsewhere—either in the referral cache or in the routing header in the incoming message.

To create a working router, we follow the same process as for a custom router—we derive a new router from RoutingHandler and override the ProcessRequestMessage method. The difference between a custom router and a working router is that in a working router we don’t specify any routing details within the overridden ProcessRequestMessage method.

If we’re using client-controlled routing and we want to have a working router, we can simply create a derived class that specifies no routing details because all of the information to route the message is already contained with the Path object that ProcessRequestMessage receives. The basic approach is as follows:

public class WorkingRouter : Microsoft.Web.Services.Routing.RoutingHandler {     protected override void ProcessRequestMessage(SoapEnvelope message,         Path outgoingPath)     {         // do some work here     } }

For server-controlled routing, the process isn’t as simple as with client-controlled routing because the referral details are manipulated by the ProcessRequestMessage method that we’ve overridden. Within our overridden class, we need to call the ProcessRequestMessage on the base class to determine the route from the referral cache:

public class WorkingRouter : Microsoft.Web.Services.Routing.RoutingHandler {     protected override void ProcessRequestMessage(SoapEnvelope message,         Path outgoingPath)     {         // do some work here         // get the routing information from the referral cache         base.ProcessRequestMessage(message, outgoingPath);     } }

If we’re not sure whether the router will exist in a server-controlled or a client-controlled situation, we must use the server-controlled version of the working router. As you’ll recall, if we have routing details already specified, any details we specify in a referral cache are ignored.