FW: [ebxml-dev] ebMS Asynchronous Binding to HTTP

["Mike Dillon - Drummond Group" <mike@drummondgroup.com>]

-----Original Message-----
From: Mike Dillon [mailto:mikedillon@attbi.com]
Sent: Wednesday, June 25, 2003 11:47 AM
To: Patrick Yee; james.wowchuk@marketboomer.com;
ebxml-dev@lists.ebxml.org
Cc: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-dev] ebMS Asynchronous Binding to HTTP


 This is a complicated issue that directly affects key MSH design choices.
 I suggest that the messaging Committee discuss this and issue a
 recommendation, if thats possible per OASIS procedures.

 I believe the intention of the ebXML Messaging Specification is that
	1) There is a clear seperation between the protocol stacks
	2) The ebXML level Acknowledgment is the event that tells you
		the message has been received

 My personal point of view is I would like to see the specification state
 1) A receiving MSH MUST attempt to return the http response before
returning
	an ebXML level acknowledgment
 2) The message orginator must anticipate that due to processing,network
	or load balancing anamolies an asynchronous ebXML level acknowledgment
	may be received prior to receiving the original synchronous http response.
	The message originator SHOULD handle this scenario gracefully, and rely on
	the ebXML level acknowledgment as the event that signals the message has
been
	successfully received.

 In other words, I believe that the MSH systems should be designed to
 always return the http response first, and to gracefully handle the
 unusual situation where having sent a message, the ebXML acknowledgment
 is received back before the http response is received back.

 Its worth noting that AS2 has incorporated such language, mostly due to the
fact
 that large messages are commonplace in the AS2 world, and if the http
response
 is not returned in a timely fashion you run into timeouts, out of synch
 transactions and resource/thread issues. The latest AS2 version states
 	"When handling an asynchronous request, the HTTP response must be
	sent back before the MDN is processed and sent on the separate connection."
 An MDN is a Message Disposition Notification, effectively the same as an
ebXML
 level acknowledgement.

 I skimmed through the RosettaNet RNIF specification and I could not find a
discussion
 on this point.  Im curious how other async messaging services that sit on
top of HTTP deal
 with this issue...

 Mike Dillon
 Drummond Group, Inc
 mike@drummondgroup.com
 817 875 0794


-----Original Message-----
From: Patrick Yee [mailto:kcyee@csis.hku.hk]
Sent: Wednesday, June 25, 2003 10:01 AM
To: james.wowchuk@marketboomer.com; ebxml-dev@lists.ebxml.org
Subject: Re: [ebxml-dev] ebMS Asynchronous Binding to HTTP


> There is an inherent danger if a MSH Ack is sent before the HTTP or TCP
> protocol has completed properly on the original message, either async or
> sync.  It is very easy for say a responding application to post a buffer
of
> data to the network transport layer without error.  It is only when a
> graceful close completes that one can be assured ALL the data was received
> properly.  Where both parties are not in agreement, the situation could
> arise where the say responding MSH may re-send or duplicate the message,
> requiring the receiving to eliminate duplicates.  This requires a higher
> level of MSH intelligence.  However the alternate situation could occurr
> where the responding MSH will NOT resend, but the receiving MSH will throw
> away what it got because of the network error - a reasonable action I
> believe.  So in this case, one party thinks it complete, while the other
> does not.  On some business transactions re-issuing the request may not be
> acceptable.

My feeling is, MSH Ack is the official way to denote whether a message has
been safely arrived at the receiving end or not. All the HTTP/TCP protocol
return code is for reference only. AFAIK, by design ebMS could be using
other underlying transport protocol other than HTTP. Therefore, the use of
HTTP response code is not official. Following this line of thought, to
determine whether to resend or not, whether to eliminate duplicates should
not based on return code of tranport protocol. Instead, MSH Ack and higher
level receipts should be used. Maybe this is called "higher level of MSH
intelligence"... but why not?

> Clearly if use of "polyphase commits" have taught us anything
> it is that first we deliver then we process: we don't act on anything
until
> we are sure we have all the data safely stored, then await a simple
signal:
> in the TCP networking case it is the FIN-ACK IP packets.

For the sake of argument, I agree that "we don't act on anything until we
are sure we have all the data safely stored". But once I am sure I have all
the data safely stored, I can then respond with a HTTP response code 200 and
send an async MSH Ack over a new HTTP channel. Still, I feel that there is
no relationship between this and the sequence of sending Ack/response.

Regards, -Patrick