Re: CPA and overrides

[Markus Breilmann <markus.breilmann@tamgroup.com>]

Hi all,

it seems the 'need' for overriding the CPA stems from the impression that 
we need ad-hoc messaging capabilities with a previously unknown TP and that 
the CPA would be something rather static.
My hope is that ebXML will ultimately enable a dynamic 
communication/trading network. Looking at documents of the other ebXML 
working groups (especially Reg/Rep) my understanding was that TPs register 
their CPP with a registry service. For ad-hoc communication there would 
then be a negotiation phase in which a CPA can get created on the fly based 
on those CPPs. This means there wouldn't be a need to override it. The 
negotiation would happen in layers other than the MSH but the MSH would 
still provide services to enable this phase. This would create the need for 
some well-defined service interfaces and maybe static/implied CPAs for the 
look-ups and negotiation services.

Wasn't this the idea?

Markus

 > > Hi...
 > > Just wanted to comment on the conversation in yesterday's
 > > conference call
 > > relative to overriding the CPA.
 > >
 > > In the automotive industry, more companies *do not* engage in trading
 > > partner agreements than do. So with that, AIAG would like to see:
 > >
 > > 1. Optional link to the CPA. We would like to have the
 > > *option* to link
 > > to/use a CPA, but we would rather it not be mandatory.
 >
 > CPA is not equal to TPA, of course. But isn't modularity of usage already
 > required within ebXML? That is, the pieces are supposed to be
 > usable independently, right?
 >
 > For example, CPPs and CPAs need not mention TRP packaging,
 > security or transports. And ebXML messaging could occur without
 > any CPA being exchanged (though not without some runtime stuff
 > being setup...)
 >
 > The CPA/CPP is after all an _exchange_ format for interoperabilty
 > profile information and some runtime configuration information.
 >
 > However, some of the information exchanged in a CPP/CPA at configuration
 > time is made available to the run-time MSH processor. The access method to
 > that
 > runtime info has not been specified in any detail. The "CPAId" might, along
 > with other info- From, To, Conversation, Service/Action --
 > be enough to retrieve the records. I don't think anyone has for some time
 > been proposing that the MSH always operate in a "stateless" manner (so that
 > its behavior is totally specified by data found in the PDU).
 > Or has this changed too?
 >
 > > 2. Optional override of the CPA.
 > >
 >
 > I think the better thing to say would be to change the CPA
 > or just stop using it or better avoid using it in the first place.
 >
 > If you can optionally override any aspect
 > on a per message basis, I think you are asking for a level
 > of anarchy incompatible with interoperability... If you can
 > can change anything whenever you want,
 > (send PGP instead of SMIME just to
 > keep the other side on their toes)
 > then don't bother using a CPA!
Markus Breilmann                        markus.breilmann@tamgroup.com
Director of Technology                           tel: +1.415.455.5770
The Tamalpais Group, Inc.                        fax: +1.415.455.5771
11 Belle Avenue                                 web: www.tamgroup.com
CA 94960 San Anselmo, USA