----- Original Message -----
Sent: Tuesday, January 06, 2004 5:53
PM
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