Re: Expanding Reliable Messaging to meet the needs of IOTP

[Christopher Ferris <chris.ferris@east.sun.com>]

I fundamentally disagree with this notion. The business level
response is just another message. It cannot be interpreted as
an ack without all kinds of kludgy whacked out code which the
MS must process to figure out which way is up.

The MS should have a minimal set of functionality:
	send/receive a mesage, match to conversation, route to service handler
	send/receive an MS-level ack or error, process accordingly

which could be optimized with the windowing technique to:
	send/receive a window of messages, match to conversation, route to service handler
	send/receive an MS-level ack or error, process accordingly

Suggesting that a business message could double as an ack
would require all kinds of nasty logic at the
MS level which would impede performance to no end because each
receipt of a message would have to be analyzed to death. 
Not only that but the design of the choreography would be overly complicated
IMO.

The MS should be lean and mean with a minimum of boolean logic.

Chris

David Burdett wrote:
> 
> >>>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

-- 
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903