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

I may have missed something but if the receiving MSH ignores the
HTTP response from its application, and in this case happens to be
500, there will be no retry from the sender as it has received the
MSH Acknowledgment.  This is an undesirable state.

Even in the case there is another message coming through from the
sender the receiving MSH will not send the message to its application
for the second time if the duplicate elimination flag is set.
This message will never be delivered to the receiving application.

If we start to ignore the transport state then the message will
only remain in the MSHs.  The data may have exchanged ok between
MSHs but it is not going anywhere else.


David Elliot wrote:
> Hi Mike,
> > Should it be at the point of getting a HTTP 2xx response? or
> > when the MSH feels it has sent the message but without getting
> > a 2xx?  I would think it is the former.
> > If we take the later route (which seems to be what people are
> > saying) then the receiving MSH may get a HTTP 500 AFTER it has
> > sent the MSH ack back.  Now the sender side thinks the receiver
> > has got the message but in fact receiver side does not have it!??
> My feeling is that the state of HTTP (transport level) comms doesn't
> matter here.   If the Receiving MSH persists the ebXML message then it has
> received it.   If the Sending MSH receives the subsequent ebXML Ack then
> it will not retry and the transaction is complete.
> Essentially the Receiving MSH got the ebXML message, the Sending MSH got
> the ebXML Ack, no retries will take place.  Whatever is reported by the
> HTTP transport (5xx, 4xx, xxx) does not affect the outcome as the ebXML
> layer data was exchanged ok.
> My primary point being that because ebXML has its own reliability
> mechanism it should not be concerned with the state of the transport
> protocol it's using.
> 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