RE: Ack Message Payload??

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

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