RE: Expanding Reliable Messaging to meet the needs of IOTP

[mwsachs@us.ibm.com]

Dave,

Thanks for forwarding my posting to the whole list.  In my system, I have
to push two buttons to get the cc to the list.

In the IBM Research prototype, synchronous responses to an HTTP message are
sent in the HTTP acknowledgment.  Asynchronous responses are done using a
separate HTTP request in the other direction.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



David Burdett <david.burdett@commerceone.com> on 08/21/2000 03:05:10 PM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
Subject:  RE: Expanding Reliable Messaging to meet the needs of IOTP



>>>However I am concerned about relying on the business-level response as
the confirmation of receipt of the message because business-level timeouts
can be very long<<<

I agree which is why I'm proposing that the business-level response is an
*alternative* as some business processes can be very short and a separate
acknowledgement unnecessary. We can easily include the way in which
reliable
messaging receives its acknowledgements through in the TPA.

I'm also not sure that if you are having a pseudo-real-time conversation
that occurs in IOTP, that using a separate acknowledgement actually works
on
HTTP (can anyone advise).

David
PS Sending to whole list since that is what I reckon Marty intended to do.

-----Original Message-----
From: mwsachs@us.ibm.com [mailto:mwsachs@us.ibm.com]
Sent: Monday, August 21, 2000 10:45 AM
To: David Burdett
Subject: Re: Expanding Reliable Messaging to meet the needs of IOTP


Dave,

Your suggestion has merit.  However I am concerned about relying on the
business-level response as the confirmation of receipt of the message
because business-level timeouts can be very long (consider a request which
initiates a human workflow or requires the requestee to communicate with a
subcontractor first).  Waiting that long to discover than the request was
dropped by the network seems undesirable. However many of the transports
that will be used below the messaging service already have acks prescribed
in their protocols.  If the implementation persists the message before
sending the transport-level ACK, we should be covered without an extra
layer of function.

One case where the existing proposal seems to make sense is with SMTP since
SMTP has no end to end acknowledgment on a multihop path.

Regards,
Marty

****************************************************************************

*********

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
****************************************************************************

*********



David Burdett <david.burdett@commerceone.com> on 08/21/2000 11:30:37 AM

To:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
cc:
Subject:  Expanding Reliable Messaging to meet the needs of IOTP



Folks

I suggest that reliable messaging should be expanded, so that, instead of
sending an ack, to imply that the message has been received, an alternative
would be to use the next "normal" message received instead.

The reason I suggest this is because this is how the Internet Open Trading
Protocol (RFC 2801) does it and I'm not sure that the current Reliable
Messaging spec will support this method of working. In outline what happens
is illustrated by the following:

1. Customer sends a "Payment Request" message to a Payment Handler (e.g. a
bank) - using a HTTP Post
2. The Payment Handler processes the Payment Request and sends a "Payment
Response" message on the HTTP Response
3. If the Payment Response is not received in time, a timeout occurs and
the
Customer resends the Payment Request
4. If the Payment Handler receives a duplicate Payment Request, then they
resend the Payment Response that they sent previously, but otherwise
ignores
it

No separate acknowledgement message is needed since the receipt of the
Payment Response by the Customer implies that the Payment Request has been
received.

Thoughts?

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