In your example, there is no race if the invoke is initiating the correlation that the other party is using for the receive.
But in general, as I said, there are races that can be detected and ones that cannot. I am simply concerned about going out of our way to allow something that clearly is a race.
-----Original Message-----
From: Ugo Corda [mailto:]
Sent: Friday, September 10, 2004 12:07 PM
To: Satish Thatte;
Cc: wsbpeltc
Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote
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:]
> Sent: Friday, September 10, 2004 11:55 AM
> To: ; 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:]
> 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:]
> > > Sent: Tuesday, August 31, 2004 10:15 AM
> > > To: Ugo Corda;
> > > 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:]
> > > Sent: Tuesday, August 31, 2004 10:10 AM
> > > To: Satish Thatte;
> > > 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:]
> > > > Sent: Tuesday, August 31, 2004 9:40 AM
> > > > To: Ugo Corda;
> > > > 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:]
> > > > Sent: Tuesday, August 31, 2004 9:31 AM
> > > > To: Satish Thatte;
> > > > 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:]
> > > > > Sent: Monday, August 30, 2004 10:47 PM
> > > > > To: Ugo Corda;
> > > > > 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:]
> > > > > Sent: Friday, August 27, 2004 8:04 PM
> > > > > To:
> > > > > 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:]
> > > > > > 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.
