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

[Doug Bunting <Doug.Bunting@Sun.COM>]

I have never quite understood this issue.  The ebXML specification 
allows for two cases when using the HTTP binding:

1) All response information (at the MSH level and higher) is sent 
asynchronously (no, let us not debate what "asynchronous" means :) and 
the immediate HTTP response has no meaning.  In this case, what does it 
matter whether the meaningless information is sent before or after the 
Messaging acknowledgement?  The only utility of the HTTP response is 
completing the HTTP protocol handshake.  If that must occur earlier in 
situations such as the timeout case described below, fine.  If the 
receiving MSH happens to hold the HTTP connection open while it sends 
the asynchronous acknowledgement (probably not on purpose) but avoids 
time outs, fine.

2) An ebXML Messaging acknowledgement and zero or more bits of 
application data are included in the immediate HTTP response.  In this 
case, the MSH does not send anything asynchronously and automatically. 
Interestingly, the application layer may send some type of signal or 
business level response asynchronously.  This application message might 
arrive earlier than the HTTP response is completed.  Again, we have a 
slight possible race condition.

In both of these cases, the race conditions matter if and only if the 
MSH is making incorrect assumptions about the semantics of the 
information they have on hand.  I do not see the need to describe these 
semantics (for example, an ebXML Messaging acknowledgement and not the 
HTTP response in case 1 is meaningful to the MSH) again.

thanx,
	doug

On 25-Jun-03 10:00, Mike Dillon - Drummond Group wrote:
> 
> -----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
> 
> 
> You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/members/leave_workgroup.php
>