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


I imagine that would be not different than the case of a non-initial
receive to which a message is sent before the receive itself is
activated. It would be up to the implementation to decide whether to
cache the message or drop it.

Ugo

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com] 
> Sent: Tuesday, August 31, 2004 9:40 AM
> To: Ugo Corda; ygoland@bea.com
> Cc: wsbpeltc
> Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote
> 
> 
> Suppose such an activity is a receive.  How would the message 
> be correlated to the instance without danger of being lost if 
> it arrived "too soon"?
> 
>  
> -----Original Message-----
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com] 
> Sent: Tuesday, August 31, 2004 9:31 AM
> To: Satish Thatte; ygoland@bea.com
> Cc: wsbpeltc
> Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote
> 
> 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.
> 
> 
> 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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]