RE: [wsbpel] Conflicting partnerlinks

["Eckenfels. Bernd" <B.Eckenfels@seeburger.de>]

Hello Assaf,

This understanding would be my preferred solution. 

However I rember a lot of discussions about different process instances
who can step on the toes of each other (and provoke a conflicting
receive).  I think they originated from the correlation task of finding
the correct process instance (which is allowed to spawn different
process templates).

If we (now) all agree, that we do not define
cross-process-template-instance constraints, I would feel fine (not sure
if thet would require a change in spec)

Greetings
Bernd

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com] 
Sent: Tuesday, March 01, 2005 6:51 PM
To: Eckenfels. Bernd
Cc: wsbpeltc
Subject: Re: [wsbpel] Conflicting partnerlinks

Eckenfels. Bernd wrote:

> Thinks we need to consider:
>
>Bla:Proc1 and Fasel:Proc2 both define a PartnerLink name="initial"  - 
>are outstanding receives allowed?
>
>Bla.Proc1 defines two PartnerLink name="initial" in <scope><partnerLink

>name="initial" /><scope><partnerLink name="initial"
>/>...</sceope></scope> - are two conflicting receives allowed?
>  
>
The other possibility is that these two receives (in both examples) are
not conflicting since the partner links are distinct, and therefore can
be enabled simultaneously.

My reading of the spec is that if you declare two partner links, they
are distinct. As are two instances resulting from two process instances
or scope instances. The name does not disambiguate globally, nor is it
the source of distinction.

Assaf


>Greetings
>Bernd
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>
>
>  
>