Negotiation problem

[Michael Joya <mike.joya@xmlglobal.com>]

   I'm having a little bit of trouble visualizing Collaboration Protocol
Agreement negotiation. The following is a depiction of a CPA negotiation
and an impass I have reached while implementing. Please feel free to
correct me on any of this or provide your own personal view. It's a
fuzzy construction of a scenario, but I think the main points are valid.

   I understand that a CPA is made up from N number of CPP documents,
usually two. The schema for the CPA is static, although it can be
templated from another document that lies outside of the ebxml scope,
commonly known as a business process document. So the runtime
transformation we have is:

cpaDoc := constructCpaUsingMyBPSchema(bpDoc, cpp1Doc, cpp2Doc)

   Ignoring details such as core component alignment, (which itself
carries a heavy implementation load!) our newly formed CPA document
becomes the basis of communications between two parties with a shared
interest in participating in a known, public business process.

   Let's analyze what's required to happen in real life before two
parties engage in that business process. I'll call the two parties
Initiator and Respondant from here on.

--
   Respondant takes a BP document and her business's CPP and puts them
in a public place. This can be a web site, distribution CD, FTP site, or
even via a public ebXML registry - using the recently inducted bootstrap
CPA. The proprietary BP document allows some kind of parameterization to
take place over the creation of the CPA document. The BP could even be a
textual or UML representation of what message must be sent to who, and
in what order, and so on.

   Initiator finds said BP and CPP documents and decides to do business
(discovers the Respondant?). Before an ebXML message is sent off, the
initiator needs to have formed a CPA, and its corresponding CPAId.
Knowning his own CPP, having the Respondant's on hand, and having a
BP document to use as an aide, the Initiator magically puts the pieces
of the puzzle together and forms the CPA.

   The Initiator now has what is required to send off his first message.
But wait! The CPA agreement magically created by the Initiator must also
be exist in the Respondant's possession! Three possibilities exist -

Either the Initiator submits this CPA to the Respondant's registry via
the bootstrap protocol
  OR
The Respondant must calculate the exact same CPA as her potential
client.
  OR
The Initiator sends the requested CPA to a human Respondant agent for
manual trust validation. (By phone, etc)
.....
--

   The problem is that neither of these modes of operation is terribly
viable. I didn't believe it myself until I tried enumerating them in an
implementation. Let's delve further:
  - Option one forebodes authentication. There's no way for the
Respondant to assure herself that the initiator is really Boeing,
Coca-Cola, or XML Global; not having established a CPA in the first
place, she has no frame of reference by which to trust the Initiator. It
looks to me as though this option REQUIRES that third party trust
intervene. If so, why is there no specified model for this?
 - Option two would be desirable, but unfortunately ebXML specifications
can't dictate any form of implementation. I think this restriction
borders on silly; but since we're all abiding by the rules, this option
can't be enforced in a specification. Not to mention that the
transformation may be parameterized by use of a proprietary BP document.

  - Option three defeats the purpose of an automatic messaging
& discovery system altogether. However, if we all agree that a human
operator should play a part in the negotiation of an ebXML CPA, I'm sure
that as vendors and implementors, we could make this option come to
life. But should we?

   Have I err'd here? Since most of our POC demonstrations take place in
a vacuum and under "cradled" circumstances, we don't run into
negotiation problems very frequently. Has anyone else had similar
trouble implementing negotiation?

   Any and all feedback welcome.



--
// Michael Joya
// XML Global Research and Development
// 1818 Cornwall Ave. Suite 9
// Vancouver, Canada
// 604-717-1100x230