RE: Ack Message Payload??

[Martin W Sachs/Watson/IBM <mwsachs@us.ibm.com>]

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