Pim: inline
From: Pim van der Eijk
[mailto:]
Sent: Wednesday, April 02, 2008 1:35
PM
To: Durand, Jacques R.;
Subject: RE: [ebxml-msg] Groups -
Transparent MEP routing proposal V0.1
(ebMS-transparent-Multihop-MEPs-Routng.doc) uploaded
Hello Jacques,
Here are some quick comments on this
proposal (and some earlier
documents):
1) What does "no
additional capability besides Core ebMS V3 is required from the endpoint MSHs
involved at the boundaries of the I-Cloud" mean?
The
proposal describes a requirement that "The
PMode parameter PMode.Protocol.Address contains the Hub URL, the value of which
must be extended with an HTTP Query of the form:
?pmode=<ID>". In this proposal, any support for multihop
would mean the ebMS 3.0 processor must append this query to the hub URL. I
don't know if any of the few existing ebMS 3.0 processors support this ability
to update the hub URL today, and it may not be easy to add this behaviour to an
existing SOAP stack. Or are we assuming this is configured statically by users,
e.g. in the CPA? In a CPA with a dozen CanSends, each would be
connected with a DeliveryChannel that references a Transport element that
contains a URL that include a substring naming that same DeliveryChannel. We
would be missing a generalization, which users and implementers will object
to.
<JD> Our assumption is that the
URL of the Hub (or Intermediary) is configuration data: e.g. it has to be
represented in the PMode that describes an end-to-end exchange. We do not see any problem with our own
implementation on top of Axis 2, in adding an HTTP query. Now we know that the CPA is a possible
representation for the PMode. The CPA has already been profiled / extended for
V3.0. It may have to be updated again for multi-hop, and with all due
respect for the CPA, I believe
a multihop solution(s) should
be designed independently from the current CPA (ebms specs are
supposed to work independently), then we can adapt/extend the CPA as
needed.
This being said, I don't believe that a
different DeliveryChannel has to be defined for each party or each CanSend when
the same Intermediary is used as TransportReceiver/Endpoint. An identifier must exist in the CPA (or
PMode) that defines a set of messages sent to the same destination with the same
level of reliability. (question: how do you know which message must be
associated with which RM sequence, in your solution?) This identifier is what
needs be communicated to the first intermediary (or Hub) in our solution, along
with CreateSequence. Whether already appended to the destination URL or
intended to be appended when the CPA is interpreted. I see this a CPA binding
question - probably needs be defined in a conformance
profile.
2) This proposal is based on features of HTTP as an underlying
transport protocol. Even if most ebMS implementations will use
HTTP, the idea that an ebMS multihop functionality ("level 3" in my
earlier terminology) has dependencies with transport protocols (two levels
lower) does not seem right architecturally. If someone defined another transport
protocol binding than HTTP for ebMS 3 0 (e.g. SMTP or JMS), he should be
able to use our multihop solution with those other lower level transport
protocols.
<JD> then let us
just say that the handhake part of our solution (initiating a new RM sequence)
is transport-binding specific (at
least, specific to the transport used between Sending endpoint and first
Intermediary). That wouldn't be the first ebMS feature the usability of which is
tied to a particular transport layer (e.g. Pull mode so far is not usable with
an underlying protocol that is not request-response , e.g. SMTP). It could
be that we don't have a solution for all
transports..
3) Page 5 "Step
4:
The Hub receives the message, and closes the HTTP connection (asynchronous
case). The Hub determines where this User Message must be sent, using routing
function based on ebMS header data". It would be better if the Hub
does a routability check (do I have a configuration rule that tells me where to
forward this message to?) before closing the connection. If it does not
know how to forward the message, the Hub could then return an ebMS error
directly. This means that a sender in a multihop context could receive
errors from both the ultimate recipient (as in the peer to peer case) and
from intermediaries.
<JD> good
point. A new type of error needs be created for Intermediaries (e.g.
"RoutingFailure")
4) I
have been thinking of an alternative way to do what you want using this
appended query. An alternative that to me seems more in the
spirit of the SOAP processing model, would be to allow messages to contain
more than one eb:Messaging SOAP header element. One eb:Messaging
block would be targeted at ebMS intermediary nodes, identified using a separate
"target" attribute. The other would be targeted at the true recipient, as
in v3.0 Core. The idea is analogous to having multiple WS-Security
header blocks, targeted at multiple SOAP nodes. Given our goal to converge with
WS-* specifications, it seems best to leverage their type of solutions to
similar problems.
The only required (compatible) update to the ebMS v3 0
schema is to add an optional "target" attribute to
eb:Messaging.
The
eb:Message block targeted at the intermediary could be used in various
situations:
- When
sending a wsrm:CreateSequence message, it would serve to provide rich business
document routingheader content (To/PartyId, Service) to enable the sequence to
be established with the right recipient MSH. Like the appended "?pmode=<ID>", this second header is not explicitly
mentioned in v3 0 Core. But v3 0 Core is assumed to be composable with
other WS-* specifications not discussed in v3 0 Core (say, WS-Addressing or
WS-SecureConversation) like any well-designed WS spec without this having to be
described in the v3 0 spec. It may be an acceptable price to pay, even for
Endpoints. In a Web Browser you have to configure something in your client
to use an HTTP proxy too, after all.
- But
the Sending endpoint could use the appended "?pmode=<ID>" trick to pass information to the first
intermediary that would allow to create the second ebMS header block as in your
proposal, if it somehow cannot be modified to create this second block
itself.
<JD>
When HTTP is used, the HTTP query trick has the advantage of not requiring more
than Core V3 Conformance - i.e. no ebms-level additional capability, like this
piggybacking of an eb:Messaging header on a CreateSequence message. And
even if we do so, we could probably reuse regular eb:Messaging headers (same
Core V3 schema) without creating a "target" attribute, if we rely instead on
SOAP processing features - i.e. use instead the standard "role" attribute
that SOAP2.0 headers support.
- Intermediaries could have same default logic as ebMS
2.0 to reverse route any ebMS (user or signal) message by reversing eb:From
and eb:To, copying eb:Service, eb:Action, eb:ConversationId, eb:AgreementRef and
setting eb:RefToMessageId based on incoming eb:MessageId. We only need
to think of a value for eb:Action. This model could be used to return a
standalone wsrm:CreateSequenceResponse to the sending MSH.
<JD> we thought of that. But that seems contrived. We
believe again that within an I-Cloud, routing should always be possible based on
the URL of the destination node, in case this URL is known (in many cases, a
single hop directly to this URL will be possible !) And that is usually the case
for a response: we know where it should go. more generally, the URL of the
Intermediary to which the response destination MSH is connected (the last hop
could be a Pull). Header data that tells where the Response should go, needs
then be added to the Request message by the first intermediary. That could be a
wsa header (ReplyTo) or another ebMS-level header
data.
- When sending an eb:Messaging/eb:SignalMessage, adding a
eb:Messaging[@target='intermediary'] structure could provide rich header
data to allow the signal to be routed across hops, even though the
Signal itself lacks business semantics. This would even work
for PullRequest which unlike eb:Receipt and errors is not a response message,
where the trick of rerouting based on retrieving data from the preceding
UserMessage using MessageId/RefToMessageId would not work.
<JD> right that
PullRequest was never considered for "routing" so far. But we believe that is a
low priority: the case for pulling across the entire I-Cloud has not been made
yet... So yes some "routable" header could be added to a response Signal.
But if doing so, it is better if the first intermediary on its way does this,
rather than the endpoint MSH because that would require more than core V3
conformance.
- When sending an eb:Messaging/eb:UserMessage,
adding a eb:Messaging[@target='intermediary'] structure would not be necessary,
if the ebMS header is not encrypted, so that its header elements can
be used for routing.
- When
sending an eb:Messaging/eb:UserMessage, adding a
eb:Messaging[@target='intermediary'] structure would allow the end-to-end ebMS
header to be encrypted by the first intermediary and decrypted by the last one
or by the recipient.
<JD> Possibly.
Although instead of adding a second eb:Messaging header, we could consider
instead an "eb:Routing" header that contains the subset of header values that
are set as "constants" in the PMode, if we admit that all messages related to
same PMode (or same CPA CanSend?) must be routed the same way. The first
Intermediary to which the endpoint MSH is connected would add this header, based
on PMode info (assuming here that an endpoint must "register" in some way to an
Intermediary that will serve as its gateway to the I-Cloud).
This has some advantages in cases where
(some of the) header data is sensitive too. The eb:Messaging structure
targeted at the intermediary could be copied from the end-to-end headers, or it
could have some derived generalized content (e.g. mapping many
From/PartyIds to a more general PartyId, e.g. the one of the first
intermediary). This would greatly simplify the maintenance of routing
tables at the intermediary, which would just have to know how to get from one
intermediary to another, not from any endpoint to any other endpoint. In
realistic use cases (e.g. hubs linking geographies, or various sectors) there
could be in the order of dozens of intermediaries serving thousands of
endpoints.
-
The last
intermediary could remove this header block before forwarding the message to the
Endpoint, as in your proposal.
- The second
ebMS header would never be needed in peer-to-peer ebMS
messaging.
Note:
the above attempts to use routing based on ebMS header data for all ebMS traffic
and WSRM lifecycle messages. This does not preclude the use of optimized
routing information, as in your proposal. If the endpoint somehow
pre-computes a way to express the HTTP URL of the ultimate recipient in a
WS-Addressing header, as a custom header, as an HTTP URL or as an IP
address, this could be encoded in the SOAP structure too. But before we
look at optimizations, I wanted to make sure the ebMS 2.0 style of header-based
routing can be used to cover end-to-end routing of user messages, signals and
reliability messages.
<JD> But the
main problem with ebms header-based routing of signals, is that Core V3
does not support adding such headers... note that even if you relax
this restriction, a "reverse-routing" based on exactly the same headers with
just a swap between FromParty and ToParty, assumes that the routing always works
with only ToParty. What if in a first
phase the routing uses "Service", then only for the last Intermediary, uses
"ToParty"? How can an intermediary tell if it must do reverse-routing or just
regular routing? I am not convinced this reverse routing system is viable - need
to see it described more completely.
-Jacques
Pim
