Re: CPP/CPA specification clarification

[Martin W Sachs <mwsachs@us.ibm.com>]

Eric,

My replies embedded below.

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Eric Chiu <echiu@imservice.com> on 06/05/2001 01:11:29 AM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   ebxml-tp@lists.ebxml.org
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:  To be exact, the CPP-CPA specification defines the precise grammar
for writing a CPP or CPA.  It's up to a party that wants to advertise its
IT characteristics to write a CPP specific to itself.  It's up to two
parties
who want to do business to combine their CPPs into a CPA that defines how
they will operate.  This is no different from any standard.  The standard
defines the protocol or document format but it's up to the users or
application developers to specialize it to their own needs.  If the CC team
decides to define a library of CPP components, that's fine but it's also
really outside the scope of teh CPP/CPA spec.

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

The registry is like a public web site.  The CPP is a single item that
might be in that registry.  Otherwise you are correct.

> 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:  Definitely.  UDDI is another good place to advertise.

> 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: One alternative non-messaging method is to mail a diskette.

MWS: It says MAY
because of ebXML's requirement that its specifications be able to stand
alone as well as work together.  This is especially important for discovery
matters since it is unclear at this time whether both UDDI and ebXML
Registry will end up being significant in the market.

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