RE: Expanding Reliable Messaging to meet the needs of IOTP

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

Chris

Two main issues ...

POINT ONE
I fundamentally disagree with you when you say ...

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

This statement can ONLY be true IF THERE IS ONLY ONE WAY TO TECHNICALLY
SOLVE A PROBLEM which clearly is not true. I also assert that you cannot
PROVE that something can only be solved using "kludgy whacked out code"
since what would stop someone from solving the problem simply and elegantly.
Unless you can prove it is impossible to write elegant code then your
statement is fundamentally wrong.

Anyway, to stop this getting in to a slanging match ;) What I will do (but
folks please give me time - I have a day job) is write up a solution which
solves the problem pretty elegantly based on a set of pseudo code that I
wrote to solve exactly this problem for IOTP.

So Chris, I think the jury's out on this one.

POINT TWO
Whilst I agree that we want to follow the KISS principle. We must support a
reasonable set of use cases, that represent how eCommerce is actually being
used today otherwise ebXML will not be adopted. Although synchronous
responses are needed for IOTP, they aren't the only cases. Commerce One's
"RoundTrip" and Ariba's "PunchOut" which both do similar things, both need a
synchronous messaging system.

So, again, to stop this getting in to a slanging match, the solution is to
develop an alternative that proves that this is pretty simple to do. Again I
will do this, but I need the time.

David
PS I am about to go into a day-long meeting and might not be able to
continue this conversation until next week.

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
Sent: Friday, August 25, 2000 7:27 AM
To: David Burdett
Cc: 'mwsachs@us.ibm.com'; ebXML Transport (E-mail)
Subject: Re: Expanding Reliable Messaging to meet the needs of IOTP


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