[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. 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:satisht@microsoft.com] > Sent: Friday, September 10, 2004 2:02 PM > To: Ugo Corda; ygoland@bea.com > 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: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/le ave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]