Re: CPP/CPA specification clarification

[christopher ferris <chris.ferris@east.sun.com>]

Eric,

Please see below.

Cheers,

Chris

Eric Chiu wrote:
> 
> 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?

Not quite. The CC team is defining a set of rules by which
a document's schema is assembled, from a set of core components,
based on the context within which that document will be exchanged. The
business process provides part of that context. These schema are
ultimately referenced by the CPP and CPA document instances
that a business creates (it doesn't "implement" a CPP/CPA per se)
for itself.

> 
> > 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).....

Not quite. The CPP analogy is close, but a CPP doesn't describe the
goods and services a company offers. That would be more the
responsibility
of a UDDI registration. Rather, a CPP is a technical description of
the possible means by which a prospective partner MAY engage in 
e-business. 

Two businesses collaborate to form a CPA, typically by constructing
an intersection of their respective CPPs and negotiating any 
differences where no intersection exists.

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

I would think that the answer to that question would be yes. Why not?

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

A CPA is an agreement between two parties. It is NOT necessary, nor
even very efficient to store that CPA in a registry/repository since
it is generally considered a private matter between the two parties,
not something used for discovery, etc. Typically, only CPPs will
be stored in the registry/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.
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard