RE: [ebxml-cppa-negot] CPA negotiation removes all butoneChannelId element?

[Sacha Schlegel <sacha_oasis@schlegel.li>]

Hi All

Thanks for your comments.

So the current version of the MSH specification deals with only ONE
channelId element per ThisPartyActionBinding in a final CPA. In the
future there might be multiple channelIds to allow a fallback mechanisms
for the MSH's, but not for the moment.

Further the CPA negotiation process is responsible to select the one
choice between multiple channelId elements.

A followup questions follows.

Kind regards

Sacha

On Wed, 2003-10-22 at 05:57, Dale Moberg wrote: 
> 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.
> 
> Dale: +1.
> 
> 
> In addition, the only semantics that has been discussed for multiple
> Channels remaining in a CPA was to provide for a fallback channel.
> However, very little has been said about exactly how that fallback
> channel would work. In particular, how it would interact with reliable
> messaging retry count or interval is unspecified. Nor is it specified
> whether the same message Id would be used on a fallback channel. I think
> that implementers would be on their own in making this work in a
> predictable way. For that reason, I doubt that version 2 CPAs would in
> practice make much use of the fallback channel idea.
> Perhaps it can be raised as a new version 3 issue when/if we cross that
> threshold.  
> 
> 
> >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.
> >
> 
> Dale> I think this is the safest behavior given the underspecified
> character
> of allowing multiple channels for a given action for the purpose of
> fallback support within a version 2.0 CPA. 
> 
> >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.
> 
> Dale> Well, we discussed it in passing, but I am afraid we never nailed
> down all the loose ends for fallback channel (or fallback endpoint)
> semantics for the CPA. We left it in and in effect left it to
> implementers to make it work. I doubt that the result would be very
> interoperable. The MSH tracking you mention here points at some of the
> hard parts. Eg, the same message id would need to be used for purposes
> of duplicate checking for RM while the messages might have to be quite
> differently packaged in accordance with Channel properties, and so
> really be a quite different message. I am afraid that specifying in the
> necessary detail all those behaviors really fell on the other side of
> the 80/20 split for version 2.... But as I mentioned we might consider
> what to do with this for a version 3.x
> CPPA if we ever get there...
> 
> Dale Moberg
> 
> 
> 
> 
> 
> >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 
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/ebxml-cppa-negot/members/le
> ave_workgroup.php.
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ebxml-cppa-negot/members/leave_workgroup.php.
> 
> 
> 
> 
> !DSPAM:3f95ac4a303492019287571!
-- 
------------------------------------------------
Sacha                                   Schlegel
------------------------------------------------
4 Warwick Str, 6102 St. James, Perth,  Australia
sacha@schlegel.li                www.schlegel.li
public key:            www.schlegel.li/sacha.gpg
------------------------------------------------

This is a digitally signed message part