RE: [ebxml-msg] Issue for your review

["Danda, Venkata" <venkat.danda@iona.com>]

Hi Michael,

You are right. In case of the receiving side application fails
to persist the message or some thing goes wrong in the server side
it will raise server side http error code to the MSH. Receiver side 
MSH should communicate this to the Sender. As you mentioned the data
will exchanged between the MSHs but not to the applications properly.

Thanks,
Venkat Danda

-----Original Message-----
From: Michael Wang [mailto:mwang@tibco.com]
Sent: Monday, October 21, 2002 10:05 AM
To: ebxml-msg@lists.oasis-open.org
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.

Regards,
-mw


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


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>