MHonArc v2.5.0b2 -->
ebxml-msg message
[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]