Re: [ebxml-msg] Issue for your review

[Doug Bunting <db134722@iplanet.com>]

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>