RE: Ack Message Payload??

[Stefano POGLIANI <stefano.pogliani@sun.com>]

Yes, Marty. The example of the parser error describes a "technical" error that prevents the choreography to continue and, thus, needs to be reported to the application layer.

/Stefano

> -----Original Message-----
> From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
> Sent: Thursday, November 09, 2000 4:12 PM
> To: stefano.pogliani@sun.com
> Cc: ebxml transport; ebxml-tp@lists.ebxml.org
> Subject: RE: Ack Message Payload??
> 
> 
> 
> I fully agree with Stefano.  In general, errors detected by the messaging
> service should be resolved by the messaging service.  Errors detected by
> the application result in "normal" messages reporting the error and these
> go to the application at the other end.
> 
> There is, of course the "grey" zone, errors detected by the 
> middleware that
> need to be reported to the application at the other end.  An example might
> be an error detected by a parser that is part of the middleware on the
> receiving side.  Such an error is in fact not in the messaging service
> domain;  it is in the application domain.
> 
> Regards,
> Marty
> 
> ******************************************************************
> *******************
> 
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
> ******************************************************************
> *******************
> 
> 
> 
> Stefano POGLIANI <stefano.pogliani@sun.com> on 11/09/2000 09:35:14 AM
> 
> Please respond to stefano.pogliani@sun.com
> 
> To:   ebxml transport <ebXML-Transport@lists.ebxml.org>
> cc:   ebxml-tp@lists.ebxml.org
> Subject:  RE: Ack Message Payload??
> 
> 
> 
> In my opinion, it is tricky to define a Business Level ACK.
> I may be wrong, but I do not see how it would exist actually. At
> BusinessProcess Level we model a choreography of exchanges between two
> parties. Some of the exchanges may be "thought of" as ACKs but, 
> if they are
> modelled in the choreography, they are actually "normal" messages (i.e.
> messages expected by the application managing the choreography). In this
> case, the fact there a payload is present or not is up to the choreography
> and shouldn't be questioned (unless it breaks some consistency rules on
> respect to the format of a message).
> 
> So, an ACK is, as far as I see it, a technical construct that can be used
> to model the technical exchange of messages. An example is an async
> interaction where the ACK may be used to "technically" ensure that the
> request get through. In this context I would not expect the ACK to reach
> the Application Layer.
> 
>      There is probably one exception to the last sentence (at least). This
>      exception could be when one of the two parties has TR&P and the other
>      has not. But I am not sure this is a valid config.
> 
> A little bit different is the case of an Error message (sorry if I am
> saying something out of context but I am not yet up to date with 
> the latest
> TR&P specs). I see different scenarios:
>      1.   the "Error" may be explicitely generated by the receving
> application
>           in which case it is an error that has been anticipated by the
>           choreography): pass the error to the "sending" application
> because it
>           is probably "able to manage it".
>      2.   the "Error" may come from the TR&P. In this case,
>           a.   if the Error is something that prevents the choreography to
>                continue, then the Application layer should be warned in
> order
>                to take some "default" action.
>           b.   if the Error is something that does not prevent the
> choreography
>                to continue (i.e. it is resolvable by the TR&P), then the
> TR&P
>                should take care of the corrective action.
> 
> /Stefano
> 
> 
> 
> > -----Original Message-----
> > From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com]
> > Sent: Tuesday, October 31, 2000 8:36 PM
> > To: Patil, Sanjay
> > Cc: 'David RR Webber'; Christopher Ferris; ebxml transport;
> > ebxml-tp@lists.ebxml.org
> > Subject: RE: Ack Message Payload??
> >
> >
> >
> > What does "no payload" mean?
> >
> > I would like to postulate that a business process will require 
> a business
> > process header, which contains control information specific to that
> > business process.  The business-process header is the header of
> > the payload
> > of the Message-service message and is separate from the 
> messaging-service
> > header.
> >
> > If this postulate is accepted, then I suggest that an event could be
> > represented by a business-process header with no business-process
> payload.
> > From the viewpoint of the messaging service, there would formally be a
> > payload.  I suggest further that any header information needed 
> to support
> > an event belongs in the business-process header, not the messaging
> service
> > header.  This is consistent with good layering design and keeps the
> > messaging service out of the business of having special functions for
> > particular kinds of business process messages.
> >
> > Regards,
> > Marty
> >
> > ******************************************************************
> > *******************
> >
> > Martin W. Sachs
> > IBM T. J. Watson Research Center
> > P. O. B. 704
> > Yorktown Hts, NY 10598
> > 914-784-7287;  IBM tie line 863-7287
> > Notes address:  Martin W Sachs/Watson/IBM
> > Internet address:  mwsachs @ us.ibm.com
> > ******************************************************************
> > *******************
> >
> >
> >
> > "Patil, Sanjay" <Spatil@netfish.com> on 10/31/2000 02:22:14 PM
> >
> > To:   "'David RR Webber'" <Gnosis_@compuserve.com>, Christopher Ferris
> >       <chris.ferris@east.sun.com>, ebxml transport
> >       <ebXML-Transport@lists.ebxml.org>
> > cc:
> > Subject:  RE: Ack Message Payload??
> >
> >
> >
> >
> > If ebXMLHeader is not enough to identify the message
> > completely and requires some dummy payload, we need
> > to work more on the ebXMLHeader.
> >
> > Relying on dummy payloads for unambiguity would lead to
> > ambiguous specs of the TRP, not a good idea.
> >
> > I am for not having payload when none is required.
> > Business Processes should handle events (no payload)
> > as well as normal business documents.
> >
> > thanks,
> > Sanjay Patil
> > ------------------------------------------------------------------
> > ----------
> >
> > ------------------------------
> > Work Phone: 408 350 9619
> > http://www.netfish.com
> >
> >
> > -----Original Message-----
> > From: David RR Webber [mailto:Gnosis_@compuserve.com]
> > Sent: Tuesday, October 31, 2000 6:46 AM
> > To: Christopher Ferris; ebxml transport
> > Subject: Re: Ack Message Payload??
> >
> >
> > Message text written by Christopher Ferris
> > >
> > Regardless, I think that a BP-level ACK *should* have
> > a payload, even if it is a minimal one like:
> >         <status>OK</status>
> >
> > It SHALL have a MessageType="Normal" and it SHALL have
> > a ServiceInterface and Action appropriate to its purpose
> > at least for the current state of affairs.
> > <<<<<<<<<<<<<<<
> >
> > Chris,
> >
> > Agreed.   Getting back an empty transaction is too ambiguous.
> >
> > DW.
> >
> >
> >
> >
> 
> 
> 
> 
>