RE: [ebxml-msg] Pim on routing intermediaries, WS-ReliableMessaging

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

So we could call this option (already alluded to by Ian in a previous
call in November) the 2-tiered reliability, the main advantage of which
is that it does not require to route anything other than ebMS messages:

Level 1: WS-RM/R only needs be used between pairs of MSHs (so each path
segment is "independently reliable"), in other words the reliability
headers are changing across an intermediary, but not the ebMS header.

Level 2: additional ebMS signals allow for end-to-end doublecheck, by
synchronizing the status on both sides. E.g. sender will periodically
notify a list of "should-have-received"  ebMS IDs to receiver, and a
symmetric synchronization signal sent by receiver MSH, would notify of
what has NOT been received/delivered. Or conversely the receiver will
notify a list of "have-received". Remedial action need not be prescribed
(P-Mode will control) -  could range from just notifying the application
layer on either/both sender or receiver side, to re-issuing the missing
messages (from the ebMS layer, in order to avoid creating RM-level
duplicates that could be eliminated at next RM endpoint).

Some interesting aspects about this solution:
- the status synchronization is a useful feature in itself as we seem to
agree (awareness of loss by a receiver MSH allows better diagnostics on
failed choreographies, etc). 
- the ultimate receiving MSH may not have to support this feature in
order to have end-to-end reliability: the last intermediary has to.
Indeed, when getting the "should-have-received" signal, the intermediary
could be required to respond with only those messageIDs that it has
actually successfully forwarded, removing the last possibility of
"intermediary loss". E.g. it could be required to get the RM Ack of
ultimate receiver, before even sending the "have-received" signal. SO
that mode of reliability does not require an ultimate MSH to support
more than core V3 features. This is becoming in the CDC network case,
where MSH hubs serve clusters of endpoint MSHs. Even if last MSH is not
supporting RM, this enables "end-to-previous-to-end" reliability !

I am starting to like it.

So there seems to be two general modes of reliable ebMS multi-hop:

(1) The "flat reliability" mode, supported end-to-end by the RM layer.
Here, only the use of WS-Reliability really makes sense, as the routing
is supposed to be controlled by ebMS header info, even for establishing
RM sequences.

(2) two-tier reliability, where the RM mechanism from WS protocol is
only used per segment. Here both WS-Reliability and WS-ReliableMessaging
can be used between MSH pairs.


Jacques


-----Original Message-----
From: David RR Webber (XML) [mailto:david@drrw.info] 
Sent: Wednesday, November 28, 2007 6:46 AM
To: Durand, Jacques R.
Cc: Pim van der Eijk; ebxml-msg@lists.oasis-open.org; Moberg Dale
Subject: RE: [ebxml-msg] Pim on routing intermediaries,
WS-ReliableMessaging

Jacques,

Yes - I think the ability to do status checks definately beckons
eventually.

I like what you suggest - good lightweight logical next step.

During the BCM work and then ebBP - we identified the need in extended
collaborations to have a "linking and switching" status tracking
service.

This is way more than what's needed for message delivery of course - but
then again - the types of mechanisms could definately be interchangeable
/ reusable here.

Since right now each ebBP / ebMS is responsible for its own status
tracking - the obvious next logic step is to provide centralized status
checking services.  We've explored this model in BCM - the linking and
switching Appendix B spec' - which uses the Prolog assertion/retraction
predicate based approach.

At some point we will need to get serious about enabling that all -
would be a very cool facility - incredibly useful for all kinds of
applications...

; -)

Cheers, DW

> -------- Original Message --------
> Subject: RE: [ebxml-msg] Pim on routing intermediaries, 
> WS-ReliableMessaging
> From: "Durand, Jacques R." <JDurand@us.fujitsu.com>
> Date: Wed, November 28, 2007 9:06 am
> To: "David RR Webber (XML)" <david@drrw.info>,  "Moberg Dale"
> <dmoberg@axway.com>
> Cc: "Pim van der Eijk" <pvde@sonnenglanz.net>, 
> <ebxml-msg@lists.oasis-open.org>
> 
> David:
> 
> That sounds like re-implementing reliability at ebMS level - something

