Re: [wsbpel] Issue 81 - Proposal For Vote

["Yaron Y. Goland" <ygoland@bea.com>]

+1 (assuming the group decides they don't want initial activity to be 
non-start activities, otherwise -1 :)

Alex Yiu wrote:
> Hi, Yaron,
> 
> After doing the HW on this particular proposal, I guess we may need to add some 
> more wordings to avoid ambiguity.
> 
> Consider this example:
> <flow>
>     <receive ... createInstance="yes" />
>     <assign ... />
> </flow>
> 
> The summary of the issue said : "Explicitly require that initial activities be 
> start activities."
> 
> However, the only relevant text in the proposal that I found is:
> 
>     *To: *
>     A receive/pick activity annotated in this way MUST be a "start activity". A
>     "start activity" is a receive/pick activity that is marked with a
>     createInstance="yes" attribute where no other activities but scope, flow,
>     sequence or empty activities occur before it in the execution path rooted at
>     the process element.
> 
> 
> Technically, the <assign> is NOT before the <receive> in either activity 
> ancestor chain sense or document ordering sense. The term "execution path" may 
> be a bit not-so-well-defined also. Hence, I would like to make the text clearer 
> (by mixing in some of old text) as follows:
> 
>     From:
>     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 (Version-2):
>     A "start activity" is a receive/pick activity that is annotated with a
>     createInstance="yes" attribute. NO other "non-start activities" but scope,
>     flow, sequence or empty activities may potentially be performed prior to or
>     simultaneously with a "start activity". The logical order of performing
>     activities is determined by static analysis.  
> 
> 
> It would be nice, if we can actually include some examples like the following to 
> illustrate what we mean in the spec:
> 
> That is making the following *illegal*:
> <flow>
>     <receive ... createInstance="yes" />
>     <assign ... />
> </flow>
> 
> And, making the following *legal*:
> <flow>
>     <links>
>         <link name="RecvToAssign"/>
>     </links>
>     <sequence>
>           <receive ... createInstance="yes">
>                 <sources> <source linkName="RecvToAssign" />  <sources>
>           </receive>
>           ...
>     </sequence>
>     <sequence>
>           <assign>
>                 <targets> <target linkName="RecvToAssign" /> </targets>
>                 ...
>           </assign>
>     </sequence>
> </flow>
>          
> 
> 
> Thanks!
> 
> 
> 
> Regards,
> Alex Yiu
> 
> 
> 
> Yaron Y. Goland wrote:
> 
>> Summary: Explicitly require that initial activities be start activities.
>>
>> 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 a receive/pick activity that is marked with a 
>> createInstance="yes" attribute where no other activities but scope, flow, 
>> sequence or empty activities occur before it in the execution path rooted at 
>> the process element.
>>
>> 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. As specified in
>> section 6.5 the initial start activity must complete execution before
>> any other start activities are allowed to execute.
>>
>> 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_workgroup.php.
>>
>