Similar to specifications we've looked at in the previous two chapters, WS-Routing is one of the more recent Web services specifications. In its simplest form, WS-Routing is designed to provide a stateless, SOAP-based protocol for routing messages asynchronously using a number of transports. The specification is written so that it is transport agnostic ”meaning that WS-Routing can apply to SOAP messages sent via TCP, UDP, HTTP, or even SMTP.
The specification, which can be found at http://msdn.microsoft.com/ webservices /understanding/gxa/default.aspx?pull=/library/en-us/dnglobspec/html/ws-routing.asp , was authored by Microsoft in October 2001 but was first published in May 2001 as SOAP-RP.
The specification states that the entire route (path) for a message as well as the reverse path (that is, the route the reply will need to take) can be described within the SOAP Header portion of a message. This path contains the Uniform Resource Identifiers (URIs) of the intermediaries that the message must follow to reach its destination. As an example, the following listing shows a route or path within a SOAP message:
<SOAP-ENV:Header> <wsrp:path xmlns:wsrp="http://schemas.xmlsoap.org/rp/"> <wsrp:action>http://www.my.org/action</wsrp:action> <wsrp:to>http://www.my.org/d</wsrp:to> <wsrp:fwd> <wsrp:via>http://www.my.org/b</wsrp:via> <wsrp:via>http://www.my.org/c</wsrp:via> </wsrp:fwd> <wsrp:from>http://www.my.org/a</wsrp:from> <wsrp:id>uuid:A15E4356-36F1-4c49-9AB9-2E9A1AE346AF</wsrp:id> </wsrp:path> </SOAP-ENV:Header>
The route is shown using the < wsrp:to >, < wsrp:fwd >, and < wsrp:from > details. These details indicate the final destination of the message ( http://www.my.org/d ), the route it should take ( http://www.my.org/b to http://www.my.org/c ), and the originator ( http://www.my.org/a ), respectively. The message also has an action. This is the SOAP action to perform once the destination is reached ”in most cases, this will be the method that should be called.
This message will be passed through a series of intermediaries (also known as routers) as shown in Figure 15.1. The intermediaries will interrogate the path, make changes as applicable , and forward the message to the next destination. For example, using the message just shown, intermediary B might perform some action based on the message, as well as change the route to confirm that the next destination is C. The intermediaries also have the ability to change the action of the message, perhaps to specify an additional intermediary or to change the path completely.
As all the messages are based on SOAP, which is platform independent, this example lends itself to being a great interoperability story. In theory, sender A could be based on Java, intermediary B could be on .NET, intermediary C could be a mainframe, and the endpoint D could be some kind of SOAP-aware mobile device.
In the scope of this chapter and by using the samples, I'll show a number of scenarios based on a client, router, and an endpoint. A combination of clients and Web services written in both Java and .NET will be used to show that WS- Routing can be used regardless of the underlying technology. To demonstrate these scenarios, we'll use the WS-Routing capabilities of Microsoft Web Services Enhancements (WSE) 1.0 and GLUE version 4.0.1 from The Mind Electric.
This sample assumes that Microsoft WSE (Web Services Enhancements) 1.0 Service Pack 1 has been installed. This software can be downloaded from http://msdn.microsoft.com/webservices and must be installed for the .NET portions of the sample to compile correctly. Additional information about downloading and installing the product can be found in the "Downloading and Installing Microsoft WSE" section of Chapter 13, "Web Services Interoperability, Part 1: Security."