ebxml-msg — archive

[Jacques Durand]

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.