[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-cppa-negot] CPA negotiation, contact with negotiationresearch community plus some thoughts.
Hi Monica My comments below. On Mon, 2004-05-24 at 22:17, Monica J. Martin wrote: > >Schlegel: If the Automated Negotiation of CPA specification does not deal with the > >actual negotiation, then I think the negotiation protocol (bpss), the > >negotiation messages, and some negotiation rules, are already pretty > >good. The problem I think is the high number of possiblites of what can > >be negotiated, there are so many possiblities, that its difficult to > >imagine. > > > >So, if we want to continue the negotiation path, I think we need to talk > >about the NDD more, specially about those types of the negotiable > >information items. In my research I did not realy use an NDD but sort of > >a restricted NDD, where users only could negotiate over values of > >elements and attributes of the CPA template, not about ranges or > >cardinality problems, or values with piecewise functions. > > > >Also, I wonder how much negoitation information is necessary in an NDD. > >Beacuse, in the end, the negotiation will be run in a negotiation > >application (or software agent). So for example, a piecewise function > >might expose already too much information. A simple reference to the > >negotiable element or attribute might be sufficient. The only reason for > >more information in the NDD was (as far as I remember), to potentially > >converge to a solution faster. On the other hand, the CPA composition > >process can use some more information, again on the cost of revealing > >those information. > > > >Please let me know what you think. > > > > > mm1: Sacha, prior to this time we discuss how CPPA could effectively > work / interoperate with XACML and WSPL. Could not the cardinality, > value, range resolution occur using WSPL as another complementary > service? Perhaps this is outside of the scope of your question but the > functionality may already exist to do so. Sacha: Need to look closer into XACML and WSPL. > > 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. I try to summaries a little ... --------------------------------- --------------------------------- 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. a) Business Process (ebXML special UML Activity Diagrams) matching ------------------------------------------------------------------ If two CPP's reference the "same" business process, then there is no problem, concerning the business process. There can still be problems, as I found in my research. But from a business process point of view, both CPP's are talking about the same business process. If the two CPP's are referenceing a different business process, then there is a problem. Dennis was looking at the two different business processes and was trying to check if there is still a possiblity to say, that the two business processes are sort of compatible. The assumption was taken, that a business process lists business sceanrios. If at least one sceanrio was the same of the two business processes, there could be a new business process with only that one scenario, or all common scenarios. 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. 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 ... 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. Bascially, Dennis discovered after communication with Core Components membmers, that a business document, or the root element of a business document will be a ABIE. So if two companies reference the same ABIE, no problem. Again, a problem occurs if two parties reference different ABIEs. The idea was to create (automatically) a third ABIE, with the most common properties of the two conflicting ABIE's (if I understand right). Dennis used the context of ABIEs to check whether ABIE's could match. Eg. A NL_EUROPE_Address ABIE has a hierachical geographical context with Europe on the top level, followed by NL (Netherland) on the next level. I did not follow how to match ABIES based on context. Dennis had another paragraph on ABIE's syntax checking. I think, he is talking about the schema files of two different ABIE's. He had problems with the cardinality of ABIE's properties, where we have the options of: Mandatory, Optional, and not present. So Dennis provided a table, how a a third ABIE (based on the two different ABIE) has to define the cardinality's (of ABIE properties) based on the cardinalities of the input ABIEs (properties). Again, I think this is meant, when creating a new ABIE. --------------------------------- --------------------------------- 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. 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. > I am not advocating any approach but all present some > opportunity and challenges. Thanks. Kind regards Sacha > > > > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ebxml-cppa-negot/members/leave_workgroup.php. -- ------------------------------------------------ Sacha Schlegel ------------------------------------------------ public key: www.schlegel.li/sacha.gpg ------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]