[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-cppa-negot] CPA negotiation removes all but one ChannelId element?
I hope that others will also respond to Sacha's commentsso that we have some serious discussion. I give some initial answers below. Members of the CPPA and MSG TCs: Please see Sacha's comment below about dynamic switching of delivery channels. Regards, Marty At 05:43 PM 10/21/2003 +0800, Sacha Schlegel wrote: >Hi CPA negotiation group > >Sorting out preferences among elements is thought to be handled by the >CPA negotiation process. > >Example: To show the support of several transport protocols, a party >can have a list of several ChannelId elements in a >ThisPartyActionBinding element. > ><CPP> > ... > <ThisPartyActionBinding ...> > <BusinessTransactionCharacteristics .../> > <ActionContext ...> > <ChannelId>x</ChannelId> > <ChannelId>y</ChannelId> > <ChannelId>z</ChannelId> > </ThisPartyActionBinding> > ... ></CPP> > >If the CPA negotiation process sorts out WHICH delivery channel is taken >(x, y, or z) does that mean that a CPA will allways have only ONE >ChannelId element per ThisPartyActionBinding element (variant a)? > >OR does it just reorder the list (variant b)? MWS: Reordering is not enough in a CPA. Unused elements should always be deleted during the negotiation process. >sample variant a: > ><CPA> > ... > <ThisPartyActionBinding ...> > <BusinessTransactionCharacteristics .../> > <ActionContext ...> > <ChannelId>y</ChannelId> > </ThisPartyActionBinding> > ... ></CPA> > >variant a: the CPA negotiation would make sure the two DelvieryChannels >(of CPP one and CPP two) are compatible (might get tricky as the >negotiation actors (human or computer) would need to know the >interdependance of the elements/attributes). The CPA composition tool >might have provided the list of elements/attributes to check in its >NDD. Then once a delivery channel is chosen, the other delivery channels >and its NDD entries can be removed. > >variant b: Compatibility issue as in variant a. I could imagine, that >a "dynamic" MSH could switch Delivery Channel in case that one >Delivery Channel goes down, eg becomes unreliable. The MSH's then >must be able to track both Delivery Channels. MWS: This is an interesting point. I have included the CPPA and MSG teams in the address of this message for their consideration. I don't think that we ever explicitly discussed this point. >What is the consus of this one? > >Kind regards. > >Sacha Schlegel > >PS: Just got Individual OASIS member yesterday, hurray >-- >------------------------------------------------ >Sacha Schlegel >------------------------------------------------ >4 Warwick Str, 6102 St. James, Perth, Australia >sacha@schlegel.li www.schlegel.li >public key: www.schlegel.li/sacha.gpg >------------------------------------------------ ************************************* Martin Sachs standards architect Cyclone Commerce msachs@cyclonecommerce.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]