----- Original Message -----
Sent: Monday, February 16, 2004 11:18
AM
Subject: [ebxml-bp] [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