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

["David RR Webber \(XML\)" <david@drrw.info>]

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