multi-hop / routing: current state of discussions

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

Here is my recollection of what are the options on the table, and some requirements on which there seems to be consensus so far.

Any more addition or update?

 

-Jacques

 

 

General assumptions:

------------------------------

 

A1: intermediaries must (or "should"?) be "transparent", not altering ebMS headers at all.

A2: end-to-end reliability case must be supported (in addition to other case where the intermediary is itself an RM / Security endpoint)

A3: the Sending MSH should not have to be aware of intermediaries (i.e. not distinguish them

from any receiving MSH, message content-wise). At most, some P-mode options might be ruled out.

 

1. Topology Requirements

----------------------------------------

 

Different topologies that must be supported:

 

T1: single intermediary (2 hops), gateway mode serving back-office message handlers.

Typically in the DMZ, and likely to be itself a reliability/security endpoint.

 

T2: single intermediary, a hub serving as a switch between a community of MSHs.

Not a security or reliability endpoint.

 

T3: Interconnected Hubs (generalization of T2), each of them serving a set of local MSHs.

An end-to-end path may involve several hubs. Endpoints may have specific constraints

that the hubs do not have, e.g. they may only pull from their hub, messages that have been

pushed to this hub.

 

2. Traffic Patterns Requirements

----------------------------------------------

 

Different flow patterns that must be supported:

 

P1: The "unidirectional intermediary":

Case where an Intermediary sits in the DMZ, only channeling the incoming

traffic, for security reasons. All outgoing requests are not required to use the intermediary,

and can directly address their destination (or another intermediary).

 

P2: The "bi-directional intermediary":

Cases where all requests and responses to/from a particular ultimate destination,

need use the same intermediary.

 

3. Connection Management Requirements

------------------------------------------------------------

 

C1: Synchronous paths:

All intermediaries keep their connections open for a request path, and responses

tht the ultimate receiver is sending synchronously, are carried over the back-channels

all the way (possibly, piggybacked with some ebMS Error-warning from intermediaries,

or with RM acks or other signals, if an intermediary is itself a QoS endpoint).

 

C2: Asynchronous paths:

At every step, the intermediary closes the connection, returning HTTP status, possibly

an ebMS error if the processing of the request fails, and possibly other signals in case

the intermediary is itself a reliability/security endpoint.

For any synchronous response received, the last intermediary has to either (a) send it in a callback

mode e.g. over a new HTTP request, (b) reuse another back-channel available from its

predecessor (e.g. offered by a PullRequest).

 

Routing techniques: (to be discussed)

----------------------------

 

R1. Fully static routing:

In that case, the intermediary is wired to always forward everything

to the same destination, no matter what the origin is. No routing function required.

 

R2. URL-based routing:

In that case, the routing is determined only based on URL content, e.g. on which port(s)

the intermediary receives.

 

R3. Message-controlled routing:

In that case the routing is entirely determined by message content (e.g. ebMS header or

wsa header). These header elements would contain the next MSH URL (e.g. as in WS-Routing,

or can be achieved for 2-hops e.g. using wsa:To).

 

R4. Message and Table-controlled routing:

Routing is determined based on message content + routing table that associates next URL

with message content.

 

NOTE: R4 must be supported, others to be discussed.

 

 

SOAP header data involved in routing: options to be discussed

------------------------------------------------------------------------------------------

 

NOTE: here, only WS-ReliableMessaging and issues related to its use are looked at.

The use of WS-Reliability would not cause the same problems as the latter has no

standalone RM signals to care about.

 

H1. None. In that case, other techniques are used, e.g. URL-based (see R2, or R1 above).

In that case, fully synchronous paths should be used (C1 above). Or, fully async.

Such intermediaries are not ebMS intermediaries, not even SOAP intermediaries (no

intelligence of SOAP headers).

 

H2. WS-Addressing headers:

- the routing of "RM sequence lifecycle" messages (CreateSequence / CreateSequenceResponse,

CloseSequence / ClSR, TerminateSequence / TSR) must be controlled by WS-addr, especially

the response signals are controlled by wsa:ReplyTo. This is required for compliance with

the behavior expected from RMDs out there.

- wsa:ReplyTo could be given 3 types of values:

(a) the URL of ultimate recipient (RMS). That fits the traffic pattern P1 above.

(b) the URL of the intermediary. In that case, the intermediary must be told how to forward

this further back to the RMS.

(c) an "anonymous" URI. In that case, the last intermediary will receive the response signals

synchronously, and must be told how to forward back to RMS.

Issue with (c): if RMS has set "anonymous ReplyTo" it may expect to get this response

on the back-channel of the related request (and not any other backchannel).

This can't be accommodated by the "first" intermediary, unless we are in a synchronous path (C1 above).

- the routing of "forth" RM signals (the RM lifecycle requests) is TBD, can use wsa but

tis is not a critical compliance issue.

- the routing of ebMS messages could also be based on wsa headers, but the routing functions

are then llimited (based on wsa:From, wsa:To, wsa:Action, not based on any party info or

eb:Service/Action). NOTE: such intermediaries could just be SOAP intermediaries and not understand

ebMS headers. But this cause sever restrictions: combinations of Push and Pull, where a hub itself is

the target of pulling, could not be handled.

 

H3. ebMS headers:

- the routing of "RM sequence lifecycle" request messages (CreateSequence ...) could still

be controlled at ebMS level if piggybacked on an ebMS message, e.g. a dummy one with

the existing default eb:Service for testing, and a new dummy eb:Action value.

Drawback: this requires some control on the RMS implementation to be able to piggyback

its signals, and this does not remove the need to use wsa:ReplyTo.

Advantage: the routing of "forth" RM signals canbe controlled in same way as other ebMS

messages (except based on Service/Action if dummy values are needed on the piggyback message).

- the routing of ebMS messages is based on their header content (see R3 or R4 above).

NOTE: This understanding of ebMS header is necessary for advanced Intermediary functions besides

routing, like handling cases where the intermdiary itself is Pull target.