Subject: Re: CPP/CPA specification clarification
Marty, Thanks for your help. I'd like to get further details if possible... questions and comments below. If you can confirm or correct my assumptions, I would appreciate it. > MWS: The CPP/CPA specifciation does not provide a business document set. > The Core Components team is attempting to define rules for creating > document components that can be composed into documents. ETC: So the CPP/CPA specification defines the constraints for writing CPPs and CPAs, but does not actually define specific CPPs and CPAs. It leaves the task of defining generic CPPs for the CC spec, and specific implementations of CPPs and CPAs to actual developers of the system. So CPP/CPA spec is like a high-level overview of what should be in a specific CPP/CPA? > MWS: The CPP is a document that defines the owning party's IT > characteristics and points to the collaborative business processes that > it supports. The CPA is a document that defines the agreed IT > characteristics under which a pair of parties will exchange messages and > points to the agreed collaborative process. Document types (e.g. schemas) > are identified in the collaborative process definition (Process > Specification > document.) ETC: So to use an analogy, CPP is like a public website that I can query to check on the corporate profile of my trading partner, with basic information on what goods and service the company offers/wants. I'll have to authenticate, and then I'll be shown an CPA, which is a secured extranet, with actual forms for me to purchase goods/services. Then I can exchange messages on trades (presumably using ebXML messaging)..... > MWS: It does not piggyback on X12. I'm not even sure what that means. > The messages exchanged between the two parties can be EDI messages as > well as XML messages. There is no specific dependence on the ebXML > registry or any registry. However the partner discovery process is > very important to e-business. Normally you should expect to pull > a partner's CPP from a repository. The CPA is effectively private > to two parties and will probably not be kept in a repository. ETC: Yes, I presume a "Yellow Pages" of goods and services will evolve to assist in the partner discovery (there were references to this in the requirements and tech arch specs). Though there is no logical dependency of the CPP/CPA spec on Registry/Repository specs, there are frequent references between specs. I suspect real world applications will adapt both or none. Do it make sense to create ebXML-compliant CPP, then put it into a non-ebXML compliant repository? > MWS: Yes, if a CPP or CPA is transferred in a message, it is the > payload. However the CPP and CPA are NOT exchanged in the messages > which two parties exchange in performing a business process. They > may be sent in messages when obtained from a repository or when > negotiating the details of a CPA. ETC: what are alternative non -messaging methods of transferring CPP/CPA content? Why "may" instead of "should" in this case of querying CPA from a repository? > MWS: Section 6 of the specification provides a good description of > CPP-CPA usage. For an overall view of the ebXML goals and architecture, > get > the requirements and technical-architecture specifications from the > ebXML website. ETC: You're right, section 7 of CPP/CPA spec provide a good overview of usage at a high level, step-by-step. I think I need to have a prototype to visualize this better. It's not technical, but there are a number of possible permutations in the process, if you explore all the branches.
Powered by eList eXpress LLC