Re: [ebxml-bp] fork/join

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

Monica,

I would disagree - I think this is potentially a path we do NOT want to
go down - I was much more impressed with the suggestion from Hong Kong
that there are in fact highlevel - big blocks - and these are what we
need to use - I believe this is the ghist of JJ's reply too - that its NOT
flowchart programming - but process modelling - that we are doing,
so great care is needed in what devices are included and why:

I like this block set:
>- Decision (if structure)
>- Parallel execution
>- Select execution
>- Join execution
>- Repeat execution (loop structure)

Just as an aside - I worked on a school project with my kids over the
holidays - programming with the Lego MindStorm robotic software
tools.  They have done an amazing job in making event driven
interrupt control programming as simple as arranging coloured boxes
into a flowset - and setting parameters - that a 12 year old can do
(no snyde comments about my abilities either please!).

We could do a lot worse than adopt a similar model too - it
certainly closely models the block set above.

I think there is a huge lesson learned here for us - and a need to
realize what BPSS brings as a solution set - and it is not BPEL
style programming constructs and things like AND-fork - which
clearly is NOT what I'd expect a business process designer
person to have any inkling of the resulting behaviour.

Thanks, DW.

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