[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Ack Message Payload??
Yes, that also.
Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074
"Burdett, David" <david.burdett@commerceone.com> on 11/13/2000 02:54:09 PM
To: Scott Hinkelman/Austin/IBM@IBMUS, Martin W Sachs/Watson/IBM@IBMUS
cc: Daniel Ling <dan@vcheq.com>, stefano.pogliani@sun.com, ebxml
transport <ebXML-Transport@lists.ebxml.org>, ebxml-tp@lists.ebxml.org
Subject: RE: Ack Message Payload??
Just a thought, but couldn't "Service" and "Action" in the contain
sufficient semantic meaning that no other information is needed. Therefore
you could have a business mesage with no payload.
David
-----Original Message-----
From: Scott Hinkelman/Austin/IBM [mailto:srh@us.ibm.com]
Sent: Monday, November 13, 2000 11:16 AM
To: Martin W Sachs/Watson/IBM
Cc: Daniel Ling; stefano.pogliani@sun.com; ebxml transport;
ebxml-tp@lists.ebxml.org
Subject: Re: Ack Message Payload??
Marty,
> In terms of the void return you mentioned, are you sure it means "no
payload"? Could it mean no message at all?
Good question. If the application layer supporting the commercial
transaction is expecting a void return it would seem natural
that no payload needs to be returned, or made available to it (depending on
your implementation) from the MSH. [For example,
our current TRP implementation does not return payloads to the application,
but makes them available via an ebXMLMessage
object.] Depending on the QOS of the MSH implementation and the current RM
parameters,
I believe it could work with or without a message within the MSH layer.
This may not be able to be answered/specified if the only thing in scope is
essentially a serialization format and no APIs, etc.
Thanks,
Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074
Martin W Sachs
11/10/2000 04:04 PM
To: Scott Hinkelman/Austin/IBM@IBMUS
cc: Daniel Ling <dan@vcheq.com>, stefano.pogliani@sun.com, ebxml
transport <ebXML-Transport@lists.ebxml.org>, ebxml-tp@lists.ebxml.org
From: Martin W Sachs/Watson/IBM@IBMUS
Subject: Re: Ack Message Payload?? (Document link: Scott Hinkelman)
Scott,
One of the questions the TRP team has been wrestling with is whether there
are cases where the business message consists only of an messaging service
message header (header but no payload). In terms of the void return you
mentioned, are you sure it means "no payload"? Could it mean no message at
all?
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
****************************************************************************
*********
Scott Hinkelman
11/10/2000 03:20 PM
To: Daniel Ling <dan@vcheq.com>
cc: Martin W Sachs/Watson/IBM@IBMUS, stefano.pogliani@sun.com, ebxml
transport <ebXML-Transport@lists.ebxml.org>, ebxml-tp@lists.ebxml.org
From: Scott Hinkelman/Austin/IBM@IBMUS
Subject: Re: Ack Message Payload?? (Document link: Martin W. Sachs)
I believe that if the business collaboration specifies a void return for a
commercial transaction then there is no payload returned,
and if it specifies an 'ack' it is up to that commercial transaction to
define the 'ack' definition in the payload.
Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074
Daniel Ling <dan@vcheq.com> on 11/10/2000 12:47:27 PM
To: Martin W Sachs/Watson/IBM@IBMUS, stefano.pogliani@sun.com
cc: ebxml transport <ebXML-Transport@lists.ebxml.org>,
ebxml-tp@lists.ebxml.org
Subject: Re: Ack Message Payload??
I fully agree with Stefano. Middleware parser errors should definitely be
reported to the
application layer and not the messaging service since it prevents the
sequencing to be done
appropriately .It must be reported to the application layer.
Regards,
Daniel Ling
Technical Architect
VCHEQ
PGP Key ID : 0122020A
PGP Fingerprint : 37B4 E1ED 2840 6EA7 917C 7D84 6608 0EED 0122 020A
WEB: www.vcheq.com
DID: 65-8258225
FAX: 65-5365082
CONFIDENTIALITY CAUTION : This message is intended only for the use of the
individual or entity to whom it is addressed and contains information that
is privileged and confidential. If you, the reader of this message, are not
the intended recipient, you should not disseminate, distribute or copy this
communication. If you have received this communication in error, please
notify us immediately by return email and delete the original message.
Thank
you.
----- Original Message -----
From: "Martin W Sachs/Watson/IBM" <mwsachs@us.ibm.com>
To: <stefano.pogliani@sun.com>
Cc: "ebxml transport" <ebXML-Transport@lists.ebxml.org>;
<ebxml-tp@lists.ebxml.org>
Sent: Thursday, November 09, 2000 11:12 PM
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.
> >
> >
> >
> >
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC