RE: [wsbpel] One more Topic for the "Review input from TC members" session of the F2FSome

["Satish Thatte" <satisht@microsoft.com>]

Ben,

The fact of concurrent behavior of autonomous processes especially given
that communication among them does not involve a "speaker queue"
certainly makes for interesting modeling problems for public behavior.
I believe thinking through the implications is certainly in scope.  A
very simple example of such races is in the BA protocol in
WS-Transaction.

Satish

-----Original Message-----
From: Ben Bloch [mailto:ben_b54@hotmail.com] 
Sent: Sunday, May 25, 2003 2:10 PM
To: Satish Thatte; Marin, Mike; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] One more Topic for the "Review input from TC
members" session of the F2FSome

Shared data and "serializable scopes" may be the solution or, more
likely,
part of it, but I just wanted to make sure this use case was in scope
and,
if so, is considered as part of the spec design.

Ben
----- Original Message ----- 
From: "Satish Thatte" <satisht@microsoft.com>
To: "Ben Bloch" <ben_b54@hotmail.com>; "Marin, Mike"
<MMarin@filenet.com>;
<wsbpel@lists.oasis-open.org>
Sent: Friday, May 23, 2003 8:45 PM
Subject: RE: [wsbpel] One more Topic for the "Review input from TC
members"
session of the F2FSome


The current BPEL model is shared data.  This is the motivation for
"serializable scopes" (see section 13.6).

Satish

-----Original Message-----
From: Ben Bloch [mailto:ben_b54@hotmail.com]
Sent: Friday, May 23, 2003 1:56 PM
To: Marin, Mike; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] One more Topic for the "Review input from TC
members" session of the F2FSome

If I understand you correctly, Mike, I concur -  these race conditions
are a
critical issue. I was, in fact, going to pose as a use case precisely or
at
least partially what you refer to here.  That is, the use case of
asynchronous but interdependent work flows.

This really needs a state transition diagram, but here is example:

n asynchronous workflows - let's say 2: A,B
m processses - let's say 3: X,Y,Z

Workflow A makes state changes (eg a price change) to X,Y,Z
Workflow B is started by X, which, based on its state, sends a message
to Y
which changes its state, which in turn, based on its state, generates
message
for Z which changes its state.

A race condition occurs when, for example, A changes X but not yet Y and
Z
while X, assuming Y is in a synchronized state vis a vis worklow A, has
already sent message to Y.

As service-oriented architectures and composite applications become
increasingly common, such multithreaded race conditions, including those
previously handled previously in proc, will need to be handled by some
coordinating process, presumably a workflow or similar system.

Is such a use case included as a WSBPEL goal?  I would advocate it
should
be, since this is an example from the real world of business processes.

Ben

----- Original Message ----- 
From: "Marin, Mike" <MMarin@filenet.com>
To: <wsbpel@lists.oasis-open.org>
Sent: Friday, May 23, 2003 1:44 PM
Subject: [wsbpel] One more Topic for the "Review input from TC members"
session of the F2FSome


>
> The description of the underlying data model for the executable
process
> seems to be missing from the specification. The two commonly
implemented
> data models in BPM and workflow systems, includes what I will call
> shared data and path data.
>
> In the shared data model, all parallel activities share the data and
so
> you have race conditions and last one win situations. In the path data
> model, each parallel path of activities has a copy of the data. In
this
> case, you have problems with stall data and deciding how to merge the
> data together when the parallel paths meet. So, both models have some
> problems and benefits, and so, different products use different models
> and or variations.
> In the case of BPE, I have not been able to ascertain the type of
> underling model being use. So, I think that we need to clearly state
the
> underling data model in the specification.
>
> For example, let assume the following pseudo-BPEL,
>
> Assume variables R, X, Y, Z are all in this scope, then
> Sequence
> {
>     Flow
>     {
>         Sequence
>         {
>               Receive into variable R  // read value "a"
>               Wait (randomly between zero and two hours)
>               Assign X with R
>          }
>         Sequence
>         {
>               Receive into variable R // read value "b"
>               Wait (randomly between zero and two hours)
>               Assign Y with R
>          }
>     }
>     Assign Z with R
> }
>
> In this example the two receive are executed in parallel (let assume
> they implement two operations that can be called at the same time, and
> both will be called in an arbitrary order). Note that having the two
> receive does not break any of the BPEL rules, because they are not
> conflicting receive (they are in a different partner link, port type,
> operation, and correlation set). Let further assume the receive are
> executed within seconds one from the other.
>
> The question is, what is the resulting value in X, Y, and Z. Do the
> values depend on which receive is triggered first? Or in which
sequence
> finish first?
>
> The results may be either
> 1- (X=a, Y=a, Z=a) or (X=b, Y=b, Z=b) for shared data;
> 2- (X=a, Y=b, Z=a) or - (X=a, Y=b, Z=b) for path data.
> 3- any other permutation...
>
> --
> Regards,
> Mike Marin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org