[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [RSD] Roles Options
Discussion|OASIS.ebBP.Roles;
Topic|WI13
mmer@
We had a long and rather tortuous discussion in Santa Clara (BTW we met in an old Asylum!) on Roles. The key was that there are several levels at which roles can be defined:
1) the BusinessTransaction level - not currently implemented - to remain implicit
2) the BinaryCollaboration level - what is currently supported and will remain
3) the ProcessSpecification - not referenced at the moment.
There is another one which is the nested collaboration through the use of the CollaborationActivity.
What was proposed was that we introduced the ProcessSpecification level of role definition that would represent the highest level of roles that would be able to perform the BPSS. I feel an example coming on, but do not forgat that names can make examples seem rather arbituary - so bear with me.
before going into the example I enclose two pictures showing two possible options for linking level 2 and level 3 roles. One is from the level 3 down and the other is, guess what, the other way round. These might not be mutually exclusive. We might like a both and approach. <<Roles.gif>> <<binCollabRole.gif>>
The Example:
ProcessSpecificationLevel - (level3) Roles - ServiceProvider and NetworkProvider
Two Collaborations (level2):
BinaryCollaboration: OrderingCollaboration: Roles - Buyer and Seller
BinaryCollaboration: RepairCollaboration: Roles - ServiceOwner and Repairer
- The required mappings would be: ServiceProvider performs Buyer and ServiceOwner - NetworkProvider performs Seller and Repairer.
Where these mapping take place is rather arbituary, except in the following example:
ProcessSpecificationLevel - (level3) Roles - ServiceProvider and NetworkProvider and NetworkEquipmentProvider
Two Collaborations (level2):
BinaryCollaboration: OrderingCollaboration: Roles - Buyer and Seller
BinaryCollaboration: RepairCollaboration: Roles - ServiceOwner and Repairer
In this case the role mappings would be:
ServiceProvider performs Buyer and ServiceOwner
NetworkProvider performs Seller, Buyer, Repairer and ServiceOwner
NetworkEquipmentProvider performs Seller and Repairer.
This is obviously more complex and could be said to begin to be multiparty, except we have no dependancies between the collabs.
I could go onto provide another example where there is a nested collab:
ProcessSpecificationLevel - (level3) Roles - ServiceProvider and NetworkProvider
Two Collaborations (level2):
BinaryCollaboration: OrderingCollaboration: Roles - Buyer and Seller
NestedBinaryCollaboration: PreOrderCheckCollaboration: Roles - ProvisionalBuyer and InventoryOwner
the mappings would be:
ServiceProvider to Buyer
Networkprovider to Seller
within the CollaboartionActivity the following mapping would apply:
Buyer to ProvisionalServiceOwner
Seller to InventoryOwner
This looks OK to me as you can track all the way through from the level three to the inner collaboration. The final piece of the jigsaw is when the nested Collab can also exist in a non nested fasion. In this case any mappings given at the higher level could be overwritten by the mapping given in the CollaborationActivity. With this simple rule we can not have the case where one collaboration can contain two instances of another with different role mappings for each included collaborations.
@mmer
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]