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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-if message

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


Subject: RE: Guaranteed Delivery of messages


I agree.  We have opted to use AQMP running on Apache Qpid and XMPP with AMP which both offer guaranteed delivery handled at the application layer, which is most likely different from Solace's implementation, but provides the capability nonetheless.
 
As Hans has stated there are much larger implications for actually doing this correctly other than a single element with an address.  The larger issue for me is that if someone sends me a DE message with the optional replyTo field filled in with an e-mail address, this requires my system to be able to send email, if it has an XMPP address I need an XMPP server, if it has a SIP endpoint I need a SIP client.  With the multitude of possible fields that could be placed in that field I think this issue presents a scenario in which our standard could not function across systems, thereby bringing into question our level of interoperability among systems.
 

Don McGarry

Office: 315-838-2669

Cell: 703-595-9375

dmcgarry@mitre.org


From: Hans Jespersen [Hans.Jespersen@SolaceSystems.com]
Sent: Tuesday, June 29, 2010 11:52 PM
To: emergency-if@lists.oasis-open.org
Subject: [emergency-if] Guaranteed Delivery of messages

At the F2F meeting today we spoke about how to guarantee the delivery of EDXL-DE messages end to end between two or more senders and receivers, and in a way that is independent of transport protocol. This is more than just hop by hop or single transport guaranteed messaging which is what we implement today in several implementations.

 

OASIS has a lot of past history in the design of these kind protocols. OASIS created the WS-Reliability standard and later the WS-ReliableMessaging standard both of which are designed to accomplish exactly this task. See http://en.wikipedia.org/wiki/WS-Reliability and http://en.wikipedia.org/wiki/WS-ReliableMessaging for more background on these efforts. I have also included the WSRM spec for review so everyone can see that this is a similar use case to the one we are considering for the Reply-To element and ACK  distributionType.

 

I believe that at a minimum we would have to implement most of the XML elements that the OASIS WS-ReliableMessaging standard uses to accomplish this similar task. That means adding Sequence numbers, Message ID Numbers, Transport independent Addresses, Retransmission flags, Possible Duplicate Flags, Negative ACK messages, etc.

 

It took OASIS over 3 years to create these simpler protocols and they had participation from many of the vendors in the Message Oriented Middleware community (IBM, Microsoft, Oracle, BEA, Sun, TIBCO, Sonic, WebMethods, etc.). My recommendation is that we consider this functionality out of scope for EDXL-DE and recommend the use of OASIS WS-ReliableMessaging, or any one of the many other non-SOAP standards and products that implement guaranteed messaging at the transport level (i.e. Java Messaging Service, Distributed database Transactions, …). The use of guaranteed messaging protocols at the transport level will still allow for an audit trail and non-repudiation of receipt of EDXL-DE messages so the use case for this feature is still satisfied in an implementation specific manner.

 

-hans

 

--

Hans Jespersen

Principal Systems Engineer

Solace Systems Inc.

2051 Landings Drive, Mountain View, CA 94043

Phone: (650) 924-2670

hans.jespersen@solacesystems.com

http://www.solacesystems.com

 



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