1 WS-Routing

2 Why WS-Routing? SOAP (by itself) doesn’t define a message path –Header blocks describe functions to be performed by intermediaries that play specified roles, but there is no standard way to provide addresses of intermediaries or indicate the order in which intermediaries are to be visited –Envelope doesn’t contain address (target module, target node) Hence, SOAP message is embedded in another application layer protocol - generally HTTP - that contains the address –receiving (HTTP) processor directs message to target (application) module –Target module determines next node and addresses the HTTP message to it

3 Why WS-Routing? WS-Routing extends SOAP with an addressing structure to define a complete message path Extended SOAP message is self-contained –does not have to be bound to another application layer protocol –can be sent directly over a transport protocol (e.g., TCP) –receiving SOAP processor directs message to target module –target module interprets WS-Routing information and sends message to next intermediary using transport protocol

4 WS-Routing WS-Routing: –is stateless: nodes along path do not maintain state –defines a SOAP header for storing routing information –supports Specification of a forward path Specification of a reverse path Specification of relationships (correlation) between messages

5 Intermediaries Support a distributed processing mechanism in which nodes along a message path supply value-added services –SOAP header contains the part of a message to be processed by an intermediary that fulfills a particular role

6 Specifying the Message Path - WS-Routing (SOAP) header block - URI of initial sender - URI of final destination - specifies forward message path using an ordered list of elements – - URI of an intermediate - (optional) specifies reverse message path using an ordered list of elements

7 WS-Routing Processing Final destination is the (if present) or the last child of element On receipt of message, a node deletes the first child of, processes appropriate header blocks, and relays message to new first child of, or to element if has no children A node may insert new children to dynamically build the forward path

8 Message Format <s:Envelope xmlns:s=“…” …URI identifying processor at destination… … URI identifying final destination … … URI identifying first intermediary … … URI identifying second intermediary … … additional intermediaries can be specified here … … URI identifying initial sender … … unique message identifier … … other headers … ….

9 Reverse Path In some applications it may be appropriate to provide for a response message –Communication follows request/response pattern –Peer-to-peer communication is anticipated –A fault message may be generated –An acknowledgement will be sent Problem: Don’t want intermediate nodes to have to maintain state to remember the reverse path

10 Reverse Path Solution: Sender includes a child of element in forward message –Reverse path is built dynamically and stored in message as it progresses in forward direction –Indicates a possible path to be used by receiver for a return message Intermediary may short-circuit forward path and reply to initial sender over the (partial) reverse path –Appropriate if intermediary implements a cache

11 Building the Reverse Path When an intermediary receives a message containing a element it adds a new element as the head of the list containing its own URI.

12 Constructing the Reverse Path …. …B’s URI… …C’s URI… …A’s URI… …. …. …C’s URI… …B’s URI… …A’s URI… …. message arriving at B from A message leaving B addressed to C

13 Message Correlation can be used to store the value of the field of a related message –A reply message is related to a forward message –A fault message is related to the message that caused the fault