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.