[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
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]