ebBP 7/6/2005: Role Binding Summary (Discussion Item 12 July 2005)

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

We'll entertain further discussion on the role bindings on Tuesday's call 12 July 2005.
Here is the summary I promised to reference.

Role Discussion Summary:
Roles are typically attached to the Business Transaction Activity not the Business Transaction. Questions were raised on roles during the initiation of the wd-2-0-1-12 proposal vote (related to adding a RespondingBusinessActivity to the Notification and InformationDistribution concrete patterns in the v2.0.1 ebBP schema). Note, from v1.01 (including v1.1), the BT did not have roles defined on the element and a rudimentary form of Performs also existed. The Performs element was enhanced in v2.0/v2.0.1 to accommodate user community requirements on role changes (such as for Negotiation use case and the business scenario provided by Cristiano Novelli) [1]. We've found that role changes occur from the abstract partner on a business collaboration to the concrete roles that parties assume during a BTA (or across many BTA that may share the same BT).

Kenji Nagahashi had raised the question about the implicit roles in any business transaction, and asked where the roles are bound (which he related to the RespondingBusinessActivity change). [2] Related to roles, Nagahashi proposed that Perform should not directly refer to Activity in BT; it should always refer to 
BT Roles and Activities should get associated with the external role through those BT roles. Kenji felt this simplified the constructs.

Summary points from Tuesday's call, 5 July 2005 (thanks to all who attended): [3]
1. Adding roles on business transaction impacts reusability.
2. Separate in the roles definition - when bound and bound to what. Is the pattern and ebBP definition different from how it is used?
3. Semantic nature of Performs (since beginning) links to activity that is being performed. A transaction has both activities. Roles are identified. Adding roles to BT doesn't change the requirement that Performs relate to an activity.
4. Adding roles to BT and change with RespondingBusinessActivity are orthogonal.
5. CPPA needs to understand roles, parties and activities in order to build out CPP actions for that choreography automatically. Need association between choreography (BTA) and the context of which they refer.
6. Roles are defined in the context of the associated business collaboration.
7. @name and @nameID should be retained with the latter used for referencing in a consistent manner.
8. If the other party is in any way identified, any action requires both activities to bind business responsibility.

Agreed Tuesday:
1. Discuss Role questions 12 July 2005. This will be added to the agenda.
2. Separate the vote for RespondingBusinessActivity and the role questions. One doesn't preclude consideration of the other. Please remember to vote on wd-2-0-1-12 before the vote closes 7 July 2005 (tomorrow).

Thanks.

[1] Negotiation example is in the v2.0.1 Spec package in the appendices.
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/document.php?document_id=13327
Novelli business scenario: http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200507/msg00020.html
[2] Nagahashi proposal: http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200507/msg00020.html
Moberg response: http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200507/msg00015.html
Martin response: http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200507/msg00016.html;
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200507/msg00010.html
(Patterns reference)
[3] TC members may have differing views on some of these points.