Observations on comments forwarded from ebBP TC

Monica Martin forwarded comments from Radha Arun that pertained to CPPA

>One thing that is consistently missing with respect to the CPA - is the top

>down trading partner management aspects.

>Most people - given the high degree of technical tagness in the CPA itself

>- tend to have the bottom up view of CPA.

>My experience is focusing on how to use the Registry, CPA and ebMS together

>to faciliate partner control / collaboration of wide communities.  So

>partners can use CPA ID as a linkage mechanism that controls access,

>versioning and interoperability.

Adding to that is the adherence of FERA reference guide mechanism so

>that a B2B gateway can support, ESB, MQUEUE and Web service intermediation.

>How far that fits with this specification?

>This is an architecture and design realization that needs to happen.  So

>the CPA is performing as an orchestration linkage tool - rather than just a

>set of config' parameters for your ebMS.

The Collaboration Protocol Profile and Agreements that have been specified in this TC have not been concerned with configuration that pertained to internal orchestration of private processes, but instead only pertain to public aspects of business processes and collaboration. Of course, the MSH will (since it is often part of a middleware component) need to be configured to integrate with the “inside” of a business. The general presumption has been that private processes are not really the subject of agreements between collaborators except for certain levels or qualities of service such as a promised turnaround time for a business response. Configuration of integration is not planned as a topic for the CPPA TC in the near future.

>2.Relation with other specification –

> >    i.e how the CPA and CVV should interact with CQI – Customer

> Information Quality TC recommended work?

Monica informed us that these TCs had been concerned with name and address standardization. Agreements about the syntax or semantics of business documents, or even localization or other contextual factors, has not been taken up in the CPPA. There has been various UNCEFACT initiatives that have been more concerned with agreements about such factors as well as the legal and trade agreement factors associated with collaborative processes. Trade, legal, and other semantic alignment agreements (including agreements about penalties or rewards related to performance levels) are not planned as topics for the CPPA TC in the near future.

>3. CPA actually specifies the interface with access points defined by the

> business process specification. Elaboration / clarification on  this

> sentence? Does it mean BSI is CPA?

CPPA, as you note, is mainly concerned with technical aspects of configuration needed to implement communications, security, reliability and certain aspects of quality of service related to those topics. The sentence notes that parts of the business process (the actions within a business transaction activity (BPSS terminology) are independently configurable in CPAs. If we think of a BSH as a software component exhibiting the BSI interface, the CPA might have some parameters that would be of interest to such a BSH. But it is the ebMS MSH that is the main component being configured by information in a CPA. But the ebBP 2.0 specification discusses one sense of BSI, and the CPPA does not define that interface. (Signals and timers are potentially configured by parameters in the CPA, but they are mainly described by the actual business process descriptions conforming to the ebBP schema. The ebBP specification discusses one sense of BSI in an appendix.

ebxml-cppa message