Re: [wsbpel] Issue - 120 - What are the semantics when an initial<receive> has no correlation set?

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

Ugo,

    If we rule out singletons, then non-initiating <receives>s in a 
process MUST be correlated to an existing process instance.

    If the BPEL engine receives a message for a non-initiating <receive> 
activity, and that message cannot be correlated to an existing process 
instance, it is an error. If there is no chance of the message being 
correlated (the <receive> has no correlation set that can be used for 
this purpose), it is still an error. The question is: is it a run-time 
error, or one detected during static analysis of the <process>?

-Ron

Ugo Corda wrote:

>Even if we rule out singletons, we should still clarify what happens
>when multiple instances exist at the same time as a consequence of
>multiple messages being sent to the initial <receive>. If no
>correlationSet exists to distinguish the various instances, what happens
>to successive messages (non instantiating) sent to the instances? Do all
>the instances get a copy the message? Is it implementation-defined?
>
>Ugo
>
>  
>
>>-----Original Message-----
>>From: Yaron Y. Goland [mailto:ygoland@bea.com] 
>>Sent: Friday, August 13, 2004 11:00 AM
>>To: Ugo Corda
>>Cc: Ron Ten-Hove; wsbpel@lists.oasis-open.org
>>Subject: Re: [wsbpel] Issue - 120 - What are the semantics 
>>when an initial <receive> has no correlation set?
>>
>>
>>It occurs to me that we can break this problem down a little more.
>>
>>One can trivially imagine a web service that consists of exactly one 
>>request/response pair that receives a message, processes it, sends a 
>>response and exits. Such a webservice would have no need to use 
>>correlation sets. Therefore I think we can be sure that at a 
>>minimum we 
>>want to make it possible to define a BPEL that has a single start 
>>activity with no correlation set that doesn't create a singleton.
>>
>>What this argues to me is that the default interpretation of 
>>a BPEL with 
>>a start activity with no correlation set is that it is not a 
>>singleton.
>>
>>Therefore what 120 really should be about is - do we want to 
>>intentionally add an attribute or other mechanism to specify 
>>that a BPEL 
>>process is intended to be a singleton?
>>
>>We already know we can simulate a singleton in BPEL by having an 
>>instance with a start activity that is only known to the deployment 
>>environment and then having all subsequent messages sent to 
>>the single 
>>BPEL instance. But I readily admit that this is a less than clean 
>>solution. It is best when possible to directly express one's 
>>semantics.
>>
>>So I think we can then rephrase the issue once again to - Is it worth 
>>defining explicit singleton behavior in BPEL 2.0 (or whatever 
>>we call it)?
>>
>>To which, given our other priorities, I think the answer is no. But I 
>>realize that my answer is just a matter of opinion.
>>
>>    
>>