Re: [wsbpel] Issue 81 - Rough draft of proposal for vote

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

That is not necessarily a race condition. The <receive> will be correlated to the process instance, using correlation sets that will be initialized before the <invoke> is commited (ie, the message is sent).

A naive BPEL implementation might create a race condition between the <invoke> and <receive>, due to its own internal state management. If I recall correctly, the Collaxa BPEL engine addresses this, and other potential race conditions related to message exchanges, in robust ways. Perhaps Edwin can comment on this further?

-Ron

Ugo Corda wrote:

The following is also statically detectable:

sequence
	invoke
	receive
sequence

Depending on the time spent executing the invoke, the receive message might be lost. So are we going to disallow that type of sequence too?

Ugo

  

-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com] 
Sent: Friday, September 10, 2004 11:55 AM
To: ygoland@bea.com; Ugo Corda
Cc: wsbpeltc
Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote


I have a sense of déjà vu that I have seen this and replied 
to it earlier.

Basically, the answer is that it is possible to make process 
protocol mistakes that would cause races that would then risk 
losing messages.  Not all such races can be statically 
detected.  However, non-start initial receives (assuming they 
are appropriately correlated) are an obviously statically 
detectable case, hence there is no reason to allow them.

-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com] 
Sent: Friday, September 10, 2004 10:54 AM
To: Ugo Corda
Cc: Satish Thatte; wsbpeltc
Subject: Re: [wsbpel] Issue 81 - Rough draft of proposal for vote

I agree with Ugo. I don't see the difference. What makes it 
'explicitly 
impossible' to expect that such a message would arrive? In 
fact, how is 
it any different than a start receive immediately followed by a 
non-start receive? The behavior in the BPEL sense would 
appear to me to 
be identical.

	Thanks,

		Yaron

Ugo Corda wrote:

    

 > Yes except in the latter case we have some expectation of a  > 
protocol to make sure messages don't arrive too early.

I cannot see the difference. The activation of a 
      

non-initial receive 
    

is dependent on the completion of the preceding activities in the 
sequence, which can be completely run-time dependent. The 
      

activation 
    

of an initial non-start receive is dependent on the 
      

reception of the 
    

initial start receive, which can also be completely run-time 
dependent. I don't see how any protocol could do better in one case 
than in the other.

Ugo

 > -----Original Message-----
 > From: Satish Thatte [mailto:satisht@microsoft.com]
 > Sent: Tuesday, August 31, 2004 10:15 AM
 > To: Ugo Corda; ygoland@bea.com
 > Cc: wsbpeltc
 > Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal 
      

for vote  
    

 >
        

 > Yes except in the latter case we have some expectation of a
 > protocol to make sure messages don't arrive too early.  In
 > the initial non-start receive this is explicitly impossible.
 > I am just saying that we can interpret this at a technical
 > level but I wonder if it is really meaningful. Not a huge
 > deal but my preference is to tighten the features so we can
 > justify their usage.
 > 
 >
 > -----Original Message-----
 > From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
 > Sent: Tuesday, August 31, 2004 10:10 AM
 > To: Satish Thatte; ygoland@bea.com
 > Cc: wsbpeltc
 > Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote
 >
 > I imagine that would be not different than the case of a
 > non-initial receive to which a message is sent before the
 > receive itself is activated. It would be up to the
 > implementation to decide whether to cache the message or drop it.
 >
 > Ugo
 >
 > > -----Original Message-----
 > > From: Satish Thatte [mailto:satisht@microsoft.com]
 > > Sent: Tuesday, August 31, 2004 9:40 AM
 > > To: Ugo Corda; ygoland@bea.com
 > > Cc: wsbpeltc
 > > Subject: RE: [wsbpel] Issue 81 - Rough draft of 
      

proposal for vote
    

 > >
 > >
 > > Suppose such an activity is a receive.  How would the message
 > > be correlated to the instance without danger of being lost if
 > > it arrived "too soon"?
 > >
 > > 
 > > -----Original Message-----
 > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
 > > Sent: Tuesday, August 31, 2004 9:31 AM
 > > To: Satish Thatte; ygoland@bea.com
 > > Cc: wsbpeltc
 > > Subject: RE: [wsbpel] Issue 81 - Rough draft of 
      

proposal for vote
    

 > >
 > > It would probably be easier if you could explain why those
 > > activities should be banned. What kind of problems do you
 > > think they would create?
 > >
 > > Ugo
 > >
 > > > -----Original Message-----
 > > > From: Satish Thatte [mailto:satisht@microsoft.com]
 > > > Sent: Monday, August 30, 2004 10:47 PM
 > > > To: Ugo Corda; ygoland@bea.com
 > > > Cc: wsbpeltc
 > > > Subject: RE: [wsbpel] Issue 81 - Rough draft of 
      

