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