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






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






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