Re: Negotiation problem

[Matthew MacKenzie <matt@xmlglobal.com>]

Marty,

Imposing the human element into the equation sure would make life a heck of
a lot easier for us software architects :-)

Seriously, there should at least be an action plan for addressing the
automated negotiation process.  Preliminary explorations by my team into
this particular area brought us to the conclusion that we would still need
human intervention for even the simplest contract unless there was
considerable work done to define a standard protocol for CPA negotiation, so
that vendor implementations always come up with the same contract given the
same input.  The CPP structure would actually be redefined during the
process of building this negotiation protocol for the simple reason that a
CPP has to be rich enough to allow the negotiation tool to make the same
decisions a human would make - which is hard because a human can sense small
yet signifigant detail such as "Who holds the upper hand in this
negotiation?" or "How much can I go over my budget for this transaction? 
How important is it that I obtain these <thing(s)>?".

Cheers,

Matthew MacKenzie
XMLGlobal
<<| message from: Martin W Sachs <mwsachs@us.ibm.com> |>>

> When we (IBM Research) built the tpaML definition and BPF prototype
> runtime, we had a (perhaps naiive) view that representatives of the two
> parties would sit down together in the same room, compose the CPA, and
then
> take copies of it home with them on diskettes and install them in their
> systems. As Chris says, "it's a place to start", especially since the
> future beyond May is still a black hole.
> 
> 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
>
*************************************************************************************
> 
> 
> 
> christopher ferris <chris.ferris@east.sun.com> on 01/30/2001 07:46:38 AM
> 
> To:   Michael Joya <mike.joya@xmlglobal.com>
> cc:   ebxml-poc@lists.ebxml.org, "ebxml-tp@lists.ebxml.org"
>       <ebxml-tp@lists.ebxml.org>, "ebxml-transport@lists.ebxml.org"
>       <ebxml-transport@lists.ebxml.org>
> Subject:  Re: Negotiation problem
> 
> 
> 
> Michael,
> 
> Please see below.
> 
> Cheers,
> 
> Chris
> 
> Michael Joya wrote:
> >
> >    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)
> > .....
> > --
> 
> We have discussed this in the TR&P group, most recently at Tokyo.
> We came up with the idea that the initiator could send the CPA
> in a message that referenced the CPA in the message as the CpaId
> sent with the first message in the collaboration.
> 
> The receiving party's system would have to recognize the CPA
> as having a status of "proposed" and could either accept or
> reject the proposal. Acceptance would involve installing the
> received CPA and then processing the message.
> 
> While we never concluded the discussion, nor have we settled
> on the negotiation aspects, it is certainly possible.
> 
> Of course, you can simply send the proposed CPA to the
> business partner via email, you could have a web service
> set up to receive and install CPAs that did NOT use ebXML
> Message Service (e.g. just a Servlet).
> 
> >
> >    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?
> 
> If the two parties share a trust network, then this is not an issue.
> Choice of a PKI is out of scope for ebXML at least at this stage of
> the game.
> 
> >  - 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?
> 
> It is a place to start!
> 
> >
> >    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
> 
> 
> 
> 
> 
> 
> 
<<| end message from Martin W Sachs <mwsachs@us.ibm.com> |>>

--
Matthew MacKenzie
VP Research & Development, Founder
XML Global Technologies, Inc.