> In your example, there is no race if the invoke is initiating
> the correlation that the other party is using for the receive.
Same with the two initial receive's within a flow. The start receive initiates the correlation and the non-start receive can use that correlation.
Ugo
> -----Original Message-----
> From: Satish Thatte [mailto:]
> Sent: Friday, September 10, 2004 2:02 PM
> To: Ugo Corda;
> Cc: wsbpeltc
> Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote
>
>
> 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/le
ave_workgroup.php.
