[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Federated systems and Guaranteed Delivery of messages
|
All; There are three places where Guaranteed Delivery is
critical. This is based on the OASIS EDXL-DE structures design capability
to transverse multiple distribution systems and networking protocols and still
provide delivery service. 1.
The first issue is when true streaming or semi-streaming sensor
detection (e.g. not transaction capable) are being routed to an authoritative information
repository with higher bandwidth and data responsibility. This may need
to be identified by recipient’s subscription for data stream. The
issues arises when the data repository has become unavailable. The need
for “error to” notification is a requirement to notify information repository
personnel of non-availability and/or users and business processes using the
authoritative information repository data . There is a secondary issue of
what to do with data which cannot be delivery. 2.
The second issues arises from federating disparate distribution
system which exchange OASIS EDXL-DE structures with each other. The issue
is similar to issue one where the other distribution system replaces the
authoritative information repository. 3.
The third issue arises from delivery to high consequence automated
systems like EAS and CMAS. This is an information architecture issue which should be
considered for designing and subsequently federating an OASIS EDXL-DE
distribution system with larger OASIS EDXL-DE distribution infrastructure. David E. Ellis (505) 844-6697 From: McGarry, Donald P.
[mailto:dmcgarry@mitre.org] 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. From: Hans
Jespersen [Hans.Jespersen@SolaceSystems.com] 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]