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

["Ben Bloch" <ben_b54@hotmail.com>]

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
>
>