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






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/leave_workgroup.php
.





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