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