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.

 

Pim

 

From: Durand, Jacques R. 
[mailto:] 
Sent: 26 March 2008 
01:25
To: 
Subject: 
[ebxml-msg] a mix bag

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