Re: [ebxml-bp] fork/join

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Jean-Jacques Dubray wrote:

> 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
>
mm1: JJ, Keith and others, thanks for answering David C's questions.  
Dave, you may be mixing some terms/concepts between BPSS and BPEL. What 
David Choi has outlined appears to map to what could be expressed in 
BPSS and JJ outlined.  Note from Section 5.12.6.1 [1], that the 
different states and transactions within business activities.  I would 
encourage other team members to engage in the conversation, as this 
drawing from David Choi appears to map to BPSS.  In fact, the example 
given in the specification is the case Choi questions. Decisions or 
forks are used for more than one outgoing transition. [2]

<<There are a number of auxiliary kinds of Business States that 
facilitate the choreographing of Business Activities. These include a 
Start state,
a Completion state (which comes in a Success and Failure flavor), a Fork 
state, a Join state and a Decision state. These are all equivalent
to diagramming artifacts on a UML activity diagram, however, the 
semantics are not exactly the same. An XOR value in the type
attribute of a fork means that only one Business State of the fork will 
be allowed to be reached. All the other will become invalid as soon as
one of the business state is reached (e.g. a Business Transaction 
Activity starts). An OR value will mean that any business activity
pointed to by a transition coming from the fork might be initiated. 
These business activities may occur in parallel. Note that it is not
important to specify the order in which condition expression on a 
transition coming from a fork will be evaluated. It is merely the order in
which the request of the business transaction activities will arrive 
that will determine the order in which the condition expression need to be
evaluated. A fork has a timeToPerform attribute.>>

[1] v 1.1
[2] Section 5.18

Thanks.