-----Original Message-----
From: Satish Thatte [mailto:satisht@microsoft.com]
Sent: Friday, September 10, 2004 11:55 AM
To: ygoland@bea.com; Ugo Corda
Cc: wsbpeltc
Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote
I have a sense of déjà vu that I have seen this and replied
to it earlier.
Basically, the answer is that it is possible to make process
protocol mistakes that would cause races that would then risk
losing messages. Not all such races can be statically
detected. However, non-start initial receives (assuming they
are appropriately correlated) are an obviously statically
detectable case, hence there is no reason to allow them.
-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com]
Sent: Friday, September 10, 2004 10:54 AM
To: Ugo Corda
Cc: Satish Thatte; wsbpeltc
Subject: Re: [wsbpel] Issue 81 - Rough draft of proposal for vote
I agree with Ugo. I don't see the difference. What makes it
'explicitly
impossible' to expect that such a message would arrive? In
fact, how is
it any different than a start receive immediately followed by a
non-start receive? The behavior in the BPEL sense would
appear to me to
be identical.
Thanks,
Yaron
Ugo Corda wrote:
> Yes except in the latter case we have some expectation of a >
protocol to make sure messages don't arrive too early.
I cannot see the difference. The activation of a
non-initial receive
is dependent on the completion of the preceding activities in the
sequence, which can be completely run-time dependent. The
activation
of an initial non-start receive is dependent on the
reception of the
initial start receive, which can also be completely run-time
dependent. I don't see how any protocol could do better in one case
than in the other.
Ugo
> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Tuesday, August 31, 2004 10:15 AM
> To: Ugo Corda; ygoland@bea.com
> Cc: wsbpeltc
> 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/le
ave_workgr
oup.php.