MHonArc v2.5.2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [ebxml-msg] Issue for your review
I think that it is safest to state that
the sender can have no expectation thatit 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'sperspective, 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=asynchronousDoug 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>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC