Re: [ebxml-msg] Issue for your review

[Doug Bunting <db134722@iplanet.com>]

My apologies. ;-)

s/transport/transfer/g

thanx,
    doug

Doug Bunting wrote:

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