Re: [ebxml-msg] Issue for your review

[Christopher B Ferris <chrisfer@us.ibm.com>]

I think that it is safest to state that
the sender can have no expectation that
it will receive the HTTP 2xx response
before the receipt of any acknowledgement.

By its very definition[1], asynchronous
means:

Lack of temporal concurrence; absence of synchronism.

The sending of an asynchronous message
need not complete, from the sender's
perspective, before the recipient sends
the acknowledgment.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

[1] http://www.dictionary.com/search?q=asynchronous

Doug Bunting <db134722@iplanet.com> wrote on
10/18/2002 05:06:17 PM:

> Dave,
> 
> An excellent description of how very little we say in the Messaging
> specification can completely control the observed ordering of responses
seen at
> the originating server.  Your example describes a real world
issue resulting
> from a clear separation of concerns between the ebXML and transport
layers.
> 
> The other case I was attempting to describe earlier involved separating
concerns
> between the application and ebXML layers.  I had misread or forgotten
the
> original issue description and thought we were discussing a SyncReply
/
> syncReplyMode="mshSignalsOnly" / AckRequested case.  What
I was describing in an
> earlier email is an indeterminate ordering of business and MSH signals
or
> responses in this case.  The MSH MUST make the incoming message
available to the
> application prior to returning (via the HTTP 200 reply if using that
transfer
> protocol) an Acknowledgment message.  The MSH has no control
over how quickly
> the application operates so business signals or responses may arrive
at the
> originating server before the Acknowledgement message.  We could
try to force
> that MSH to prevent outgoing messages including a RefToMessageID pointing
to the
> one it's working on but we can't guarantee the same MSH will even
be used for
> the outgoing message or close all of the race conditions.  And,
so...
> 
> In both cases, we need to describe the issue so originating servers
do not
> depend upon particular orderings rather than increasing the complexity
of the
> receiving server to (slightly) lessen the chances for ordering to
follow
> less-than-obvious patterns.
> 
> thanx,
>     doug
> 
> Dave Elliot wrote:
> ...
> 
> > Here's another real world problem.  Suppose the Responder
behaves as you
> > suggest and does not send an async EbXML Ack until the transport
layer
> > of the inbound message has wrapped up.  So in effect you
have this
> > sequence:  The Responder sends HTTP 202 and then immediately
sends the
> > EbXML Ack over a different DeliveryChannel (possibily different
> > transport protocol).
> >
> > Now let us suppose that the EbXML Ack delivery protocol is faster
to
> > send and to unmarshall/process than HTTP.  This means that
the ebXML Ack
> > would arrive up at the Sender's EbXML Layer before the Sender's
HTTP
> > transport was able to confirm to its EbXML Layer that the original
> > message was even sent.
> >
> > Which illustrates that even if you were to mandate the transport/ebXML
> > layer sequence that the Responder must follow, the sequence may
still
> > occasionally/randomly appear different to the Requester.  That's
why I
> > don't think it is safe to mandate that kind of thing.
> >
> > Best Regards,
> >
> > Dave Elliot
> > XML Global Technologies
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>