Hello Jacques,
You are right that my proposed scenario assumes
that the intermediary provides failover. Some ebMS 2.0 intermediary
deployments are in fact built on clustered messaging application servers,
clustered database servers and clustered file systems, mirrored over multiple
locations. They are designed to handle exactly the failure scenarios you
describe, so if clustering is required to support ebMS 3.0 multi-hop, this is
not a new requirement for them. I do agree that
any solution that does not require clustering just to support end-to-end
reliable messaging is preferable, and the simpler the requirements for
intermediaries (or at least for "routing" intermediaries), the
better.
Pim
Pim:
"For example, for k=3 and n=450, there would have to be 606150
level 3 end-to-end sequences to set up, compared with only 2700 level 2
sequences"
Just a note: I don't think
these two alternatives are at different "levels" ( In your diagram in
Introduction, why should the ebMS intermediary be at SOAP level (level 2) while
the endpoint MSHs are at "ebMS level (3) ? both are doing ebMS-level
processing, if only for routing, and both handle RM processing at same level -
SOAP RM headers.)
You are right that in this use
case, the overall number of RM sequences is much less for the entire network.
But a big difference, is that the risk of managing them all is here
concentrated on the Hub. If the Hub crashes or is down for a while, and other
alternative paths have to be found between a Sender endpoint and a Receiver
endpoint, then the Sender endpoint may want to resend non-acknowledged messages
via another route. That becomes a mess with a smart Hub doing "relayed
Acks":
- these resends cannot be
controlled in the usual way by Sender RM layer as they need to be done over a
new RM sequence for the alternative Hub. So the ebMS layer has to be in charge
of tracking these failures (fair enough if we assume a processable "delivery
failure notification") but also of re-submitting to its RM module these
non-acknowledged messages for a new sequence, in an automated way. Not a
natural behavior for a common MSH.
- these resends might end-up
generating many duplicates (after all, the Acks might have been on their way
when the Hub #1 crashed.). The only way to detect these duplicates that are
resent over a different sequence, is via their eb:MessageId. Again, something
that endpoint MSHs are not prepared to do as they were delegating this to
their RM module.
You could argue that the Hub
must be designed to withstand such failures, e.g. advanced failover technique
that takes over persistent RM tables,etc. But isn't that engineering level to
ensure reliability a high price to pay for allowing endpoint MSHs to use fewer
sequences, when we could achieve same or better reliability with
dumbed-down Hubs?
--------------- stepping back
one level ;-)
It appears that there are very
diverse multi-hop requirements and scenarios that could occur, and that a single
solution will not fit all.
So far we have been dancing
around two main multi-hop RM designs that have been fairly well investigated,
each one having its weak scenarios but each one could claim some unique
benefits.
We could settle for specifying
these two. These could be two conformance profiles for Intermediaries.
Because
:
- in both cases the
endpoint MSHs are not affected, and do not need to "know" which kind of
Intermediary is deployed in order to operate,
- both types of
intermediaries could be combined in the same I-Cloud, e.g. a Gateway connecting
a public "end-to-end RM" I-Cloud to a private domain will want to relay acks
across these two domains and keep full control on its RM sequences while
handling outside security.
Then I do not see this
*diversity* of solution as an interoperability threat (while I still believe the
relayed acks technique in itself poses interop challenges !).
It seems to me that the only
differences in endpoint MSH behavior is mostly an optimization concern (e.g. use
same RM sequence across PModes vs. one per PMode) and can be resolved at
configuration level (PMode.Reliability).
Jacques