Re: Relationship cardinalities (was ... RE: Requirements: Decisio n Po ints Requirement Proposals

Burdett, David wrote:

> Assaf
>
> I always tend to think that one role can take part in multiple 
> choreographies, for example a buyer could take part in:
> 1. Several different choreographies each of which resulted in the 
> placement of an order
> 2. A separate order status choreography that could work with any of 
> the different choreographies.
>
Of course the buyer can participate in any number of choreographies it 
wants, but as an entity there is nothing precluding the buyer from doing 
that. I assume the choreographies are not related and so neither 
choreography cares what said entity would be doing on behalf of some 
other choreography. So now the question becomes what does it mean for 
the same role to take part in multiple choreographies?

Does it mean 'thou shall not preclude some entity from participating in 
more than one choreography'? What would the requirement on the language 
to make a non-restriction like this?

Does it mean all the choreographies need to use the exact same role 
name? What happens if they don't - does it preclude the buyer entity 
from participating in two different choreographies (known by different 
names)? What if they do - is that sufficient to allow the buyer to 
participate in different choreographies?

Does it mean they all expect the buyer to use the same set of 
interfaces? If so, how do you combine the same interface into multiple 
choreographies?

> I also recognize that the same choreography and roles could be 
> invented multiple times. For example, the shoe industry could invent a 
> choreography for placing orders that was identical to one developed by 
> the wine industry but they give the choroegraphies different 
> identifiers (URIs) for choreography itself and each of its roles.
>
> This is really a broader standardization issue that will only be 
> solved when there is choreography instance standardization. For 
> example the UBL initiative is developing standard representations and 
> semantics for order documents using XML schema. We really need 
> standard order placement choreographies to be developed using WS-Chor 
> ... but we need WS-Chor first.
>
I am assuming the case of standardization and the case of 
non-standardiation are both valid. You would have cases where 
standardization is either easy, done unilaterally, or beneficial to all 
parties to agree. You would have cases where even if you could agree 
there's no benefit in doing so, maybe just because there's too much 
variance. I don't know if there's a lot of benefit for the shoe and wine 
industry to do things differently just because they classify products in 
different way, but I could think of a construction company that needs to 
order office supplies, heavy equipment and flammable materials and these 
may be different processes altogether.

arkin

> David
>

Received on Monday, 9 June 2003 17:45:31 UTC