Re: Requirements for reliable message delivery

Thanks for the responses to Brian's posting on requirements for reliable
message delivery. I'll try and provide some of the background behind the
draft submission.

Firstly, what do we mean by a message. As has been said, there are many
uses of the term from instant messaging to EDI. The requirements we see are
for reliable delivery of messages as part of some distributed business
processing where the guarantee of delivery is a service provided by some
message oriented middleware and not the responsibility of an application.
The application simply assumes that the middleware will deliver the message
to its destination and the delivery will be idempotent. At a simple level,
this may be the delivery of a form from a browser to a server as part o a
business to consumer service. At a most complex level, this may include
messages flowing between components of a distributed supply chain
implementation. Another example may be the reliable delivery of EDI
messages. An intermediate level may be the batching of messages generated
by a complex shopping basket implemented as a multi-frame browser.

Also in this context, we see the message as being opaque. The contents of
the message structure should not be governed by the requirement for
reliable delivery. As a member of the W3C XML Protocol WG and also ebXML, I
am aware of the work going on in defining reliable protocols in those WGs.
However, they assume that the message being delivered has a particular
structure. I have no problem with this for new compliant message sets and
applications that may be developed in the future, but existing message
formats such as EDI or other "binary" messages need to be delivered
reliably. Therefore there is a requirement for the reliable delivery of
opaque messages.

From our experience with reliable transactional messaging, we believe that
a single hop approach is the starting point. Certainly end-to-end
reliability is required at an application level, but we believe this should
be built on a single-hop model with multiple hops being considered as
cascaded single hops. An important consideration here is transactionality.
The complexity of distributed 2 phase commit can be simplified by adopting
the single hop model. A unidirectional message over a single hop can be
managed as a single unit of work with commit/rollback being applied when a
message is reliably delivered to the endpoint. Therefore in an asynchronous
request/response single hop model, there are three units of work - the
request, the processing and the response. This extends to the multi hop
case so for N hops, there are 2N +1 units of work. Issues such as
end-to-end security, authentication, non-repudiation etc can then be
implemented at the application layer on top of the messaging.

A reliable messaging protocol requires the definition of "state machines"
at the endpoints of the single hop together with state information
transferred as part of the message between the endpoints. These may be
abstracted to a set of operations that we have briefly described in the
requirements document. Separation of the state machines from the state
information means that alternative bindings of the state information to
different transports can be implemented. The choice of HTTP in our
requirements comes about from customer feedback. In spite of the
deficiencies of HTTP, it is the de-facto infrastructure on the Web and
adding reliability to it is seen as important. How that is achieved and
whether HTTP is the only transport is another discussion. If the state
machine is separated from the state information, then alternative
approaches using APEX or SOAP are valid.

Hope this adds some further background to the draft,
John

XML Technology and Messaging,
IBM UK Ltd, Hursley Park,
Winchester, SO21 2JN

Tel: (work) +44 (0)1962 815188        (home) +44 (0)1722 781271
Fax: +44 (0)1962 816898
Notes Id: John Ibbotson/UK/IBM
email: john_ibbotson@uk.ibm.com

Received on Friday, 23 November 2001 10:21:17 UTC