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
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>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC