How WSE Routing Works

Routing in WSE is implemented by using a custom HTTP handler for the requested URL that can route the incoming message to the next intermediary. In WSE, this custom handler is the RoutingHandler class.

When an incoming message is received, the Routing input filter parses the routing header and populates the Path object of the request’s SoapContext object. Control is then passed to the ProcessRequest method of the RoutingHandler class; this is where all of the work to route the message occurs. The processes that occur in ProcessRequest are shown in Figure 14-1.

Figure 14-1: Internal architecture of the RoutingHandler.ProcessRequest method

Within ProcessRequest, we use the details in the Path object of the request’s SoapContext object to create an outgoing Path object that contains the details about the route the message must take after it leaves this router. The outgoing Path object is basically a copy of the path specified by the request’s SoapContext object, except that if the current router is the first <wsrp:via> element in the <wsrp:fwd> collection, it is moved from the Fwd collection to the Rev collection. (We want to keep details of the reverse path, and we don’t want to reroute to the same router!)

The ProcessRequestMessage method is then called and is passed a copy of the outgoing Path object—if the outgoing Path object isn’t populated, the ProcessRequestMessage method checks the referral cache for any details for this router, and these are copied from the referral cache to the Path object.

When control is passed back to ProcessMessage, the returned Path object is interrogated to determine the next intermediary for the message. If there are any Via elements that can be routed, the first one in the collection is used; if there are no Via elements, a call is made to the router specified in the To element. If we can’t determine a router that we can forward the message to, an exception of type SoapHeaderException is thrown.

Before making the call to the next router, the routing handler sets the Path object of the outgoing SoapContext object to the Path object returned from ProcessRequestMessage. The Routing output filter then uses the Path object to add the routing header to the request.

When control is returned from the next router, we call the ProcessResponseMessage method; the message returned from the remote call can then be modified if required.

All of this might seem a little complex for this early in the chapter, but you’ll soon see that the way the different objects are integrated provides a vast range of options for controlling how you route messages.