RE: two questions concerning cpp/cpa

[Martin Sachs <msachs@cyclonecommerce.com>]

I think that Dale explained TPA very well but perhaps the following will 
further clarify.

TPA is "trading partner agreement" as used in EDI.  It includes both 
business agreement information and technical (message exchange) 
specifications. It is not automated; the programmers have to read the 
agreement and conform to it in both the business and technical aspects.

CPA, as we all know, is strictly a technical agreement.  A TPA could 
reference a CPA instead of spelling out all the technical terms and 
conditions but I don't know if anyone actually does that.

The original IBM contribution to ebXML was called "tpaML" because we in IBM 
mistakenly referred to our work as an electronic TPA. We dealt with only 
the technical part of the agreement and people inside and outside of IBM 
objected to our using the term.

I'm not sure that TPP is anything real.  It is intended to be one party's 
profile of both technical and business agreement information. This term may 
have been invented by the ebXML architecture team.

CPPA version 1 uses the terms TPA and TPP in the first two paragraphs of 
the introduction.  This was to satisfy certain people who wanted to see a 
connection between CPA and TPA.  However the terms are not used anywhere 
else in version 1 and were removed for version 2.

Regards,
Marty

At 11:26 AM 2/11/2004, Dale Moberg wrote:


>hi
>
>ive got two questions concerning ebxml...maybe someone can help me.
>
>1st: what exactly is the difference between TPP and CPP / TPA and CPA?
>somewhere i read that tpp is more abstract than cpp...is this correct?
>can someone describe this a bit more detailed?
>
>DaleMoberg> The CPP is the Collaboration Protocol Profile and the CPA is
>the Collaboration Protocol Agreement.
>The idea is that for business processes involving collaboration there
>will be some protocol for collaboration, specifying security, transport,
>wire formats, acknowledgments, reliable messaging parameters and so
>forth. The parties can announce what they can do (their services and
>their roles in the constituent activities) and how they can do it-- that
>is the CPP. The CPA then merges (parts of) the collaboration
>participants' CPPs into what they have selected to collaborate on and
>how they intend to do it. Not really that intricate, but there is a lot
>of "stuff" that is agreed upon! On the other hand, a TPA may include or
>reference a CPA. "TPA" is a term used for the "terms and conditions"
>concerning collaboration. It includes things specifying agreed upon
>remedies in cases where the parties fail to perform in accordance with
>agreements. It may specify volume discounts for purchases. And so forth.
>TPAs are not so much abstract as they involve legal agreements. There is
>a UN/CEFACT group, UBAC, that is working on specifying aspects of these
>legal contracts. RosettaNet in the past has actually proposed an XML
>based TPA (I am uncertain how far it got in the RosettaNet approval
>process.) So TPAs are real things, but are rarely (yet) for "automated"
>processing. [An exception might be for the "click-through" agreements
>that software vendors and web sites may force you to "Accept" before
>continuing to install their product or use their service.]  I hope that
>helps you understand the contrast of a technical "contract" for the
>collaboration interface used by collaboraters' software and the legal
>contract used to define commercial practices.
>
>
>2nd: how exactly are CPAs created? i know that you need two or more cpps
>and i have a figure where it is explained. but i guess the figure is
>quite theoetic...how is it managed in the daily doing?
>
>DaleMoberg> The full answer to this is fairly lengthy. There are CPPs,
>CPA templates (draft CPAs) and CPAs.
>CPPs are created by software implementations to describe what and how
>they can do. To create a CPP, information is acquired at installation
>(for things like PartyIDs, PartyNames), at configuration (for things
>like "What OAGIS BODs of what version do you want to use with your
>collaborators? Or what BPSS instance do you wish to deploy for
>collaborators? ) The rest of the technical details can be explicitly
>entered by users in forms or created behind the scenes by the software
>(URLs for endpoints might be generated automatically, for example) CPPs
>can also be created by editing tools that usually use a form and/or
>wizards to gather the information from a person.
>
>For CPA templates, they can be created just as CPPs are created. If you
>wish to present a collaborator with a template, you basically pre-select
>what to do and how things will be done, and expect the collaborator to
>fill out "personal" information. [Personal information includes
>endpoints, certificates, trust anchors, as well as all the PartyId and
>similar values that will be used to fill out messages.]
>
>For CPAs, they can be created from templates (see above) or assembled
>from 2 CPPs (mine and the other guy's). A negotiation protocol is
>currently in draft form that explains how to arrive at a CPA.  A
>negotiation descriptor document (a map of Xpaths and ranges of values)
>together with a CPA draft are offered to a collaborator, and the
>collaborator is allowed to select negotiable items to arrive at a CPA.
>Again the selection can be driven by forms or by automated processes or
>a combination.
>
>
>how much is automated and how much has to be done by a human being?
>
>DaleMoberg> As you might have gathered, the specification officially
>leaves this open. In practice, some items would be unsafe to negotiate
>in a fully automatic way. For example, if someone specifies what
>TrustAnchors you need to accept, a human being will be needed to verify
>that such a security policy is to be accepted. Maybe in some distant
>future world, pre-defined policies will allow even trust anchor choice
>to be automated. But we aren't there yet. So you have freedom in
>designing your product approach. You can leave it up to  form/ editing
>tools (we will call that basically manual) or you can automate as far as
>you can figure out how to automate. Clearly the latter direction is one
>that reduces the burden on the end user and so might have some market
>appeal! hth.
>
>thank you very much and have a nice day
>markus
>
>
>The ebxml-dev list is sponsored by OASIS <http://www.oasis-open.org> The
>list archives are at http://lists.ebxml.org/archives/ebxml-dev/
>To subscribe or unsubscribe from this list use the subscription manager:
>
><http://www.oasis-open.org/mlmanage/>
>
>The ebxml-dev list is sponsored by OASIS <http://www.oasis-open.org> The
>list archives are at http://lists.ebxml.org/archives/ebxml-dev/
>To subscribe or unsubscribe from this list use the subscription manager:
><http://www.oasis-open.org/mlmanage/>

*************************************
Martin Sachs
standards architect
Cyclone Commerce
msachs@cyclonecommerce.com