Reliable Messaging over Synchronous Transports

["Burdett, David" <david.burdett@commerceone.com>]

Folks

Last week Chris and I got into a debate over supporting the reliable
messaging needs for IOTP. At the end of last week Chris and I discussed this
on the phone and agreed that what we were talking about was the need to do
reliable messaging over synchronous transports. The rest of this email
provides a usecase that explains why using the message that contains the
business response as an acknowledgement is needed for synchronous
transports. 

Chris, I've mis-represented anything please let us all know.

David
=============
RELIABLE MESSAGING OVER SYNCRHONOUS TRANSPORTS - Use Case

BACKGROUND
This use case describes a situation where:
*	a small business has PC running:
*	their "enterprise software" e.g. QuickBooks, and 
*	a web browser (http client)
*	the business wants to use QuickBooks to make an immediate payment to
their bank by:
*	sending a payment request, and then 
*	receiving an immediate  payment response that contains a receipt
that proves that payment was, or will be made
*	they want to send the payment request **reliably** using "at most
once" delivery semantics since:
*	the need to know that the payment was made by a specific time to
meet a business requirement (this means email would be too slow)
*	they don't want to pay twice because of accidental duplicate
delivery of the payment request message by the data communications protocol

In addition:
*	the bank's payment service operates in real time and can provide
immediate acknowledgement that the payment has (or will be) paid by a
specific time.
*	the small business does not want to operate their own web server as
they see no business benefit in doing so.

ANALYSIS
1. Email is too slow to meet the business requirement. Therefore the only
viable data communications protocol that will be fast enough and is widely
available is HTTP.

2. The small business can only, therefore, access their banking service via
an http client. This means that:
*	the banking service cannot later "push" a payment response message
asynchronously back to small business (remember email is too slow), and
therefore
*	the banking service has to send the payment response on an HTTP
response that is a result of an earlier HTTP post.

3. There are two ways in which the payment response could be delivered on an
HTTP response:
*	the small bussiness keeps sending HTTP posts to the banking service
to check if the payment had been made, eventually it will be and so the http
response will contain the result, or
*	the payment response is sent on the HTTP response for the HTTP post
that contained the payment request.

4. Since the banking service can provide an immediate response to the
payment request, the best way for the banking service to send the payment
response is on the HTTP response to the HTTP post that contained the payment
request.

RELIABLE MESSAGING
Once the payment response is received, it means that small business can
conclude that the payment response was received and has been actioned. No
other acknowledgement is necessary from either a business or technical point
of view.

Reliable messaging can then be achieved with the following logic (note this
is only an outline) ....
1. If the small business does not receive a payment response within a
defined period then there is a "timeout" and the original payment request is
resent
2. If the banking service receives a duplicate message then it knows to:
  a) send back a copy of the response previously sent, but otherwise ...
  b) completely ignore the payment request and not re-process it

This is the same logic as is used when doing reliable messaging over
asynchronous links with "acks". In this case ...
1. If an acknowledgment message is not received within a defined period then
there is a "timeout" and the original message is resent
2. If the receiving service receives a duplicate normal message then it
knows to:
  a) send back a copy of the acknowledgement previously sent, but otherwise
...
  b) completely ignore the message and not re-process it

So all we need to do to support both synchronous and asynchronous approaches
in the current spec is to allow ebXML messages with a MessageType of
"Normal" to act as an acknowledgement for an earlier "Normal" message, and
use the "RefToMessageId" to identify that it is a response. Note that this
would be an additional alternative to using an acknowledgement -
acknowledgement messages are still needed.

ALTERING THE SPEC
Chris and I concluded that perhaps the best way to go forward was to alter
the spec as follows:
1. In the normative part of the spec, allow a Message Type of either
"Acknowledgement" or "Normal" act as the proof of receipt of an earlier
"Normal" message.
2. Include in a non-normative appendix, guidelines on when each type of
acknowledgement should be used, esentially:
  a) use a separate acknowledgement message when asynchronous messaging was
possible (either over HTTP or SMTP)
  b) using the message carrying the business response as the
acknowledgeement if synchronous messaging was being used.

Does this make sense?

David

Product Management, CommerceOne
4400 Rosewood Drive 3rd Fl, Bldg 4, Pleasanton, CA 94588, USA
Tel: +1 (925) 520 4422 (also voicemail); Pager: +1 (888) 936 9599 
mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com