[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Ack Message Payload??
By George, I think he's got it!
;-)
"Burdett, David" wrote:
>
> 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.
> > >
> > >
> > >
> > >
> >
> >
> >
> >
--
Christopher Ferris
_/_/_/_/ _/ _/ _/ _/ Sr Staff Engineer - XTC Advanced Development
_/ _/ _/ _/_/ _/ Phone: 781-442-3063 or x23063
_/_/_/_/ _/ _/ _/ _/ _/ Email: chris.ferris@East.Sun.COM
_/ _/ _/ _/ _/_/ Sun Microsystems, Mailstop: UBUR03-313
_/_/_/_/ _/_/_/ _/ _/ 1 Network Drive Burlington, MA 01803-0903
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC