[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 -- Principal Systems Engineer Solace Systems Inc. hans.jespersen@solacesystems.com |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]