RE: [wsbpel] Issue 81 - Rough draft of proposal for vote

["Ugo Corda" <UCorda@SeeBeyond.com>]

It would probably be easier if you could explain why those activities
should be banned. What kind of problems do you think they would create?

Ugo

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com] 
> Sent: Monday, August 30, 2004 10:47 PM
> To: Ugo Corda; ygoland@bea.com
> Cc: wsbpeltc
> Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote
> 
> 
> Help me understand why we should allow initial non-start 
> activities? Why not ban those?
> 
>  
> -----Original Message-----
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com] 
> Sent: Friday, August 27, 2004 8:04 PM
> To: ygoland@bea.com
> Cc: wsbpeltc
> 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
> > > 
> > 
> 
> 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/le
ave_workgr
oup.php.