RE: Expanding Reliable Messaging to meet the needs of IOTP

[Marc Breissinger <marcb@webmethods.com>]

David,

I think the issue you raise is important, but it is a symptom of a larger
problem: we have, up to this point, avoided specifying how the ebXML
Messaging Service supports a synchronous, request-response style of
interaction.

I agree with you that the "ack" is not necessary if you have a
request-response interaction style (i.e., the response functions as both the
ack and the response).  I believe we should make this explicit in the RM
specification.  Your use of the HTTP Response to illustrate this scenario is
transport binding specific, but the concept applies across other protocols.

I disagree with your assertion, however, that an "ack" is not necessary at
all.  Asynchronous, event-based business processes requires the use of
acknowledgements as there is usually no expected response.

marc

> -----Original Message-----
> From: David Burdett [mailto:david.burdett@commerceone.com]
> Sent: Monday, August 21, 2000 11:31 AM
> To: ebXML Transport (E-mail)
> 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