RE: [ebxml-bp] fork/join

[Keith Swenson <KSwenson@fsw.fujitsu.com>]

Title: RE: [ebxml-bp] fork/join

The main point I am trying to make is that I want someone to write down a textual definition of the term, and then use them consistently in discussions about the standards.  I gave four examples.  I have no particular reverence for these terms other that the fact that someone actually wrote down the definitions in a glossary.  If we conclude that we really are speaking of a new concept, then by all means, invent a new term, but use it only after it is included in a glossary.

 

That being said, I am not at all convinced that you actually have a different concept.  I realize the the definitions are in terms of "execution", but as such execution can include "waiting for an event" which I believe is the same thing as "observed".  (You speak of paths being 'disabled' which implies to me they were enabled at some time, and therefor essentially the same as executing a 'wait for event' activity.) From your examples:

(a) is an AND-Join (I would instead say all paths must be waited for)

(c) is a OR-Join which as you point out is not really a join in any real sense.  It probably should have been called XOR, but I use OR because that is the one that is defined. 

(b) admittedly I do not have a defined term to describe.  Different people have different tastes in modelling, but I would model the timeout simply as another path.  Waiting for an event (or a message) is much the same as waiting for a point in time.  The Join condition needs to be a complex one that treats the timeout path specially (it overrides the other paths in some ways.)  This may not be the best way to model it.  Different process engines have implemented the time-out case differently -- which is not a good thing, only a fact of life.

 

By "fork" do you mean the concept of the collection of paths that extend from a split to a join?  Is it the case that (a) is really an AND-split followed eventually by an AND-Join?  Is (c) really an AND-split followed eventually by an OR-Join such that the first path wins and the others are disabled?

 

-Keith

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jeanjadu@attachmate.com]
Sent: Tuesday, January 06, 2004 2:53 PM
To: 'Keith Swenson '; ''David RR Webber' '; 'conch@etri.re.kr '; 'ebxml-bp@lists.oasis-open.org '
Subject: RE: [ebxml-bp] fork/join

I am missing the context of the discussion so excuse me if this is off topic.

Keith, unfortunately, we DO have to invent something because the WfMC talks about "executed" business processes and not collaboration. A collaboration is not "executed" per say but rather "observed". This little known fact has drastic consequences on the notion of Fork/Join.

In a collaboration a fork indicate that:
a) all subsequent paths MUST be taken (== AND-Join)
b) some must be taken (then a timeout has to occur as there can be no rule about when the join happens)
c) XOR = one only one can happen, once it happens, all the other ones are disabled (No real join happens here)

The fork for a) and b) is specified with XOR=false. What distinguishes a) and b) is: a) AND-join, b) timeout on the fork

The fork in case c) is specified with XOR=true.

Cheers,

Jean-Jacques

-----Original Message-----
From: Keith Swenson
To: 'David RR Webber'; conch@etri.re.kr; ebxml-bp@lists.oasis-open.org
Sent: 1/5/04 1:31 PM
Subject: RE: [ebxml-bp] fork/join

Here are terms used by WfMC for these concepts.  These are well defined
in a ratified standard glossary. (
http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf
<http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf> )
These may seem cumbersome, but experience has shown that they are clear.
Unless another standard exists that I don't know about, in order to
promote discussion, I recommend we use these terms:

AND-Split: A point within the business process where a single thread of
control splits into two or more threads which are executed in parallel
within the business process, allowing multiple activities to be executed
simultaneously (see Parallel Routing).

OR-Split: A point within the business process where a single thread of
control makes a decision upon which branch to take when encountered with
multiple alternative business process branches

AND-Join: A point in the business process where two or more parallel
executing activities converge into a single common thread of control
(see Parallel Routing). Synchronization is needed.

OR-Join: A point within the business process where two or more
alternative business process branches re-converge to a single common
activity as the next step within the workflow. (As no parallel activity
execution has occurred at the join point, no synchronisation is
required.)

So, the 'switch' and the 'fork' are both OR-Splits.  Definately don't
want to re-invent something!

-Keith Swenson

-----Original Message-----
From: David RR Webber [mailto:david@drrw.info]
Sent: Monday, December 29, 2003 8:52 AM
To: conch@etri.re.kr; ebxml-bp@lists.oasis-open.org
Subject: Re: [ebxml-bp] fork/join

David,
 
For a moment there you had me concerned!  I guess we need to all agree
on what
each of these terms means - fork to me means something totally
different.
 
What you are calling fork - I call 'switch' and then processing picks a
path based
on context (see BPEL example attached) - where the switch is a
side-branch -
relative to the flow diagram you have - so its very clear that
processing is
still occuring within the overall flow.
 
Whereas Fork to me means - terminate here and invoke an external process

non-contiguously, (like someone taking a fork in a road).
 
Join is not really needed for 'switch', when you have an implied 'end
switch'.
But Join may be needed to jump across to some other path - from the
current
path - this is the equivalent to a classic "goto #anchor", and you then
need to
ensure deterministic outcomes - such as using "terminate()" or
"return()".
 
We could be in danger here of re-inventing programming 101 of course!!!
 
DW.

----- Original Message -----
From: conch@etri.re.kr <mailto:conch@etri.re.kr> 
To: ebxml-bp@lists.oasis-open.org <mailto:ebxml-bp@lists.oasis-open.org>

Sent: Sunday, December 28, 2003 9:49 PM
Subject: [ebxml-bp] fork/join

All,

Please see the attached documents for fork/join activity diagram and
some questions.

regards /

David Choi