Re: [ebxml-msg] Issue for your review

[Michael Wang <mwang@tibco.com>]

Hi Dave,

I think you have misunderstood me.  As suggested by you that MSH
should not care of transport level state then this is a possible scenario.

The receiving MSH forwards the message to its application using HTTP.
The receiving MSH not caring of the transport state then sends
the MSH Ack back to the sender.  The sending MSH received its expected
MSH ack.

All seems good until you realised your application actually returned
HTTP 500.  Now we have a case of sending MSH thinks the message was
delivered as it received a MSH ack.  Receiving MSH thinks it delivered
the message to application as it did not care of the transport state.

This is a case of receiving MSH did not experience a failure due
to its ignorance of transport state but took up the contractual
responsibility of delivering a MSH ack back.

If the spec had qualified "delivered"/"made available" as dictated
by the delivered semantics of the transport in use then there would be
no amgiguity.  If this were the case, the above example would mean
the receiving MSH MUST wait for HTTP 2xx before sending MSH ack
back to the sending MSH.

Regards,
-mw

Dave Elliot wrote:
> 
> On Mon, 2002-10-21 at 10:19, Danda, Venkata wrote:
> > 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.
> 
> Here's the thing...  The Receiver side does not need to propogate
> internal errors to the Sender MSH using transport protocols.  If the
> Receiver MSH experiences a failure that prevents it from taking
> responsibility for the inbound message then it indicates this implicitly
> by _not_ returning an ebXML Ack or explicitly by sending an ebXML
> Error.  In either case transport protocol response codes are not
> involved...
> 
> If the Receiver MSH even _attempts_ to return an ebXML Ack then it has
> already taken contractual responsibility for delivering the message to a
> bound ToParty or to a NextMSH.  This is regardless of whether or not the
> ebXML Ack transmits ok.
> 
> One last point that you and Mike have raised is that failure to leverage
> transport protocol response codes can mean that an MSH will hold on to
> ebXML data without delivering it.  I have thought about this and cannot
> bring to mind a legal situation where an MSH could be in a position of
> blocking an ebXML message without delivering it to a bound ToParty or
> forwarding to a NextMSH....?
> 
> Cheers,
> 
> Dave Elliot
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>