[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 120 - What are the semantics when an initial<receive> has no correlation set?
Ugo, I think what you are describing is an indeterminant process, caused by the concurrency introduced by the flow. A static analysis could reveal this. <receive> <flow> <receive><cset initiate = "yes"> <receive><cset initiate = "no"> As you pointed out, if this wasn't found by static analysis, a run-time error could occur, if the receives were executed in the wrong order. -Ron Ugo Corda wrote: Ron, It looks like the condition you describe cannot always be detected via static analysis. Imagine a process where the initiating <receive> (with no correlation set) is followed by a flow. One branch of the flow contains an invoke with correlation set (and initiate="yes"), while the other branch has a receive, also with the same correlation set (and initiate="no"). Evidently the order of execution required to avoid the error you mention would be invoke followed by receive. But that might only be known at run-time. Even worse, under identical conditions the generation of the error might be implementation-dependent. Suppose that the message is sent to the receive before the invoke is executed. One implementation might decide to cache the message and activate the receive only after the invoke is executed, in which case the receive might correlate with the set value established by the invoke (no error). But another implementation might just generate the error right away as soon as the message is received before the invoke. Ugo-----Original Message----- From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM] Sent: Friday, August 13, 2004 1:04 PM To: wsbpel@lists.oasis-open.org Subject: Re: [wsbpel] Issue - 120 - What are the semantics when an initial <receive> has no correlation set? 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, processesit, sends aresponse 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 worthdefining explicit singleton behavior in BPEL 2.0 (or whatever we call it)? To which, given our other priorities, I think the answer isno. But Irealize that my answer is just a matter of opinion.To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]