Re: [ebxml-bp] Re: Updated InformationDistribution,Notification Patterns and Performs (Roles

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

Kenji,
This is converse to our agreement to use @nameid for referencing. We should also discuss how flexible any approach is to future changes involving more complexity in StatusVisibility, ComplexBTA, etc. We can discuss your proposal Tuesday morning as this is a more substantive change than simply adding two Responding Business Activities on two patterns. It affects several underlying assumptions.

One point that we should remember is this is collaborative, not single party view and it is consistent to have both activities.  To me from a business perspective this is very important in eBusiness. Another key point is that historically use communities have had ready access to augment the patterns at will. With these concrete patterns, interested user communities will learn quite a bit about the patterns, their intent, how they may be used, and what responsibilities they require. I think this discussion is evidence of that.

Talk to everyone Tuesday. Remember that the vote ends Thursday and also is the precursor to Committee Draft vote. Thanks. Monica

----- Original Message -----
From: Kenji Nagahashi <nagahashi@us.fujitsu.com>
Date: Friday, July 1, 2005 7:04 pm
Subject: Re: [ebxml-bp] Re: Updated InformationDistribution, Notification Patterns and Performs (Roles

> Thank you Monica and Dale for quick help!
> 
> I found the diagram quite familiar as RosettaNet has been using 
> the 
> diagram for years...
> 
> Seeing the diagram, I still find nothing wrong with current BT 
> schema, 
> except for possible confusion of a "Activity" concept.
> 
> If what we want here is word-by-word adoption of UML activity 
> diagram 
> representation for transaction patterns, it would be the right 
> thing to 
> let BTs always have two Activities. But I'm not sure if this 
> adoption is 
> the good thing, since the activity diagram requires redundant 
> description. It would be good for explaining the semantics of 
> patterns, 
> but not for use of pattern (as BPSS is meant for).
> 
> <Dale>
> > The other Role is the initiator of the RespondingActivity. 
> Because each
> > of the RequestingBusinessActivity and RespondingBusinessActivity 
> has a
> > unique nameID value to refer to, that permits each Role to be 
> uniquely> associated with an activity. 
> </Dale>
> 
> After reading this, I (finally) realized that focus of the 
> discussion is 
> the role-binding between BC roles and BT roles (is it right? how 
> dumb am I).
> 
> In current draft specification, BTA/Performs points to 
> RequestingBusinessActivity or RespondingBusinessActivity! (Sorry I 
> didn't know that). I see semantic anomaly here. I propose 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 
> though those BT roles. If Perform always binds role to role, 
> specification would be simpler and more consistent.
> 
> Of course this approach has a problem: two roles in BT are 
> implicit and 
> doesn't have ID to refer to! So I'd propose the following solution:
> 
> * make Performs/@currentRoleRef and Performs/@performRoleRef 
> string type 
> attributes
> * and let them refer to Roles by Role/@name instead of Role/@nameID
> * Use reserved special role names for referenging BT roles: such 
> as 
> "initiator" and "responder"
> * discard Performs/@initiatingRoleRef and Performs/@respondingRoleRef
> 
> Is this bad because inconsistent with the policy of using @nameID 
> for 
> referencing?
> 
> Regards
> Kenji
>