OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [ebxml-msg] a mix bag

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.

From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
Sent: 26 March 2008 01:25
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] a mix bag

"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).

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]