OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

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