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/>
<<attachment: winmail.dat>>