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/>