[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
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. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]