OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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?


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, 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.
> >>
> >>    
> >>
> 
> 
> 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/le
ave_workgroup.php.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]