Flow and Web Services - Link Semantics
(Page 4 of 5 )
Let's look at how links and conditions are defined to support a flow's behavior:
A link between two activities prescribes their execution order: A link's target activity can only be executed if the source activity has completed.
A link can have an associated transition condition. The transition condition is specified as a Boolean-valued XPath expression based on the process instance's state, such as the state of its variables. It determines whether a link evaluates to true or false, and thus whether a link is followed during runtime. If a transition condition isn't specified, the link is defined to be true and therefore is always followed.
An activity can be the source of multiple links, thus allowing for multiple branches that can be executed in parallel. Such an activity acts as a fork activity.
An activity can also be the target of multiple links. Such an activity establishes a point of synchronization, because it becomes eligible for execution only when all incoming links have been evaluated. It acts as a join activity. In addition, this activity may have a join condition specified. The join condition is a Boolean-valued XPath expression that is based on the process instance's state, including the state of the activity's incoming links. An activity is executed only if its join condition evaluates to true. Omitting the specification of an activity's join condition means at least one incoming link has to be true.
Activities of a flow without incoming links are started as soon as their flow is activated. They run in parallel.
Figure 12.5 Graphical outline of sample flow activity with its activities and links
Join Failures and Dead Path Elimination
How does a flow continue if the join condition of an activity fails (evaluates to false) and the activity is not to be executed? BPEL provides two answers to this question. By specifying the attribute suppressJoinFailure, you can select the behavior you want to be applied to your process and its activities.
By default, a join condition failure results in throwing a BPEL standard fault called joinFailure followed by common BPEL fault processing.
Alternatively, the BPEL standard fault joinFailure can be suppressed by setting the attribute suppressJoinFailure to "yes," and dead path elimination will be performed instead. If the join condition fails, the corresponding activity is skipped, and all the activity's outgoing links are set to false (their transition conditions are ignored). From then on, navigation processing continues as usual: The target activities of the outgoing links are tested to see whether they can be executed or whether they are to be skipped as well, depending on their specifications, and so on.
The attribute suppressJoinFailure can be specified globally at the process level and overridden selectively at the activity level.
Next: Putting Together the Flow Sample >>
More Web Services Articles
More By Sams Publishing
|
 This article is excerpted from chapter 12 of Building Web Services with Java: Making sense of XML, SOAP, WSDL, and UDDI, written by Steve Graham et al. (Sams; ISBN: 0672326418). Check it out today at your favorite bookstore. Buy this book now.
|
|