proposal for vote
    

 > > >
 > > >
 > > > Help me understand why we should allow initial non-start
 > activities?
 > > > Why not ban those?
 > > >
 > > > 
 > > > -----Original Message-----
 > > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
 > > > Sent: Friday, August 27, 2004 8:04 PM
 > > > To: ygoland@bea.com
 > > > Cc: wsbpeltc
 > > > Subject: RE: [wsbpel] Issue 81 - Rough draft of 
      

proposal for vote
    

 > > >
 > > > Your new wording works for me!
 > > >
 > > > Thank you,
 > > > Ugo
 > > >
 > > > > -----Original Message-----
 > > > > From: Yaron Y. Goland [mailto:ygoland@bea.com]
 > > > > Sent: Friday, August 27, 2004 3:39 PM
 > > > > To: Ugo Corda
 > > > > Cc: wsbpeltc
 > > > > Subject: Re: [wsbpel] Issue 81 - Rough draft of
 > proposal for vote
 > > > >
 > > > >
 > > > > An excellent point. So long as we require that all
 > processes MUST
 > > > > have at least one start activity then initial 
      

activities can be
    

 > > > > anything.
 > > > >
 > > > > Below is my modified rough draft of a proposal to vote:
 > > > >
 > > > > Section 6.4
 > > > >
 > > > > Change: To be instantiated, each business process must
 > contain at
 > > > > least one such "start activity." This must be an initial
 > > activity in
 > > > > the sense that there is no basic activity that logically
 > > precedes it
 > > > > in the behavior of the process.
 > > > >
 > > > > To: To be instantiated, each business process must
 > > contain at least
 > > > > one such "start activity." That is, a receive/pick activity
 > > > > annotated with a createInstance="yes" attribute. See
 > section 11.4
 > > > > for more details on start activities.
 > > > >
 > > > > Section 11.4
 > > > >
 > > > > Change: A receive activity annotated in this way MUST be
 > > an initial
 > > > > activity in the process, that is, the only other basic
 > activities
 > > > > may potentially be performed prior to or simultaneously
 > > with such a
 > > > > receive activity MUST be similarly annotated 
      

receive activities.
    

 > > > >
 > > > > To: A receive/pick activity annotated in this way MUST be
 > > a "start
 > > > > activity". A "start activity" is an initial 
      

activity that has a
    

 > > > > createInstance="yes" attribute defined on it. An initial
 > > activity is
 > > > > a receive/pick activity where no other activities but
 > > scope, flow,
 > > > > sequence and empty activities occur before it in 
      

the process's
    

 > > > > execution path. While all start activities must be initial
 > > > > activities not all initial activities are required 
      

to be start
    

 > > > > activities. If
 > > > an initial
 > > > > activity is not a start activity then the initial activity
 > > > will only
 > > > > become active when it is inside of a process instance.
 > > > >
 > > > > Change: It is permissible to have the createInstance
 > > attribute set
 > > > > to "yes" for a set of concurrent initial activities.
 > > > >
 > > > > To: It is permissible to have multiple start activities.
 > > > >
 > > > > Change: All such receive activities MUST use the same
 > correlation
 > > > > sets (see Correlation).
 > > > >
 > > > > To: If a process has multiple start activities then all
 > the start
 > > > > activities MUST use the same correlation sets (see
 > > > Correlation).
 > > > >
 > > > > Ugo Corda wrote:
 > > > >
 > > > > >
 > > > > >
 > > > > >  > and only receive/pick in
 > > > > >  > addition to the previously listed activities MAY occur
 > > > > in parallel
 > > > > > with  > it in the process's execution path.
 > > > > >
 > > > > > Why limit it to other receive/pick activities? If the
 > > following is
 > > > > > allowed
 > > > > >
 > > > > > <flow>
 > > > > >       <receive createInstance="yes".../>
 > > > > >       <receive createInstance="no".../>
 > > > > > </flow>
 > > > > >
 > > > > > then why not also allow this:
 > > > > >
 > > > > > <flow>
 > > > > >       <receive createInstance="yes".../>
 > > > > >       <invoke .../>
 > > > > > </flow>
 > > > > >
 > > > > >
 > > > > > Ugo
 > > > > >
 > > > >
 > > >
 > > > 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_workgr
 > > oup.php.
 > >
 > >
 > > 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_workgr
 > oup.php.
 >
 >
 > 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_workgr
oup.php.

      

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.