Re: [ebxml-bp] [Àüüȸ½Å] Re: [ebxml-bp] fork/join

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

conch@etri.re.kr wrote:

> All
>
> +1 for the repeat execution.
>
> As far as i know, other than the looping current version of BPSS is 
> capable of handling decision, pararell, join and select using 
> fork/join/decision states and condition expression, no?
>
> and monica thanks for the clarification. My question was related to 
> BPSS fork/join, my bad i forgot to mention the drawing was an attempt 
> to outline the
>
> semantics of BPSS fork/join. anyways is that true that decision state 
> can be used to for more than one outgoing transition? Does that imply 
> you can have like
>
> 3 different outgoing transitions to different busienss transactions 
> with different condition expressions?
>
> regards
>
> David Choi
>
mm1: David,
Here is what the BPSS indicates about Decisions [1]: <<[8] A 
BusinessActivity may have any number of incoming transition but only one 
output transition. Either a Fork or Decision business states must be 
used to logically specify more than one outgouing transition.>>

The example in the specification appears to indicate the answer to your 
question is that it is possible, but as indicated often, even if 
different transitions are specified, they may not be used (i.e. Cancel 
and Change Purchase Order may only be used infrequently).

I encourage JJ to answer more fully as he was the author of the Decision 
detail. Thanks.

[1] See Decision, section 6.1.11 where the specification indicates that 
for this element outgoing transition are by definition mutually 
exclusive. Also see quote above from section 5.18, page 57 of v1.1.

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