OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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

Hi Doug,

Comments below:

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

True, the same issue can arise across the EbXML layer/Application layer
boundary (referred to as the Message Service Interface (MSI) in the
spec) as you describe...  

It would be unsafe for a client of the MSI to assume that a message has
not been successfully delivered to a remote party because an ebXML layer
Ack hasn't been indicated yet.   If the MSI client was relying on the
ebXML layer Ack to arrive before considering its message sent, how would
it behave when in the (non-intuitive although possible) instance you
describe where it receives a response to a request that it doesn't
consider sent yet ???

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

Agreed...what do you think of these statements?

1. The ebXML layer in an MSH should only rely on ebXML layer mechanisms
to enforce reliability / message ordering.  The ebXML layer should not
make assumptions regarding ebXML message delivery success or failure
based upon transport layer response codes. 

2. An MSI client may leverage MSH ebXML reliability to make assumptions
regarding business message delivery failure.  However an MSI client
should not rely on MSH ebXML layer state to assume the timing of
successful business message delivery.


Best Regards,

Dave Elliot
XML Global Technologies


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC