Re: [ebxml-bp] fork/join

["David RR Webber" <david@drrw.info>]

Title: fork/join

Keith,

 

OK - makes sense.  I think we will all be in a better

position to do more on this after Jean-Jacques presentation

on Monday.

 

Thanks, DW

----- Original Message -----

From: Keith Swenson

To: David RR Webber ; Keith Swenson ; conch@etri.re.kr ; ebxml-bp@lists.oasis-open.org

Sent: Tuesday, January 13, 2004 1:25 AM

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

I am not always happy with the actual words chosen.   Anyone can come up with better terms .... just like anyone can come up with better 'standards'     :-)

 

But let's do what you say: formulate a glossary starting from one that exists.  If the terms are too geeky, then let's at least make a mapping from new terms back to the old ones.

 

-Keith

-----Original Message-----
From: David RR Webber [mailto:david@drrw.info]
Sent: Monday, January 05, 2004 9:21 PM
To: Keith Swenson; conch@etri.re.kr; ebxml-bp@lists.oasis-open.org
Subject: Re: [ebxml-bp] fork/join

Keith,

 

I'll have to digest this some more.  That is definately not at all clear - yet!

 

The use of AND and OR instead of MULTIPLE and SINGLE - which seem

to read much better.  Also AND and OR can be confused with logically

AND and OR which have very different outcome sets.

 

I'll also have to review what the BPEL folks have done - since better to

have a common term set here.

 

It definately makes sense to come up with a term glossary - maybe we

take the WfMC ones and upgrade them to match what we're

needing here... I definately prefer the use of common English than

GEEK-speak whereever possible - that way the times people actually

have to refer to the glossary should be minimal - instead of using the

glossary as a crutch...

 

Thanks, DW

----- Original Message -----

From: Keith Swenson

To: 'David RR Webber' ; conch@etri.re.kr ; ebxml-bp@lists.oasis-open.org

Sent: Monday, January 05, 2004 4: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)  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

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