Re: [ebxml-cppa-negot] CPA negotiation,contact with negotiation research community plus some thoughts.

["Monica J. Martin" <Monica.Martin@Sun.COM>]

>>mm1: On the negotiability of the business transactional aspects (or for other 
>>business transaction characteristics in other specifications for that 
>>matter), could be many and complex. I would suggest two possible options 
>>to consider: Look at the automated process matching proposed by 
>>OpenXchange, 
>>    
>>
>Sacha: I did read the "Matching of ebXML Business Processes" from Dennis
>Krukkert, Version 0.31, Status: In Progress.
>
>.....BPSS are based on UML activity diagrams, this means that a business
>process matching algorithm has to know about UML activity diagrams.
>
>One problem Dennis had is that there is no formal language specified for
>pre/post conditions of activites, so they are basically not usable.
>
mm2: The pre- and post-conditions are xsd: string and therefore, 
effectively are used for documentation.  We are discussing how they will 
be used and why for v3.0 (likely).

>a) Business Process (ebXML special UML Activity Diagrams) matching
>------------------------------------------------------------------
>......This looked interesting as one business process (a) says:
>
>bp a:: "Activity A" followed by "Activity B".
>
>The other business process (b) has:
>
>bp b:: "FORK (and)" : "Activity A", "Activity B", "JOIN"
>
>For the user of business process it is important, that activity B
>follows activity A. For the user of business process b it does not
>matter, inidcating this with a join/fork. For the user of business
>process b, activity A can follow activity B or activity B can follow
>activity A.
>
>So it is obvious, that these  two business processes "match" but look
>different. 
>
mm2: They may also take different paths but in a deterministic way come 
to the same list of possible conclusions.

>Dennis looked at bisimulation (of the process algebra domain) to look if
>the activity diagrams match. bisimulation has problems with parallelism
>so after a transformation the parallelism could be removed and a State
>Transition System (STS) resulted. Then any non-deterministic STS had to
>get deterministic by some more transformations. Then two deterministic
>STS could be compared.
>
>I cannot imagine, how this could be applied to CPA composition or CPA
>negotiation ... basically, because a CPP or CPA is not an activity
>diagram ...
>
mm1: My point was only related to assessing the viability of matching 
business processes (and business transaction characteristics) that may 
be a part of the negotiation (post v1.0 or afterward).

>b) Content matching
>-------------------
>
>Next, Dennis was looking at content matching. In particular if business
>documents match. He introduced Core Components and Aggregated Business
>Information Entity. 
>  
>
mm2: We may be seeing more work in the future where business document / 
information methodology (CCTS) and business processes may converge.

>Schlegel: So in summary, I do not think much, if any, can be applied for the CPA
>negotiation. Please let me know, if you think different.
>
>One point is interesting: How far down the path goes the CPA
>negotiation? At the moment, I think the CPA negotiation concentrates on
>CPA element/attributes only. Also, currently, the CPA negotiation does
>not address any higher level business negotiation.
>  
>
mm2: This could help CPA maintain some degree of modularity. It also 
then must leave the other negotiation to be done prior to CPA 
negotiation or to be done by an external service and information 
provided back to CPA. This supports your comments below too I believe.

>Schlegel: Eventually, a CPA formation process has to make sure, that not only the
>CPP/CPA elements and attributes match but also, that the business
>processes and business documents match. One could argue and say,
>notifying the user when an inconsistency is found is all what is needed.
>This is what my project (CPA composition) was doing, if the CPP's
>reference different business process -> indicating serious problem and
>aborting. If the CPP's reference different business documents ->
>indicating a problem (no serious as business process match) and making a
>note in the gap list.
>
>>partially resolved using WSPL or left outside of the CPPA 
>>negotiation. 
>>    
>>
>Sacha: Remembering from what I saw in the XACML examples, yes I could
>imagine, that we could use XACML, or their Policies in the Negotiation
>Description Document (NDD), in particular in the Negotiable Information
>Item (NII) element to define data types, ranges, priorities and more.
>Some more reading, of my part, is necessary.
>
>But again, in the end, the negotiation software at both negotiator ends
>will chose the negotiation values and not the ebXML CPA negotiation
>BPPSS or anything specified in the Automated Negotiation of CPA (ANCPA)
>specification (see empty CPA algorithm section in the ANCPA spec). I
>have to admit, I did not read the XACML or the WSPL specifications, but
>maybe we could enhance the negotiation samples in the CPA negotiation
>specification with a sample backend negotiation application, where the
>backend negotiation system uses matching functions of the XACML
>specification ... to determine matches...
>
>Again, I have to admit, I did not further study Kartha's sample NDD in
>the appendix of the ANCPA specification. I think Kartha's sample reveals
>best, of how NII are ought to be used how the negotiation algorithms
>have to be developed.
>
>How I understand it, the CPA negotiation specification does not provide
>how to negotiate, but provides the infrastructure of the negotiation,
>with the negotiation business process, a negotiation CPA skeleton, the
>negotiation messages and some negotiation rules.
>
>Maybe its time to think further about the execution of the negotiation.
>  
>
mm2: Yes.

>>I am not advocating any approach but all present some 
>>opportunity and challenges. Thanks.
>>    
>>