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


The assumption underlying the correlation mechanism is that it is like a "header" with a "correlation GUID" similar to a session ID.  Thus the correlation tokens are created by some one party in the correlated conversations.  In particular by the party that has a send with initiate=true.  The "initiator" of the correlation.  The others are called "followers".  See section 10.1.

-----Original Message-----
From: Ugo Corda [mailto:UCorda@SeeBeyond.com] 
Sent: Friday, September 10, 2004 3:57 PM
To: Satish Thatte; ygoland@bea.com
Cc: wsbpeltc
Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote

Sorry, I still do not see the difference. I think you are using a different set of assumptions than I do. In particular, I don't understand your statement below: "the invoke must complete all the way to its target before the message corresponding to the receive can even be sent, since the correlation tokens must be copied into it". What prevents a sender from sending a message to the receive, with the same correlation set as defined by the invoke, before the invoke itself completes, or even at the same exact time that the invoke initiates? Couldn't that message be lost in that case too?

Ugo

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com] 
> Sent: Friday, September 10, 2004 2:48 PM
> To: Ugo Corda; ygoland@bea.com
> Cc: wsbpeltc
> Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote
> 
> 
> The difference is that the message which instantiates the 
> instance and initiates the correlation arrives simultaneously 
> with the non-start one which is dependent on the correlation. 
>  Note that the start message is not dependent on the 
> correlation hence will not be lost regardless of how slow 
> instantiation is.  The non-start message may be lost.
> 
> This is distinct from the example below where the correlation 
> initiation is always before the dependent activity, and in 
> fact the invoke must complete all the way to its target 
> before the message corresponding to the receive can even be 
> sent, since the correlation tokens must be copied into it.
> 
> I repeat.  There are races that can be detected and ones that 
> cannot.  Your example is not a race.  Non-start receives that 
> depend on correlation initiated by a start receive do create 
> a race.  I am concerned about going out of our way to allow 
> something that clearly is a race.
> 
> -----Original Message-----
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com] 
> Sent: Friday, September 10, 2004 2:12 PM
> To: Satish Thatte; ygoland@bea.com
> Cc: wsbpeltc
> Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote
> 
> > In your example, there is no race if the invoke is initiating
> > the correlation that the other party is using for the receive.
> 
> Same with the two initial receive's within a flow. The start 
> receive initiates the correlation and the non-start receive 
> can use that correlation.
> 
> Ugo
> 
> > -----Original Message-----
> > From: Satish Thatte [mailto:satisht@microsoft.com]
> > Sent: Friday, September 10, 2004 2:02 PM
> > To: Ugo Corda; ygoland@bea.com
> > Cc: wsbpeltc
> > Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote
> > 
> > 
> > In your example, there is no race if the invoke is initiating
> > the correlation that the other party is using for the receive.
> > 
> > But in general, as I said, there are races that can be
> > detected and ones that cannot.  I am simply concerned about 
> > going out of our way to allow something that clearly is a race.
> > 
> > -----Original Message-----
> > From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> > Sent: Friday, September 10, 2004 12:07 PM
> > To: Satish Thatte; ygoland@bea.com
> > Cc: wsbpeltc
> > Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote
> > 
> > The following is also statically detectable:
> > 
> > sequence
> > 	invoke
> > 	receive
> > sequence
> > 
> > Depending on the time spent executing the invoke, the receive
> > message might be lost. So are we going to disallow that type 
> > of sequence too?
> > 
> > Ugo
> > 
> > > -----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.
> > > > 
> > > 
> > 
> > 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_workgroup.php.
> 
> 


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