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

• <path> - WS-Routing (SOAP) header block• <from> - URI of initial sender• <to> - URI of final destination• <fwd> - specifies forward message path

using an ordered list of <via> elements– <via> - URI of an intermediate

• <rev> - (optional) specifies reverse message path using an ordered list of <via> elements

7

WS-Routing Processing

• Final destination is the <to> (if present) or the last <via> child of <fwd> element

• On receipt of message, a node deletes the first <via> child of <fwd>, processes appropriate header blocks, and relays message to new first <via> child of <fwd>, or to <to> element if <fwd> has no children

• A node may insert new <via> children to dynamically build the forward path

8

Message Format<s:Envelope xmlns:s=“…” <s:Header> <m:path xmlns:m=“… WS-Routing namespace …”> <m:action> …URI identifying processor at destination…</m:action> <m:to> … URI identifying final destination … </m:to> <m:fwd> <m:via> … URI identifying first intermediary … </m:via> <m:via> … URI identifying second intermediary … </m:via> … additional intermediaries can be specified here … </m:fwd> <m:from> … URI identifying initial sender … </m:from> <m:id> … unique message identifier …</m:id> </m:path> … other headers … </s:Header> <s:Body> …. </s:Body></s:Envelope>

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 <rev> child of <path> 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 <rev> element it adds a new <via> element as the head of the <rev> list containing its own URI.

12

Constructing the Reverse Path

<m:path …> …. <m:fwd> <m:via>…B’s URI…</m:via> <m:via>…C’s URI…</m:via> </m:fwd> <m:rev> <m:via>…A’s URI…</m:via> </m:rev> ….</m:path>

<m:path …> …. <m:fwd> <m:via>…C’s URI…</m:via> </m:fwd> <m:rev> <m:via> …B’s URI…</m:via> <m:via> …A’s URI…</m:via> </m:rev> ….</m:path>

message arriving at B from A

message leavingB addressed to C

13

Message Correlation

• <m:relatesTo> can be used to store the value of the <m:id> 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