[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
Yes except in the latter case we have some expectation of a protocol to make sure messages don't arrive too early. In the initial non-start receive this is explicitly impossible. I am just saying that we can interpret this at a technical level but I wonder if it is really meaningful. Not a huge deal but my preference is to tighten the features so we can justify their usage. -----Original Message----- From: Ugo Corda [mailto:UCorda@SeeBeyond.com] Sent: Tuesday, August 31, 2004 10:10 AM To: Satish Thatte; ygoland@bea.com Cc: wsbpeltc 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. 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]