> I'd prefer to avoid until all other options fail to deliver :-)...
> Besides guaranteed delivery there is also duplicate detection (based 
> on sequence numbers or so for the 2 RM specs), so the redundancy is 
> starting to build-up.
> 
> Now, we may consider a mode of multi-hop reliability where RM is 
> per-segment, and in order to catch the cases of loss during router 
> forward, a kind of (ebMS) status request where the initial sender MSH 
> could notify the ultimate receiver MSH of the list of message IDs it 
> is supposed to have received over the last hour or so, and the 
> receiver MSH would notify back on what it has not been able to 
> deliver. Re-sending by the ebMS layer itself may or may not be 
> mandated - could be left to a re-submit at application level (if no 
> risk of duplicates). At least that would add awareness of both sender
and receiver of message loss (i.e.
> non-delivery), something we do not have today especially with WS-RM.
> This awareness by the receiver would in turn allow the choreography 
> layer to better diagnose failures.
> 
> Jacques
> 
> 
> -----Original Message-----
> From: David RR Webber (XML) [mailto:david@drrw.info]
> Sent: Monday, November 19, 2007 6:42 PM
> To: Moberg Dale
> Cc: Pim van der Eijk; Durand, Jacques R.; 
> ebxml-msg@lists.oasis-open.org
> Subject: RE: [ebxml-msg] Pim on routing intermediaries, 
> WS-ReliableMessaging
> 
> Dale,
> 
> I'm not sold on WS-Reliable messaging - for starters its merely trying

> to mimick what ebMS already has for the past five years!
> 
> Then - who knows what oversights they've made in the rush to get 
> something in place. Reading their design and such does not give me 
> great confidence. My sense is we are well ahead of them - and they 
> should be adopting ebMS reliable messaging (and actually they are 
> trying to clone most of it!!!)  Of people using WS the majority could 
> not careless about reliable delivery - in fact their whole modus 
> operandi is built assuming unreliable messaging and instant traffic
exchanges (query/response).
> 
> OK - so where does that leave us?
> 
> Why can we not look at some kind of orchestration agent here?  Seems 
> to me that what is needed is a very simple component that is tasked 
> with plugging the gap and acting as an ebMS/SOAP delivery extension
agent.
> All it has to be able to do is manage SOAP-based exchanges at the 
> basic transport level.  If its built very dumb and simple - it just 
> acts as a relay and a pass through - with minimal logic - mostly just 
> leveraging SOAP acks and errors themselves.
> 
> The ebMS then interacts with one or more of these SOAP relay agents - 
> and will keep trying delivery until it gets an end-to-end SOAP 
> acknowledgement relayed back to it.
> 
> The agent could be designed to use basic WS - and in fact then any 
> SOAP server could be integrated as a delivery service with the simple 
> addition of the agent component.  This seems much more like what we 
> want.  Coopting delivery via SOAP servers.
> 
> DW
> 
> "The way to be is to do" - Confucius (551-472 B.C.)
> 
> 
> > -------- Original Message --------
> > Subject: [ebxml-msg] Pim on routing intermediaries, 
> > WS-ReliableMessaging
> > From: "Moberg Dale" <dmoberg@axway.com>
> > Date: Mon, November 19, 2007 3:32 pm
> > To: "Pim van der Eijk" <pvde@sonnenglanz.net>,  "Durand,  Jacques
R."
> > <JDurand@us.fujitsu.com>,  <ebxml-msg@lists.oasis-open.org>
> > 
> > [Pim explained the conflict between WS-ReliableMessaging and the 
> > advantages in using routing intermediaries.]
> > 
> > The main options for dealing with the conflict are
> > 
> > 0. Use WS-Addressing anonymous for reply-to and acks-to, and have 
> > all intermediaries wait before their HTTP reply is made.
> > [The above does not scale well, is brittle, and utilizes lots of 
> > resources.]
> > 
> > 1. Use piggybacking (and presumably 1 message long sequences?).
> > [Still lacks routing advantages. RMSes have to target RMDs, and so 
> > have high lifecycle configurability burdens. Routing intermediary 
> > topology cannot be changed while leaving RMS configuration
unchanged.
> > Probably destroys advantages of ebMS routing intermediary, as Pim 
> > explained.]
> > 
> > 2. Locate RMD at routing intermediary, and check security at 
> > intermediary also.
> > [ Loss of end to end reliability.]
> > 
> > 
> > Pim has convincingly explained how WS-ReliableMessaging is not very 
> > intermediary friendly and, along with Jacques, reflects a step 
> > backwards in trying to accommodate intermediaries with end-to-end
> acknowledgments.
> > However, the goal of WS-* technology level convergence seems to 
> > require that we support WS-ReliableMessaging because it is the WS-I 
> > sanctioned solution.
> > 
> > Is option 2 above an option that could be embellished to be 
> > satisfactory? What would it take? Add on an ebBP/RN style 
> > ReceiptAcknowledgment or ReceiptAcknowledgmentException (if we 
> > wanted to be optimistic with respect to WS-ReliableMessaging 
> > terminated at intermediary working most of the time?)
> > 
> > Just some reactions. Good analysis Pim!
> > 
> > 
> > 
> > --------------------------------------------------------------------
> > - To unsubscribe from this mail list, you must leave the OASIS TC 
> > that generates this mail.  You may a link to this group and all your

> > TCs in
> 
> > OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.p
> > hp