[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa] FW: CPPA Simple Negotiation Model v0.06
-----Original Message-----
From: Hayes, Brian [mailto:Brian.Hayes@Commerceone.com]
Sent: Tuesday, March 12, 2002 9:11 AM
To: ebtwg-bcp@lists.ebtwg.org; ebtwg-bps@lists.ebtwg.org
Subject: CPPA Simple Negotiation Model v0.06The follwing e-mail has been posted to ebxml-cppa-negot@lists.oasis-open.org. I believe this to be a quality example of a modeling effort. Comments are welcomed, however, please consider where to route you comments. General discussion of the the model and CPPA Negotiation issues should probably be sent to ebxml-cppa-negot@lists.oasis-open.org.
---
The "Collaboration Protocol Agreement Simple Negotiation Business Process Model", version 0.06, work-in-progress, is available at http://brianhayes.home.attbi.com/TR/index.html#CPPA
4.1 Summary
This model specifies a simple business process for negotiating Collaboration Protocol Agreements. The model is based on the Simple Contract Formation Pattern as specified in ebXML E-Commerce Patterns [bpPATT]. Further text TBD.This model was developed in accordance to the methodology (process, meta-model, and notation) and patterns as set forth in the following specifications and technical reports: Business Process and Business Information Analysis Overview [bpOVER], ebXML Business Process Analysis Worksheets and Guidelines [bpWS], ebXML E-Commerce Patterns [bpPATT], and the UN/CEFACT Modeling Methodology [UMM].
The following types of files related to this model are available at http://brianhayes.home.attbi.com/TR/: BPSS XML Instance, web page version of UML model, and the Microsoft Word version of this text.
Model, v 0.06, Post-script
I did not have the time to do on-line research on negotiation prior to "publishing" version 0.06. However, here's some sites that might be worth investigation for terminology, process etc. For example, standard names for the authorized roles and other terms such as B.A.T.N.A. may be found in these resources:
- UCLA Office of Contract and Grant Administration. http://www.research.ucla.edu/sr2/gloss.htm
- DLA Commercial Activities (A-76) Competition Guidebook. http://www.dla.mil/J-8/A-76/DLSCA-76Guidebook.html
- Formal Conversations for the Contract Net Protocol. www.cpsc.ucalgary.ca/~robertof/publications/acai01/acai2001Flores&Kremer.pdf
- Google.com searches for negotiation, offer, proposal, role, etc.
Sincerely,
Brian Hayes
Commerce One Labs
Title: CPPA Simple Negotiation Model v0.06
- From: "Hayes, Brian" <Brian.Hayes@Commerceone.com>
- To: "Arvola Chan" <arvola@tibco.com>
- Date: Wed, 13 Mar 2002 11:51:32 -0800
See below. You may want to post your question to the ebtwg-bps@lists.ebtwg.org and see if you get a different answer. Good people to get comments from are JimClark <jdc-icot@lcc.net>; John Yunker john.yunker@bleuciel.org; Antoine Lonjon ALonjon@MEGA.com; so, you may want to email them directly.Also, pardon any long winded answers -- I'll be referencing specifications to make things clearer for myself.1. [Arvola] I still don't have a good grasp of the relationship between the InitiatingRole and RespondingRole elements (under BinaryCollaboration) and the fromAuthorizedRole and toAuthorizedRole attributes (undefr BusinessTransactionActivity). Do their names have to match? Within one BinaryCollaboration, doesn't each party plays exactly one role?[Brian] In my interpretation of the UMM Metamodel, the answer is yes, the names must match. I don't think the UMM Metamodel elaborates on the mapping of the role on the PartnerType to BusinessCollaboration association (in the Business Requirements View (BRV), UMM Metamodel figure BRV-Semantics) to the AuthorizedRole class (in the Business Transaction View(BTV)). In the UMM Metamodel, AuthorizedRole performs a BusinessAction (RequestingBusinessActivity or RespondingBusinessActivity). Now, the UMM could be missing some documentation that states that there is mapping from the role names used in the BRV to the BTV AuthorizedRoles and that the names do not need to be the same. I think the UMM may also be missing documentation that discusses the mapping of AuthorizedRoles in nested collaborations.BTW, the UMM Metamodel is important here because the BPSS is defined as a semantic subset of the UMM Metamodel AND the worksheets are based on the the UMM Metamodel and not the BPSS.1.1. [Arvola] Within one BinaryCollaboration, doesn't each party plays exactly one role?[Brian] Rather than answer this directly, here's my interpretation of the bpBPSS: Each party plays exactly one set of roles in a binary collaboration (including any nested binary collaborations): The [ebBPSS, 1.0.1, sectio 6.4.2.1] states "A Binary Collaboration is always between two roles." A Binary Collaboration can reference another (a sub collaboration) Binary Collaboration via the CollaborationActivity element. This referenced sub Binary Collaboration can have two roles that are different than the roles in the containing Binary Collaboration. The initiation roles map to each other and the responding roles map to each other.To understand this problem better, one needs to understand the semantics behind these elements which is deeper than the names of the elements. Sometimes the apparent differences between the BPSS and the UMM Metamodel confuses me; thus, it takes a bit of time to clear things up -- more time than I have today.2. [Arvola] Is there a problem with the following definition in CollaborationProtocolAgreementSimpleNegotiation$0.06.xml:<BusinessTransactionActivity name="Counter Offer CPA BTA" nameId="CounterOfferCPABTA" businessTransaction="Counter Offer CPA" businessTransactionIDRef="btid:CounterOfferCPA$0.06" fromAuthorizedRole="CPA Negotiator B" toAuthorizedRole="CPA Negotiator A" isConcurrent="false" isLegallyBinding="true" timeToPeform="P99D88H77M" /></BinaryCollaboration>How can the BinaryCollaboration allow for the possibility of either "CPA Negotiator A" or "CPA Negotiator B" initiating the "Counter Offer CPA BTA" BusinessTransactionActivity?[Brian] Within the context of the BusinessTransactionActivity element itself, the information is accurate. Via the CPA the two parties sign up for the roles they want to play. Now, within the context of the BinaryCollaboration element, it appears there lies the confusion. As you have seen, the BinaryCollaboration defines<InitiatingRole name="CPA Negotiator A" nameID="CPANegotiatorA" />
<RespondingRole name="CPA Negotiator B" nameID="CPANegotiatorB" />In the UMM Metamodel, the BusinessCollaborationProtocol activity model/graph does not have roles associated with it. It does have BusinessPartner class which in turn references roles in BusinessTransactions. The BPSS has a BusinessPartnerRole element; but, it is in the MultipartyCollaboration.I am thinking that the InitiatingRole and RespondingRole elements have no meaning to the BusinessTransactionActivity element other than to define the possible set of roles for the BinaryCollaboration (e.g. interpret them as Role1 and Role2).BTW, you've helped spot another error in the BPSS instance. I believe the Transition fromBusinessState and toBusinessState attributes should reference BusinessTransactionActivities (or CollaborationActivities) and not BusinessTransactions./Brian
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC