- 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.
Here I think you have
very different deployment scenarios and user communities in mind than
I. The existing ebMS 2.0 multihop users I know (and whose
interest I have in
mind) operate in environments where intermediaries are used to
bridge private networks. Message handlers are not supposed to directly
connect beyond one intermediary. They're not supposed to know the URL of
intermediaries beyond the one they're connected to immediately, but if they
knew, that URL wouldn't be in their DNS. If they knew the IP
address, it would be an address in a different VPN that they can't even
ping to.
- 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.
Yes, perhaps at an upcoming call or
F2F
-Jacques
Pim
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]