Routing and HTTP

At the moment, the only transport protocols available for our Web services are HTTP and HTTPS. Due to the request/response nature of these protocols, we have a reverse path to the caller intrinsically defined, and we don’t need to define the <wsrp:rev> elements in the routing header.

Although WS-Routing specifies the concept of a reverse path, when you use HTTP or HTTPS this path has no real meaning. It’s only when we start looking at other protocols that don’t have an intrinsic reverse path, such as Microsoft Message Queuing (MSMQ), that we need to concentrate on those details.

The current implementation of the routing input and output filters doesn’t populate the reverse path details by default—if there is no <wsrp:rev> element in the incoming routing header, no <wsrp:rev> header will be added to the request to the next router. We can, however, force the filter to populate the <wsrp:rev> header, and when we look at client-controlled routing later in the chapter, you’ll see that if we want to keep track of the route that our message has taken to reach its destination, we must force the use of the reverse path.