1 / 13

WS-Routing

WS-Routing. Why WS-Routing?. SOAP (by itself) doesn’t define a message path

laasya
Download Presentation

WS-Routing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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>…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> <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> message arriving at B from A message leaving B 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

More Related