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