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] Pim on routing intermediaries, WS-ReliableMessaging


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


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