[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Ack Message Payload??
I was also trying to avoid TRP scope creep by trying to relegate business-specific information to a business process header. I agree that if a business process is so simple-minded that all it needs to signal an event is to state the basic information in the message header so be it. I am suspicious that life is never that simple, however. In any case, what I suggested requires no knowledge on the part of the messaging service. There is a payload container which has only a business process header, and all the specifics of the events are in there. There is a minor TP issue here: If a business message can consist only of the messaging service information, then we have to make the tag that states the business document schema have cardinality 0 or 1. No big deal but that becomes another thing that the parser can't validate. 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 ************************************************************************************* "Burdett, David" <david.burdett@commerceone.com> on 10/31/2000 02:56:09 PM To: Martin W Sachs/Watson/IBM@IBMUS, "Patil, Sanjay" <Spatil@netfish.com> cc: "'David RR Webber'" <Gnosis_@compuserve.com>, Christopher Ferris <chris.ferris@east.sun.com>, ebxml transport <ebXML-Transport@lists.ebxml.org>, ebxml-tp@lists.ebxml.org Subject: RE: Ack Message Payload?? I think "No payload" means there "ebXML Payload Container" i.e. no MIME part that holds the payload. You will know this from looking at the manifest which will be empty. We do not need any fuller definition from the TRP point of view. If I go back to the original definition of the header from the overview and requirements spec it is defined as ... "A Message Header is an XML construct that contains the additional data that needs to be associated with the Documents in a message so that they can be sent to and successfully processed by a Party." I think that is sufficient and we should use this definition to guide what goes in (or stays out of) the header. We are awfully fond of scope creep to my mind. Let's keep TRP simple. David -----Original Message----- From: Martin W Sachs/Watson/IBM [mailto:mwsachs@us.ibm.com] Sent: Tuesday, October 31, 2000 11:36 AM 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