Structured activities prescribe the order in which a collection of activities is executed. They describe how a business process is created; by composing the basic activities (see section 10. Basic Activities) it performs into structures that express the control patterns, handling of faults and external events, and coordination of message exchanges between process instances involved in a business protocol.
WS-BPEL defines structured activities for various control-flow patterns:
Sequential control between activities is provided by , , , , and the serial variant of .
Concurrency and synchronization between activities is provided by and the parallel variant of .
Deferred choice controlled by external and internal events is provided by
.
The set of structured activities in WS-BPEL is not intended to be minimal. There are cases where the semantics of one activity can be represented using another activity. For example, sequential processing may be modeled using either the activity, or by a with properly defined links.
Structured activities can be nested and combined in arbitrary ways. This provides a blending of graph-structured and block-structured modeling styles that have traditionally been seen as alternatives rather than orthogonal composable features. A simple example of such blended usage is found in section 5.1. Initial Example.
The word activity is used throughout the following to include both basic and structured activities.
11.1. Sequential Processing – Sequence
A activity contains one or more activities that are performed sequentially, in the lexical order in which they appear within the element. The activity completes when the last activity in the sequence has completed.
standard-elements
activity+
Example:
...
...
...
11.2. Conditional Behavior – If
The activity provides conditional behavior. The activity consists of an ordered list of one or more conditional branches defined by the and optional elements, followed by an optional element. The and branches are considered in the order in which they appear. The first branch whose holds true is taken, and its contained activity is performed. If no branch with a condition is taken, then the branch is taken if present. The activity is complete when the contained activity of the selected branch completes, or immediately when no evaluates to true and no branch is specified.
The activity provides for repeated execution of a contained activity. The contained activity is executed as long as the Boolean evaluates to true at the beginning of each iteration.
standard-elements
bool-expr
activity
Example:
$orderDetails > 100
...
11.4. Repetitive Execution – RepeatUntil
The activity provides for repeated execution of a contained activity. The contained activity is executed until the given Boolean becomes true. The condition is tested after each execution of the body of the loop. In contrast to the activity, the loop executes the contained activity at least once.
standard-elements
activity
bool-expr
11.5. Selective Event Processing – Pick
The activity waits for the occurrence of exactly one event from a set of events, then executes the activity associated with that event. After an event has been selected, the other events are no longer accepted by that
. If a race condition occurs between multiple events, the choice of the event is implementation dependent (see the race condition description in section 10.4. Providing Web Service Operations – Receive and Reply ).
The activity is comprised of a set of branches, each containing an event-activity pair. The activity completes when the selected activity completes. The
activity's events come in two forms:
The is similar to a activity, in that it waits for the receipt of an inbound message.
The corresponds to a timer-based alarm. If the specified duration value in is zero or negative, or a specified deadline in has already been reached or passed, then the event is executed immediately. Again, the handling of race conditions is implementation dependent.
Each pick activity MUST include at least one .
A special form of is used when a new instance of a business process is to be created upon the receipt of an event. This form of has a createInstance attribute with a value of yes (the default value of the attribute is no). [SA00062] In such a case, the events in the MUST all be events. This requirement MUST be statically enforced.
[SA00063] The semantics of the event are identical to a activity regarding the optional nature of the variable attribute or elements (see also [SA00047]), the handling of race conditions, the handling of correlation sets, the single element-based part message short cut and the constraint regarding simultaneous enablement of conflicting receive actions. For the last case, if two or more receive actions for the same partnerLink, portType, operation and correlationSet(s) are simultaneously enabled during execution, then the standard fault bpel:conflictingReceive MUST be thrown (see section 10.4. Providing Web Service Operations – Receive and Reply ). Enablement of an event is equivalent to enablement of the corresponding activity for the purposes of this constraint.
The optional messageExchange attribute is used to associate an construct with a activity (for details, see section 10.4.1. Message Exchanges).
standard-elements
portType="QName"?
operation="NCName"
variable="BPELVariableName"?
messageExchange="NCName"?>+
?
+
?
+
activity
*
(
duration-expr
|
deadline-expr
)
activity
The following example shows a typical usage of . The activity occurs in a loop that is accepting line items for a large order An order completion timeout is enabled by the event.
portType="orderEntry"
operation="inputLineItem"
variable="lineItem">
portType="orderEntry"
operation="orderComplete"
variable="completionDetail">
3 days and 10 hours after the last order line -->
'P3DT10H'
11.6. Parallel and Control Dependencies Processing – Flow
The activity provides concurrency and synchronization. The syntax for is:
standard-elements
?
+
activity+
A fundamental semantic effect of grouping a set of activities in a is to enable concurrency. A completes when all of the activities enclosed by the have completed. If its enabling condition evaluates to false then an activity is skipped and also considered completed (see section 11.6.3. Dead-Path-Elimination).
In the following example, the two activities are enabled to start concurrently when the starts. Assuming the operations are request-response operations, the completion of the occurs after both the seller and the shipper respond. The “transferMoney” activity is executed after the completes.
A activity creates a set of concurrent activities directly nested within it. It enables synchronization dependencies between activities that are nested within it to any depth. The construct is used to express these synchronization dependencies. Declaration of 's are enclosed by a activity. [SA00064] A has a mandatory name attribute, which MUST be unique among all name's defined within the same immediately enclosing . This requirement MUST be statically enforced.
11.6.1. Flow-related Standard Attributes and Elements
The standard-attributes and standard-elements for activities nested within a are significant because the standard attributes and elements exist to provide link semantics to the activities. Each WS-BPEL activity has the optional containers and , which contain collections of and elements respectively. These elements are used to establish synchronization relationships through a .
?
?
bool-expr
+
?
+
?
bool-expr
[SA00065] The value of the linkName attribute of the or MUST be the name of a declared in an enclosing activity. [SA00068] An activity can declare itself to be the source of one or more links by including one or more elements. Each element associated with a given activity MUST use a linkName distinct from all other elements of that activity. Similarly, [SA00069] an activity can declare itself to be the target of one or more links by including one or more elements. Each element associated with an activity MUST use a linkName distinct from all other elements of that activity. [SA00067] Two different links MUST NOT share the same source and target activities; that is, at most one link may be used to connect two activities. [SA00066] Every link declared within a activity MUST have exactly one activity within the as its source and exactly one activity within the as its target. The source and target of a link can be nested arbitrarily deeply within structured activities nested in the , except for the boundary-crossing restrictions described below. All of the requirements specified in this paragraph MUST be statically enforced.
The , as a whole, can specify an optional . The value of the element is a Boolean expression in the expression language indicated by the expressionLanguage attribute, or in the default expression language for this process (see section 8.3. Expressions). If no is specified, the is the disjunction (i.e. a logical OR operation) of the link status of all incoming links of this activity.
Each element can specify an optional as a guard for following the specified link. If the is omitted, it is assumed to evaluate to true.
One of the optional standard-attributes on every activity, suppressJoinFailure, is related to links. This attribute indicates whether a join fault (bpel:joinFailure) should be suppressed if it occurs (see section 11.6.3. Dead-Path-Elimination). When the suppressJoinFailure attribute is not specified for an activity, it inherits its value from its closest enclosing construct (i.e. activity or the process itself).
The semantics of , , and suppressJoinFailure are discussed below in section 11.6.2. Link Semantics.
Consider a link whose source is nested inside a syntactic construct, at any level, and the link is not declared inside that construct at any level. We say such a link is leaving that construct. Also consider a link whose target is nested inside a syntactic construct at any level, but the link is not declared inside that construct at any level. We say that such a link is entering that construct. A link which either enters or leaves a construct is said to cross the boundary of the construct. When both the source and target activities for the link are nested within the construct X, while the link is declared outside the construct X, the link is said to both enter and leave the construct.
The following example shows links crossing the boundaries of structured activities. The named CtoD starts at activity C in Y and ends at activity D, which is directly enclosed by the activity. The example further illustrates that X must be performed prior to Y because X is the source of the named XtoY that is targeted at Y. The link XtoY crosses the boundaries of both X and Y.
A link used within a repeatable construct (, , , ) or a MUST be declared in a that is itself nested inside the repeatable construct or . [SA00070] A link MUST NOT cross the boundary of a repeatable construct or the element. [SA00071] A link that crosses a , or element boundary MUST be outbound only, that is, it MUST have its source activity within the or , and its target activity outside of the scope associated with the handler (see section 12. Scopes for the specification of the , , , and ) .
[SA00072] A declared in a MUST NOT create a control cycle, that is, the source activity must not have the target activity as a logically preceding activity. This implies that such directed graphs are always acyclic. Activity A is said to logically precede activity B if the initiation of B semantically requires the completion of A. In particular, a link MUST NOT have an activity as a target if the source activity encloses the target activity or vice versa. These requirements MUST be statically enforced.
To illustrate the above, the following example shows an invalid use of links, because it violates the restriction that a link must not have a target activity enclosed in the source activity:
...
...
11.6.2. Link Semantics
In the rest of this section, the links for which activity A is the source will be referred to as A's outgoing links, and the links for which activity A is the target will be referred to as A's incoming links. If activity X is the target of a link that has activity Y as the source, we say that X has a synchronizationdependency on Y.
Every activity that is the target of a link has an implicit or explicit join condition associated with it. This applies even when an activity has just one incoming link. Explicit join conditions are provided by the element under the element. If the explicit join condition is missing, the implicit condition requires the status of at least one incoming link to be true (see below for an explanation of link status). A join condition is a Boolean expression (see section 8.3.1. Boolean Expressions). [SA00073] The expression for a join condition MUST be constructed using only Boolean operators and the activity's incoming links' status values.
Ignoring links, the semantics of the business processes, , and structured activities determine when a given activity is ready to start. For example, the second activity in a is ready to start as soon as the first activity completes. The activity contained in a branch of an is ready to start when that branch is selected. Similarly, an activity nested directly within a is ready to start when the itself starts.
If an activity that is ready to start in this sense has incoming links, then it MUST NOT start until the status of all its incoming links has been determined and the, implicit or explicit, join condition has been evaluated. In order to avoid violating control dependencies, evaluation of the join condition is performed only after the status of all incoming links has been determined.
The link status is a tri-state flag associated with each declared link. This flag may be in the following three states: true, false, or unset. The lifetime of the status of a is exactly the lifetime of the activity within which it is declared. Each time a activity is activated, the status of all the links declared in that activity is unset.
The semantics of link status evaluation are described in the following paragraphs.
When activity A completes without propagating any fault, the following steps MUST be performed to determine the effect of the links on other activities:
Determine the status of all outgoing links for A. The status will be either true or false. To determine the status for each link its is evaluated. If some of the variables referenced by the are modified in a concurrent path, the result of the transition condition evaluation may depend non-deterministically on the timing of behavior among concurrent activities.
For each activity B that has a synchronization dependency on A, check whether:
B is ready to start (except for its dependency on incoming links) in the sense described above.
The status of all incoming links for B has been determined. Note that if the incoming link is leaving an isolated scope, then the final status of the link cannot be known until the isolated scope has completed (see section 12.8. Isolated Scopes).
If both of the above conditions are true, then evaluate the for B, if it evaluates to true, activity B is started. Otherwise a standard bpel:joinFailure fault MUST be thrown, unless the value of suppressJoinFailure is yes in which case bpel:joinFailure is not thrown (see section 11.6.3. Dead-Path-Elimination).
When an activity has multiple outgoing links, the order in which the status of the links and the associated transition conditions are evaluated is defined to be sequential, according to the order the links are declared in the element.
The associated source activity MUST complete before the of a link is evaluated. In the case of source activities that are themselves 's, successful completion is not required. That is, a may suffer an internal fault and yet complete (unsuccessfully) if there is a corresponding fault handler associated with the and that fault handler completes without throwing a fault. If an error occurs while evaluating the , that error does not affect the completion status of the activity and is handled by the source activity's enclosing scope. If the target of the link is outside the source activity's enclosing scope then the status of the link is false. There is no difference in the status of the link that faults on transition condition evaluation and one whose transition condition has not been evaluated. If the target is within the enclosing scope the status is irrelevant since the scope has faulted (see section 11.6.3. Dead-Path-Elimination below). In the case of a link L with a X as its source activity, a fault resulting from an error in evaluating the transition condition for L would be propagated to the enclosing for X.
If an error occurs while evaluating the transition condition of one of an activity's outgoing links, then all remaining outgoing links with targets within the source activity's enclosing scope MUST NOT have their transition conditions evaluated and remain in the unset state. However, if the target of a remaining outgoing link is outside the source activity's enclosing scope then the status of the link MUST be set to false.
If, during the performance of structured activity A, the semantics of A dictate that activity B nested within A will not be performed as part of the execution of A, then the status of all outgoing links from B MUST be set to false. However, in order to avoid violating control dependencies, this rule MUST only be applied after the status of all of B's incoming links, as well as all incoming links of any activity, upon which B has a control dependency, has been determined. An example of where this rule applies is that of an activity within an activity's branch whose is false. Another example is seen in activities that were not completed because of a faulted (see sections 12. Scopes and 12.4. Compensation Handlers). The rule on control dependencies also holds for links which are outgoing from and 's: If it is determined that one of these handlers will not run, then the status of all outgoing links are set to false.
In the following example, the toSkipped link creates a control dependency from the activity to the activity in the . The fromSkipped link creates a dependency from the activity to the activity. These two links create a transitive dependency from the activity to the activity. Even though the condition evaluates to false, thus skipping the activity, the transitive dependency is retained, and therefore the status of fromSkipped is not set to false until after the status of toSkipped is known.
...
...
The and handlers, as well as parallel activities can have simultaneously active instances. Data and resources declared within the child scopes of these constructs, including links, MUST be processed independently in each instance.
When a activity is nested within another activity, the inner activity may define a with the same name as in the enclosing activity. A source or target reference to such a from an activity matches the innermost visible to the activity.
11.6.3. Dead-Path-Elimination
When the control flow is defined by links and the value of the suppressJoinFailure attribute is yes, the interpretation of a join condition for activity A that evaluates to false is that A MUST NOT be executed. In this case, the fault bpel:joinFailure MUST NOT be generated. The value of this attribute is inherited by all nested activities, except where overridden by another suppressJoinFailure attribute setting.
When a target activity is not performed due to the value of the (implicit or explicit) being false, its outgoing links MUST be assigned a false status according to the rules of section 11.6.2. Link Semantics. This has the effect of propagating false link status transitively along entire paths formed by successive links until a join condition is reached that evaluates to true. This approach is called Dead-Path Elimination (DPE).
The default value of the suppressJoinFailure attribute of the
element is no. This avoids suppressing a well-defined fault by a default setting. Consider the interpretation of the example in section 5.1. Initial Example with the suppressJoinFailure attribute set to yes. Suppose further that the invocations of the shipping provider are enclosed in a scope that provides a fault handler (see sections 12. Scopes and 12.5. Fault Handlers). If one of these invocations were to fault, the status of the outgoing link from the invocation would be false, and the (implicit) at the target of the link would be false, but the resulting bpel:joinFailure would be implicitly suppressed and the target activity would be silently skipped within the sequence instead of causing the expected fault.
If universal suppression of the bpel:joinFailure fault is desired, it can be achieved by setting the suppressJoinFailure attribute to yes in the element.
11.6.4. Flow Graph Example
In the following example, the activities with the names receiveBuyerInformation, receiveSellerInformation, settleTrade, confirmBuyer, and confirmSeller are nodes of a graph defined within a activity.
Figure 2: Flow Graph
The following 's are defined as:
buyToSettle starts at receiveBuyerInformation (specified in the corresponding element nested in receiveBuyerInformation) and ends at settleTrade (specified in the corresponding element nested in settleTrade).
sellToSettle starts at receiveSellerInformation and ends at settleTrade.
toBuyConfirm starts at settleTrade and ends at confirmBuyer.
toSellConfirm starts at settleTrade and ends at confirmSeller.
Based on the graph structure defined by the , the activities receiveBuyerInformation and receiveSellerInformation can run concurrently. The settleTrade activity is performed only after both of these activities are completed. After settleTrade completes the two activities, confirmBuyer and confirmSeller are performed concurrently again.
$buyToSettle and $sellToSettle
11.6.5. Links and Structured Activities
Links can cross the boundaries of structured activities (see section 11.6.1. Flow-related Standard Attributes and Elements). The following example illustrates the behavior when links target activities within structured constructs.
The is intended to perform the sequence of activities A, B, and C. Activity B has a synchronization dependency on the two activities X and Y outside of the sequence. That is, B is a target of links from X and Y. The at B is not specified, and so the disjunction (i.e. a logical OR) of the links targeted to B will be used. The condition is true if at least one of the incoming links has a true status. In this case, that condition reduces to the Boolean condition (P:funcXB() or P:funcYB()).
In the , the named S and the two activities X and Y are all concurrently enabled to start when the starts. Within S, after activity A is completed, B cannot start until the status of its incoming links from X and Y is determined and the implicit join condition is evaluated. When activities X and Y complete, the join condition for B is evaluated.
Suppose that both transition conditions P:funcXB() and P:funcYB() evaluate to false, then the standard fault bpel:joinFailure will be thrown, because the attribute suppressJoinFailure of the enclosing activity is set to no. Thus the behavior of the is interrupted and neither B nor C will be performed.
If the attribute suppressJoinFailure of the enclosing activity is set to yes, then B will be skipped but C will be executed because the bpel:joinFailure will be suppressed.
P:funcXB()
...
P:funcYB()
...
...
Finally, assume that the preceding is slightly rewritten by linking A, B, and C through links (with default elements with constant value of true), instead of putting them into a . Since the default join condition is a disjunction and the of link AtoB is the constant true, the join condition will always evaluate to true, independent from the values of P:funcXB() and P:funcYB(). Now, B and subsequently C will always be executed.
P:funcXB()
P:funcYB()
11.7. Processing Multiple Branches – ForEach
The activity will execute its contained activity exactly N+1 times where N equals the minus the .
standard-attributes>
standard-elements
unsigned-integer-expression
unsigned-integer-expression
?
successfulBranchesOnly="yes|no"?>?
unsigned-integer-expression
...
When the activity is started, the expressions in and are evaluated. Once the two values are returned they remain constant for the lifespan of the activity. [SA00074] Both expressions MUST return a TII (meaning they contain at least one character) that can be validated as a xsd:unsignedInt. If these expressions do not return valid values, a bpel:invalidExpressionValue fault will be thrown (see section 8.3. Expressions). If the is greater than the , then the child activity MUST NOT be performed and the activity is complete.
The child activity of a MUST be a activity. The construct introduces an implicit counter variable, and also introduces dynamic parallelism (i.e. having parallel branches of which number is not known ahead of time). The activity provides a well-defined scope snapshot semantic and a way to name the dynamic parallel work for compensation purposes (see scope snapshot description in section 12.4.2. Process State Usage in Compensation Handlers).
If the value of the parallel attribute is no then the activity is a serial . The enclosed activity MUST be executed N+1 times, each instance starting only after the previous repetition is complete. If premature termination occurs such as due to a fault, or the completion condition evaluates to true, then this N+1 requirement does not apply. During each repetition, a variable of type xsd:unsignedInt is implicitly declared in the activity's child . This implicit variable has the name specified in the counterName attribute. The first iteration of the scope will see the counter variable initialized to the . The next iteration will cause the counter variable to be initialized to the plus one. Each subsequent iteration will increment the previously initialized counter variable value by one until the final iteration where the counter will be set to the . The counter variable is local to the enclosed and although its value can be changed during an iteration, that value will be lost at the end of each iteration. Therefore, the counter variable value will not affect the value of the next iteration's counter.
If the value of the parallel attribute is yes then the activity is a parallel . The enclosed activity MUST be concurrently executed N+1 times. In essence an implicit is dynamically created with N+1 copies of the 's enclosed activity as children. Each copy of the activity will have the same counter variable declared in the same manner as specified for serial . Each instance's counter variable MUST be uniquely initialized in parallel to one of the integer values starting with up to and including , as a part of instantiation.
[SA00076] If a variable of the same name as the value of the counterName attribute is declared explicitly in the enclosed scope, it would be considered a case of duplicate variable declaration and MUST be reported as an error during static analysis.
The activity without a completes when all of its child 's have completed. The element is optionally specified to prevent some of the children from executing (in the serial case), or to force early termination of some of the children (in the parallel case).
The element represents an unsigned-integer expression (see section 8.3.4. Unsigned Integer Expressions) used to define a completion condition of the “at least N out of M” form. The actual value B of the expression is calculated once, at the beginning of the activity. It will not change as the result of the activity's execution. At the end of execution of each directly enclosed activity, the number of completed children is compared to B, the value of the expression. If at least B children have completed, the is triggered: No further children will be started, and currently running children will be terminated (see section 12.6 Termination Handlers). Note that enforcing the semantic of “exactly N out of M” in parallel would involve a race condition, and is therefore not specified.
When the completion condition B is calculated, if its value is larger than the number of directly enclosed activities N+1, then the standard bpel:invalidBranchCondition fault MUST be thrown. [SA00075] Both B and N+1 may be constant expressions, and in such cases, static analysis SHOULD reject processes where it can be detected that B is greater than N+1.
The element has an optional successfulBranchesOnly attribute with the default value of no. If the value of successfulBranchesOnly is no, all 's which have completed (successfully or unsuccessfully) MUST be counted. If successfulBranchesOnly is yes, only 's which have completed successfully MUST be counted.
The is evaluated each time a directly enclosed activity completes. If the evaluates to true, the activity completes:
When the is fulfilled for a parallel activity, all still running directly enclosed activities MUST be terminated (see section 12.6 Termination Handlers).
When the is fulfilled for a serial activity, further child 's MUST NOT be instantiated, and the activity completes.
If upon completion of a directly enclosed activity, it can be determined that the can never be true, the standard bpel:completionConditionFailure fault MUST be thrown.
When a does not have any sub-elements or attributes understood by the WS-BPEL processor, it MUST be treated as if the does not exist.
Yüklə 2.65 Mb.