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 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:UCorda@SeeBeyond.com] 
Sent: Friday, September 10, 2004 12:07 PM
To: Satish Thatte; ygoland@bea.com
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: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.



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