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.
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.
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.
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.
- 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.
- 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.
- 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. 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.
Pim
