RE: Reliable Messaging over Synchronous Transports

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

Rik

I believe that:

a) I have described a use case that demonstrates that there is a clear
requirement for this functionality
b) It is simple to do without violating the layers

I suggest we put this topic to a vote.

David

-----Original Message-----
From: richard drummond [mailto:rvd2@worldnet.att.net]
Sent: Thursday, September 07, 2000 4:34 AM
Cc: ebXML Transport (E-mail)
Subject: RE: Reliable Messaging over Synchronous Transports


lets not confuse things. lets think of the 1974 osi protocol 7 layer stack
model. seven layers each layer (transport) talking to it counterpart layer
(transport) via a 'protocol' each layer talking to the other layers,
directly above and below via 'services'. the ms ack is part of the ms
protocol and has nothing to do with ack's for the above layers. if the above
layers need an ack they should implement it independently or ask the ms
layer, through a service interface if it got an ack. the ack for the ms
layer is NOT an ack for the layer above or below it.

this is the old issue, which continues to come up in our discussions about
applications vs. transport. they should not be intermingled..

best regards, rik





-----Original Message-----
From: Marc Breissinger [mailto:marcb@webmethods.com]
Sent: Wednesday, September 06, 2000 11:32 AM
To: Burdett, David; 'Martin W Sachs/Watson/IBM'
Cc: ebXML Transport (E-mail)
Subject: RE: Reliable Messaging over Synchronous Transports


> If I am right, it would seem that the messaging service specification
> should recommend that the MS acknowledgment not be used when an
> acknowledgment is provided at the transport level.

If I am interpreting the comments below correctly, I don't agree.  The
reliable messaging ack guarantees certain actions have taken
place at the receiver (i.e., information sufficient to detect duplicate
message receipt has been hardened), whereas the simple
transport acknowledgement provides no such guarantee.  It does not,
therefore, seem correct to me to say that the MS ack is "not to
be used."  I believe that the MS ack must always be present.  Where it is
physically present is dependent upon the transport
binding.  In the case of the HTTP transport binding, the MS ack message may
be included in the HTTP response (simple ack in Marty's
example), but it is still an MS ack -- i.e., a fully formed ebXML message is
the content of the HTTP response.


>> 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.

I don't really like the idea of allowing one "type" to act as another,
especially when MessageType is an enumerated attribute.  If
we want to allow for this behavior, I believe the more appropriate way to do
it is to change the specification to make MessageType
an element within the ebXMLHeader rather than an attribute.  The idea is
that MessageType becomes more of a "role" specification,
because a message, at the MS level, can play multiple roles in this
scenario.  It might look something like this:

<ebXMLHeader xmlns="http://www.ebxml.org/namespaces/messageHeader"
Version="1.0">
    <MessageTypeInfo>
        <MessageType>Acknowledgement</MessageType>
        <MessageType>Normal</MessageType>
    </MessageTypeInfo>
    <Manifest>...<Manifest>
    <Header>...<Header>
</ebXMLHeader>

Using this scheme, an MS error message could also function as an ack if
circumstances required.  Note that both proposed schemes
(David's and mine) rely on the fact that an MS ack contains no payload.
Allowing this behavior, whatever form it takes, does
prevent us from ever putting payload into the ack (e.g., to enumerate the
messages being acknowledged in a group, or something we
haven't thought of).

Thus, Marty's example could be reduced to:

    HTTP POST from A to B (message type "Normal")
    HTTP response from B to A carrying the business response (message types
"Acknowledgement" AND "Normal")
    HTTP POST from A to B (message type "Acknowledgement")
    HTTP response from B to A carrying *no* ebXML content

marc

==========================================================================
Marc Breissinger                                   voice (W): 703-460-2504
Director, Product Strategy - webMethods, Inc.      voice (C): 703-989-7689
Email:  marcb@webmethods.com                               We're hiring!!!
Email2: breissim@earthlink.net              URL: http://www.webmethods.com
==========================================================================


> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Tuesday, September 05, 2000 9:08 PM
> To: 'Martin W Sachs/Watson/IBM'
> Cc: ebXML Transport (E-mail)
> Subject: RE: Reliable Messaging over Synchronous Transports
>
>
> Marty
>
> I agree too.
>
> David
>
> -----Original Message-----
> From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
> Sent: Tuesday, September 05, 2000 3:25 PM
> To: Burdett, David
> Cc: ebXML Transport (E-mail)
> Subject: Re: Reliable Messaging over Synchronous Transports
>
>
>
> To me, this makes a lot of sense.  In fact, these cases are covered by the
> tpaML proposal.
>
> I believe that for the asynchronous case, the informative text should
> recommend that the original message be persisted before the acknowledgment
> message is sent.  This should be done whether the acknowledgement is at
the
> transport level or at the message service level (message type
> "acknowledgment). Otherwise, the message could be lost at the recipient
> even though the acknowledgment message was sent.
>
> It appears that where two businesses have HTTP server capability and are
> performing asynchronous exchanges with HTTP, there could be two levels of
> acknowledgment before the business response is sent, thus:
>
>    HTTP POST from A to B
>    HTTP response from B to A (simple acknowledgment)
>    Messaging Service acknowledgment from B to A (message type
>    "acknowledgment")
>    HTTP POST from B to A carrying the business response (message type
>    "normal")
>    HTTP response from A to B (simple acknowledgment)
>    Messaging Service acknowledgment from A to B
>
> If I am right, it would seem that the messaging service specification
> should recommend that the MS acknowledgment not be used when an
> acknowledgment is provided at the transport level.
>
>
> 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
>
****************************************************************************
> *********
>
>
>
> "Burdett, David" <david.burdett@commerceone.com> on 09/05/2000 05:46:17 PM
>
> To:   "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
> cc:
> Subject:  Reliable Messaging over Synchronous Transports
>
>
>
> 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
>
>