[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 81 - Proposal For Vote
D'oh! Thanks for the catch. I don't think it's worth fixing until we see Maciej's proposed language. I suspect that his language may allow us to potentially even do away with the term initial activity all together. Yaron Satish Thatte wrote: > > > It does not make sense to define initial activities to be only > receive/pick as the definition below does. I presume that the intent of > saying > > " not all initial activities are required to be start activities. > Initial > activities, start or otherwise, simultaneously become active when a > process instance begins execution" > > includes allowing an invoke as an initial activity. I don't like this > but at least we should have consistency :-) > > -----Original Message----- > From: Yaron Y. Goland [mailto:ygoland@bea.com] > Sent: Monday, September 27, 2004 11:18 AM > To: wsbpeltc > Subject: [wsbpel] Issue - 81 - Proposal For Vote > > This proposal is amended so that it requires that all initial > activities, start or otherwise, begin execution simultaneously. > > Section 6.5 > > 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. > > Change: If exactly one start activity is expected to instantiate the > process, the use of correlation sets is unconstrained. > > To: If a process contains exactly one start activity then the use of > correlation sets is unconstrained. > > 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. Initial > activities, start or otherwise, simultaneously become active when a > process instance begins execution. > > 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 and the pattern for all > the correlation sets MUST be sent to "rendezvous" (see Correlation). > > 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/leave_workgr > oup.php. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]