[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Reliable Messaging over Synchronous Transports
I don't quite agree regarding my example. The example I gave was for an
asynchronous response via HTTP, so that the business response is not in the
response to the initial post. However I agree that where possible, the MS
ACK information should be included in the transport response.
Also, for the synchronous case, it seems to me that if the business
response is present in the HTTP response, there is no need to also include
the MS acknowledgement - if the HTTP POST message got to the application,
it should be able to be assumed that the MS had no problem with the initial
message.
The correct restatement of my asynchronous example is:
HTTP POST from A to B
HTTP response from B to A (HTTP acknowledgment including MS
acknowledgment)
HTTP POST from B to A carrying the business response (message type
"normal")
HTTP response from A to B (HTTP acknowledgment including MS
acknowledgment)
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
*************************************************************************************
Marc Breissinger <marcb@webmethods.com> on 09/06/2000 12:32:11 PM
Please respond to marcb@webmethods.com
To: "Burdett, David" <david.burdett@commerceone.com>, Martin W
Sachs/Watson/IBM@IBMUS
cc: "ebXML Transport (E-mail)" <ebxml-transport@lists.ebxml.org>
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
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC