[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
Paco, This is a rationale that I can understand and, possibly, accept. The rationale presented previously, based on racing conditions, did not make any sense to me. Ugo > -----Original Message----- > From: Francisco Curbera [mailto:curbera@us.ibm.com] > Sent: Tuesday, September 14, 2004 1:29 PM > To: Ugo Corda > Cc: wsbpeltc; ygoland@bea.com > Subject: RE: [wsbpel] Issue 81 - Rough draft of proposal for vote > > > > > > > Ugo, > > That is precisely what strikes me as broken. You agree that > even though you would encode a <flow> it would necessarily > execute as a <sequence> because otherwise the whole thing > makes no sense. The behavior would be consistent with the > current spec; you just want to allow an alternative (and rather > misleading) syntax for it. I am not sure I get what is the > value of that. > > Paco > > > > > > > "Ugo Corda" > > > <UCorda@SeeBeyond To: > Francisco Curbera/Watson/IBM@IBMUS, <ygoland@bea.com> > > .com> cc: > "wsbpeltc" <wsbpel@lists.oasis-open.org> > > Subject: RE: > [wsbpel] Issue 81 - Rough draft of proposal for vote > > 09/14/2004 04:15 > > > PM > > > > > > > > > > A distinction needs to be made between the time a message is > sent and the time the corresponding receive is active, since > nothing guarantees that the two times are identical. > > In both examples below, a message can be sent to the second > receive at any time (even before the first receive is > activated). The real issue is when the corresponding receive > is active and ready to receive the message. > > In the sequence case, evidently the second receive gets > activated only after the first receive is activated. > > But in the flow case, the situation is identical. The second > receive can only be activated after the first receive gets > activated, since without the first receive there is no > process instance to speak of. > > So what is the difference in time relationship between the > first and second receive in the two examples? None that I can see. > > Ugo > > > -----Original Message----- > > From: Francisco Curbera [mailto:curbera@us.ibm.com] > > Sent: Tuesday, September 14, 2004 12:44 PM > > To: ygoland@bea.com > > Cc: wsbpeltc > > Subject: Re: [wsbpel] Issue 81 - Rough draft of proposal for vote > > > > > > > > > > > > > > I agree there are going to be lots of race conditions > regardless of > > the resolution of this issue. What strikes me is not just the race > > condition but how fundamental it is in this case. The > second of your > > examples clearly states that the process will first be instantiated > > and then be presented with a second message. This fits in > the current > > model how processes work: they are instantiated, then > messages can be > > routed to them. The first example, however, establishes the > > legality of the reverse sequence of > > events: first a message is directed at a process instance, > > then a second message creates the process instance. Our > > engines we can certainly make this work, but it seems very > > much at odds with the current notion of process instantiation > > and message routing. > > > > Paco > > > > > > > > > > > > > > "Yaron Y. Goland" > > > > > > <ygoland@bea.com> To: > > Satish Thatte <satisht@microsoft.com> > > > > cc: Ugo > > Corda <UCorda@SeeBeyond.com>, wsbpeltc <wsbpel@lists.oasis-open.org> > > 09/14/2004 01:07 Subject: Re: > > [wsbpel] Issue 81 - Rough draft of proposal for vote > > > > PM > > > > > > Please respond to > > > > > > ygoland > > > > > > > > > > > > > > > > > > > > Actually I read the thread throughly and I explicitly remember the > > paragraph you refer to. Unfortunately I still do not > understand what > > point you are trying to make. > > > > Race conditions exist all over the place and I see no difference > > between the race condition in my first and second example > even though > > you have argued (if I understand your argument correctly) that the > > first should be illegal while the second is fine. > > > > I still do not understand your logic. > > > > Yaron > > > > Satish Thatte wrote: > > > > > > > > Yaron, > > > > > > You probably did not have time to read the thread > thoroughly. For > > > instance, I wrote below: > > > > > > > > > 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. I agree that all races > > cannot be > > > eliminated, although the one you showed can in fact be > > detected. I am > > > not asking for static analysis to eliminate all races > > pessimistically. > > > I am simply asking why we should clarify something in a way that > > > almost perversely creates a race. Nothing very profound (sorry to > > > disappoint you :-)). > > > > > > Satish > > > > > > *From:* Yaron Y. Goland [mailto:ygoland@bea.com] > > > *Sent:* Mon 9/13/2004 2:44 PM > > > *To:* Ugo Corda > > > *Cc:* Satish Thatte; wsbpeltc > > > *Subject:* Re: [wsbpel] Issue 81 - Rough draft of > proposal for vote > > > > > > I must admit that I don't understand the point that Satish > > is making. > > > I believe he is arguing that we shouldn't allow for > situations that > > > could contain race conditions but just about all messaging > > situations > > > can potentially enable race conditions. > > > > > > I've tried to boil the situation down as far as I can. > > Below I provide > > > two examples that are different only in that one has a flow and > > > another has a sequence. In so far as I'm concerned these > > two scenarios > > > are absolutely identical in terms of their ability to cause race > > > conditions and therefore there is no need to distinguish > > between them. > > > I believe that Satish disagrees but I don't understand why. > > Hopefully > > > he can use these two very specific examples to explain > himself in a > > > manner that even my intellect can grasp. > > > > > > scope > > > flow > > > receive ... createInstance="yes" > > > correlations > > > correlation set="foo" initiate="yes" > > > receive ... createInstance="no" > > > correlations > > > correlation set="foo" initiate="no" > > > > > > and > > > > > > scope > > > sequence > > > receive ... createInstance="yes" > > > correlations > > > correlation set="foo" initiate="yes" > > > receive ... createInstance="no" > > > correlations > > > correlation set="foo" initiate="no" > > > > > > > > > Thanks, > > > > > > Yaron > > > > > > > > > Ugo Corda wrote: > > > > > > > > > > > > > > > Actually a correlation set is far from being a GUID. A GUID is > > > unique > and it implies that the initiator generates it and any > > > follower would > only know it after receiving it from the > > initiator. > > > But correlation > > sets > > > > are just business data (e.g. customer ID) which all > the parties > > > might > very well know since the beginning. That is what > does not > > > prevent a > sender, in my mind, from sending a message to > > the receive > > > at the same > time as the invoke is launched. > > > > > Section 10.1 implies temporal sequence for what concerns > > activities > > > > invocation, but it does not say anything, as far as I > > can see, about > > > > timing of message sending. > > > > > > > > And as far as timing of activity invocation is > > concerned, in the flow > > > > case with two receives, the start receive is necessarily > > activated > > first > > > > (without that activation, the second receive does not > > even exist), > > > and > it is only after that activation (and related > setting of the > > correlation > > > > set) that the non-start receive is activated. So, again, > > not that > > > > different than the invoke/receive sequence. > > > > > Ugo > > > > > > > > > -----Original Message----- > > > > > From: Satish Thatte [mailto:satisht@microsoft.com] > > > > > Sent: Friday, September 10, 2004 4:07 PM > > > > > To: Ugo Corda; ygoland@bea.com > > > > > Cc: wsbpeltc > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > . > > > > > > 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]