OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Negotiation problem


Michael,

	see below my comments
regards

/stefano

 -----Original Message-----
 From: Michael Joya [mailto:mike.joya@xmlglobal.com]
 Sent: 30 January 2001 03:25
 To: ebxml-poc@lists.ebxml.org
 Subject: Negotiation problem


    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,

	In the current version of the CPA specs, a CPA is composed from TWO
	CPPs. Extensions to multiple CPPs could happen later.

 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

	I do not think that the "business process document" lies
	outside the scope of ebXML.
	In my understanding it is an XML Document conforming to the
	"BP Specification Schema" and, normally, published in the
	ebXML repository.

 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

	I do not recall any public discussion on the "inducted bootstrap
	CPA", but I may have lost it. Could you please point it to me?

	In addition, I would think that the CPP (which "points" to the BP
	document) is "normally" published in the RegRep.

 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.

	What do you mean by "proprietary BP document"?
	In my understanding the BP document will be available in XML
	form conforming to the Specification Schema.


    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 use of "magically" does not reflect well the concept, I think.
	Whilst (as Marty Sachs pointed out yesterday) it is not in the scope of
	the CPA team to define the exact algorithm which defines the
	composition, the CPA team will work in such a way that it will be
	practical to derive the logical composition rules for the CPA
	(not the algorithm)


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

	Honestly, I do not think that the CPA team will have the time
	to work on this issue in the way you address it in the timeframe
	between now an Vienna.

	What I personally think is that what will happen will be, at the
	beginning, a little bit less automated. The Initiator and the
	Respondant will, logically, build the CPA "together" (I say logically
	in the sense that even if one of the two actually compiles it,
	the other one needs to validate it and agree with it); after all
	the CPA is about an "agreement". I do not think that we are there yet
	to define the protocol for an automatic agreement/negotiation.

	Once the CPA is built and agreed (somewhat "manually" or using
	phone/mail/fax/ad-hoc software), the two parties use the CPA
	to create the RUNTIME software (perhaps you have heard references
	to my proposal around a Business Service Interface [BSI]).

	The runtime software of both parties is configured based on the
	SAME CPA.

	As soon as the first party sends the "first choreographed message"
	(defined in the CPA) to the other, the conversation begines and
	takes place within the two runtimes.


    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







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC