OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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 oneChannelId element?

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.
>   ...
>   <ThisPartyActionBinding ...>
>     <BusinessTransactionCharacteristics .../>
>     <ActionContext ...>
>     <ChannelId>x</ChannelId>
>     <ChannelId>y</ChannelId>
>     <ChannelId>z</ChannelId>
>   </ThisPartyActionBinding>
>   ...
>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
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

>sample variant a:
>   ...
>   <ThisPartyActionBinding ...>
>     <BusinessTransactionCharacteristics .../>
>     <ActionContext ...>
>     <ChannelId>y</ChannelId>
>   </ThisPartyActionBinding>
>   ...
>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
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
in the address of this message for their consideration. I don't think
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

To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]