[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] Re: [ebxml-msg] Comments on your Comments
Arvola, The Override element is a child element of the ServiceBinding element. The v 1.0 CPP-CPA text for the ServiceBinding element states that it identifies a default delivery channel for all of the message traffice that is to be sent to the party within the context of the identified process-specification document. For the override element, it states that it provides a party with the ability to map or bind a different delivery channel to messages of a selected business transaction that is associated with the parent service binding element. Given these words, we can't simply add an override element for MSH to MSH messages. I suppose we could concoct a BPSS description of MSH to MSH messaging and add a ProcessSpecification subtree for this purpose. I also thought about designating that delivery channel under ebXMLBinding but since ebXMLBinding is part of a delivery channel, that's at least circular if not worst. See next paragraph for a better idea. The simplest approach is to add an additional child element to PartyInfo that designates a delivery channel for MSH to MSH messages. Alternatively, we could add an attribute to the DeliveryChannel element that permits a particular delivery channel to be used for MSH to MSH messages. I think I prefer adding a child element to PartyInfo because that would allow us to prescribe that only one such delivery channel be so designated (if that's what we want to do). Either way, we need to pay some attention to the wording because that element or attribute has to be described as usable for any messaging agent, not just the ebXML MSH, since that element or attribute is in an area that is independent of messaging protocol. 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 ************************************************************************************* Arvola Chan <arvola@tibco.com> on 11/07/2001 11:08:05 AM To: Martin W Sachs/Watson/IBM@IBMUS cc: David Fischer <david@drummondgroup.com>, ebXML Msg <ebxml-msg@lists.oasis-open.org>, ebxml-cppa@lists.oasis-open.org Subject: Re: [ebxml-cppa] Re: [ebxml-msg] Comments on your Comments Marty: Lines 1426 and 1427 in the 1.07 version of the spec (with change bars turned on) state: · The Service element MUST be set to: uri:www.oasis-open.org/messageService/ · The Action element MUST be set to MessageError. These values are to be used when an Error message is sent on its own. Therefore, it is possible to have an Override element in the CPA to designate the delivery channel to be used for such messages. Regards, -Arvola -----Original Message----- From: Martin W Sachs <mwsachs@us.ibm.com> To: Arvola Chan <arvola@tibco.com> Cc: David Fischer <david@drummondgroup.com>; ebXML Msg <ebxml-msg@lists.oasis-open.org>; ebxml-cppa@lists.oasis-open.org <ebxml-cppa@lists.oasis-open.org> Date: Tuesday, November 06, 2001 8:26 PM Subject: [ebxml-cppa] Re: [ebxml-msg] Comments on your Comments > >Arvola, > >At the moment, the CPPA specification does not provide a means of >designating delivery channels specifically for error messages. Delivery >channels can only be designated per action or for the entire set of >actions. You are proposing a new issue for the CPPA-MSG interlock list. > >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 > *************************************************************************** ********** > > > >Arvola Chan <arvola@tibco.com> on 11/06/2001 08:19:41 PM > >To: David Fischer <david@drummondgroup.com> >cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>, > ebxml-cppa@lists.oasis-open.org >Subject: Re: [ebxml-msg] Comments on your Comments > > > >David: > >I have no problem with stipulating that Errors are never sent >reliably. We just have to make it clear in the 1.1 spec. > >The CPP/A spec should indicate that any delivery channel >designated for carrying Error messages (i.e., for the action >MessageError) must not specify the use of Reliable Messaging. > >Regards, >-Arvola > >-----Original Message----- >From: David Fischer <david@drummondgroup.com> >To: Arvola Chan <arvola@tibco.com> >Cc: ebXML Msg <ebxml-msg@lists.oasis-open.org> >Date: Tuesday, November 06, 2001 7:19 AM >Subject: [ebxml-msg] Comments on your Comments > > >Arvola, > >One of your comments was on the restriction about not having Acks on >Errors. >We >can have Acks on Errors if we stipulate no Errors on Acks. If we want >Errors on >Acks then we must stipulate no Acks on Errors. If we have both, then we >have >the potential for endless loops. > >I question the need for Errors to be sent reliably. I see some significant >benefit for having Errors returned on bad Acks. > >Regards, > >David Fischer >Drummond Group. > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: <http://lists.oasis-open.org/ob/adm.pl> > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC