Fault handling in a business process can be thought of as a mode switch from the normal processing in a scope. Fault handling in WS-BPEL is designed to be treated as "reverse work," in that its aim is to undo the partial and unsuccessful work of a scope in which a fault has occurred. The completion of the activity of a fault handler, even when it does not rethrow the handled fault, is not considered successful completion of the attached scope. Compensation is not enabled for a scope that has had an associated fault handler invoked.
Explicit fault handlers, if used, attached to a scope provide a way to define a set of custom fault-handling activities, defined by and constructs. Each construct is defined to intercept a specific kind of fault, defined by a fault QName. An optional variable can be provided to hold the data associated with the fault. If the fault name is missing, then the catch will intercept all faults with the same type of fault data. The fault variable is specified using the faultVariable attribute in a fault handler. The variable is deemed to be implicitly declared by virtue of being used as the value of this attribute and is local to the fault handler. It is not visible or usable outside the fault handler in which it is declared. A clause can be added to catch any fault not caught by a more specific fault handler.
There are various sources of faults in WS-BPEL. A fault response to an activity is one source of faults, where the fault name and data are based on the definition of the fault in the WSDL operation. A activity is another source, with explicitly given name and/or data. WS-BPEL defines several standard faults with their names, and there may be other platform-specific faults such as communication failures.
A fault name may be used in a WS-BPEL process without being defined elsewhere, for example in a WSDL operation; or the fault name may be missing.
[SA00080] There MUST be at least one or element within a element. This requirement MUST be statically enforced.
Data thrown with a fault can be a WSDL message type or a XML Schema element. Each , which specifies a QName as its faultName attribute value, can only catch a fault with a matching QName (see section 10.3. Invoking Web Service Operations – Invoke for the description of how to construct this QName from a fault defined in WSDL). Faults with the same name defined in multiple WSDL operations within the same WSDL namespace can be caught by the same fault handler. If the data to be caught is a WSDL message then the faultMessageType attribute is used to specify the message type’s QName. If the data to be caught is a XML element then the faultElement attribute is used to specify the element definition’s QName.
[SA00081] To have a defined type associated with the fault variable, the faultVariable attribute MUST only be used if either the faultMessageType or faultElement attributes, but not both, accompany it. The faultMessageType and faultElement attributes MUST NOT be used unless accompanied by faultVariable attribute.
Because of the flexibility allowed in expressing the faults that a construct can handle, it is possible for a fault to match more than one fault handler. [SA00093] While multiple fault handlers may match a fault, the element MUST NOT contain identical constructs. The constructs are considered identical in this context, when they have identical values in their faultName, faultElement and faultMessageType attributes. If an attribute is not present in a , its value is considered absent and is identical only to an absent attribute of another . A process definition that violates this condition MUST be detected by static analysis and MUST be rejected by a conformant implementation.
When faults are thrown without associated data the fault MUST be caught as follows:
If there is a construct with a matching faultName value that does not specify a faultVariable attribute then the fault is passed to the identified catch activity.
Otherwise, the fault will be handled by the default fault handler (see section 12.5.1. Default Fault, Compensation, and Termination Handlers).
In the case of faults thrown with associated data the fault MUST be caught as follows:
If there is a construct with a matching faultName value that has a faultVariable whose type matches the type of the runtime fault data then the fault is passed to the identified construct (see the matching criteria definition below).
Otherwise if the fault data is a WSDL message type where the message contains a single part defined by an element and there exists a construct with a matching faultName value that has a faultVariable whose associated faultElement’s QName matches the QName of the runtime element data of the single WSDL message part, then the fault is passed to the identified construct with the faultVariable initialized to the value in the single part’s element (see the matching criteria definition below).
Otherwise if there is a construct with a matching faultName value that does not specify a faultVariable attribute then the fault is passed to the identified construct. Note that in this case the fault value will not be available from within the fault handler but will be available to the activity.
Otherwise if there is a construct without a faultName attribute that has a faultVariable whose type matches the type of the runtime fault data then the fault is passed to the identified construct (see the matching criteria definition below).
Otherwise if the fault data is a WSDL message type where the message contains a single part defined by an element and there exists a construct without a faultName attribute that has a faultVariable whose associated faultElement’s QName matches the QName of the runtime element data of the single WSDL message part, then the fault is passed to the identified construct with the faultVariable initialized to the value in the single part’s element (see the matching criteria definition below).
Otherwise if there is a fault handler then the fault is passed to the fault handler.
Otherwise, the fault will be handled by the default fault handler (see section 12.5.1. Default Fault, Compensation, and Termination Handlers).
Matching the type of a faultVariable to the runtime fault data as mentioned in points #1 and #4 above is more restrictive than in points #2 and #5. In the case of #1 and #4, a WSDL message type variable can only match a WSDL message type fault data, while an element variable can only match element-based fault data. For the case of WSDL message-based fault, they match only when their QNames are identical. For points #1 and #4, where faultElement is used, and point #2 and #5, matching is done by comparing the runtime element-based data and the faultElement’s QName.
The runtime element-based data, which originates from throwing a fault with an XSD element-based variable, an XSD type-based variable or a single-part WSDL message based on an XSD element, is considered to be compatible with the globally declared element referenced by faultElement, when:
the QName of the element-based data exactly matches the QName of the referenced element, or
the element-based data is a member of the substitutionGroup headed by the referenced element (note: this membership relation is transitive but not symmetric).
If multiple faultElement-based constructs are compatible with element-based fault data then their matching priority is as follows:
A construct with an exact QName match takes precedence.
If no exact match exists then the matching precedence is given to a with a faultElement which has the fewest level of substitutionGroup relation in XML element declaration (see example below).
For example, foo:Elem1, foo:Elem2, foo:Elem3, foo:Elem4, foo:Elem5 are all globally declared elements. Elem2 is declared with its substitutionGroup attribute referring to Elem1. The same relationship is declared between Elem3 and Elem2, and between Elem4 and Elem3, and between Elem5 and Elem4. Consider a scope with the following fault handlers:
... catch-logic-A ...
... catch-logic-B ...
... catch-logic-C ...
If the fault data element is “foo:Elem5”, the -logic-B based on “foo:Elem4” will be matched. If fault data element is “foo:Elem3”, the -logic-A based on “foo:Elem2” will be matched. If fault data element is “foo:Elem1”, the -logic-C will be matched.
Consider the following example:
faultVariable="bar"
faultMessageType="tns:barType">
Assume that a fault named ”x:foo” is thrown from within the scope to which this construct is attached. The first will be selected if the fault carries no fault data. If there is fault data associated with the fault, the third will be selected if and only if the type of the fault’s data matches the type of variable “bar”, otherwise the fault handler will be selected. Finally, a fault with a fault variable whose type matches the type of “bar” and whose name is not “x:foo” will be processed by the second catch. All other faults will be processed by the fault handler.
A WS-BPEL process is allowed to rethrow the original fault caught by the nearest enclosing fault handler with a activity. A activity is allowed to be used within any fault handler and only within a fault handler. Regardless of how a fault is caught and whether a fault handler modifies the fault data, a activity always throws the original fault data and preserves its type.
Although the use of compensation can be a key aspect of the behavior of fault handlers, the activity within a fault handler is arbitrary, and can even be the activity. When a fault handler is present, it is in charge of handling the fault. It might rethrow the same fault or a different one, or it might handle the fault by performing cleanup and allowing normal processing to continue in the enclosing scope.
A process or scope in which a fault occurred is considered to have ended abnormally (i.e. completed unsuccessfully), whether or not the fault was caught and handled without rethrowing the original fault or throwing a new fault. A compensation handler is never installed for a scope which is reached by a fault.
When a fault handler for a scope completes handling a fault that occurred in that scope without throwing a fault itself, links that have that scope as the source MUST be subject to evaluation of their status.
As explained in section 10.3. Invoking Web Service Operations – Invoke, there is a special shortcut for the invoke activity to inline fault handlers rather than explicitly using an immediately enclosing scope.
The compensation handler for scope C becomes available for invocation by the FCT-handlers for its immediately enclosing scope exactly when scope C completes normally. A fault handler for scope C is available for invocation exactly when C has commenced but has not been completed. If the scope faults before completion, then the appropriate fault handler gets control and all other fault handlers and termination handlers are uninstalled. A WS-BPEL processor MUST NOT run more than one explicit or default FCT-handler for the same scope under any circumstances.
The behavior of fault handling for scope C MUST begin by terminating all activities that are currently active and directly enclosed within C (see section 12.6 Termination Handlers). The termination of these activities MUST occur before the specific behavior of a fault handler is started. This also applies to the default fault handlers described below. The activity of a fault handler is deemed to occur in the scope to which the fault handler is attached.
12.5.1. Default Fault, Compensation, and Termination Handlers
The visibility of scope names and therefore of compensation handlers is limited to the immediately enclosing scope. Therefore, the ability to compensate a scope would be lost if the immediately enclosing scope did not have an FCT-handler. Also many faults are not programmatic or the result of operation invocation, so it is not reasonable to expect an explicit fault handler for every fault in every scope. WS-BPEL therefore provides default fault handlers, when they are missing. Similar convenience features are applied to compensation handlers and termination handlers.
Whenever a fault handler (for any fault), , or is missing for any given , they MUST be implicitly created as follows.
Default fault handler:
Default compensation handler:
Default termination handler:
12.5.2. Default Compensation Order
There are two rules for default compensation order that address different aspects of the order relation. Note that they are cumulative, i.e., they MUST both be obeyed in every case in performing default compensation.
Informally, Rule 1 states that default compensation must respect the forward order of execution for the scopes being compensated, but only in so far as that order is mandated by the process definition. In cases where concurrency is permitted as a result of the use of , parallel , or , and not otherwise constrained by links, any actual logical temporal order during execution is not a part of the constraint defined by the first rule. More formally, we state the rule based on a precise notion of control dependency.
Definition (Control Dependency). If an activity A must complete before activity B begins, as a result of the existence of a control path from A to B in the process definition, then we say that B has a control dependency on A. Note that control dependencies may occur due to control links in a as well as due to constructs like . Control flow due to explicit is not considered a control dependency.
Rule 1: Consider scopes A and B such that B has a control dependency on A. Assuming both A and B completed successfully and both must be compensated as part of a single default compensation behavior, the compensation handler of B MUST run to completion before the compensation handler of A is started.
In some situations, a single fault signal can trigger multiple default compensation behaviors. Rule 1 above applies to each compensation behavior individually.
Rule 1 permits scopes that executed concurrently on the forward path to also be compensated concurrently in the reverse path. The rule imposes a constraint on the order in which compensation handlers run during compensation in any default handlers of the enclosing scope, and is not meant to be fully prescriptive about the exact order and concurrency.
Of course, if one follows the strict reverse order of completion, then that necessarily respects control dependencies and is also consistent with this rule.
Informally, the second rule is needed as a result of the fact that all scopes are not isolated (see section 12.8. Isolated Scopes). It is syntactically possible for two scopes to have links crossing from activities within one to activities within the other, and moreover such links may cross in both directions (see section 11.6.2. Link Semantics). This would be illegal if both such scopes were isolated. The semantics of links crossing isolated scope boundaries imply that such bidirectional links constitute a cycle. The intent of Rule 2 is to treat all scopes as if they were isolated, only for purposes of cycle detection regarding links crossing scope boundaries. This allows us to apply Rule 1 to any pair of scopes to decide unambiguously if there is a control dependency between them, and if so, in which direction. Formally, we need three definitions to state the rule precisely.
Definition (Peer-Scopes). Two scopes S1 and S2 are said to be peer scopes if they are both immediately enclosed within the same scope (including process scope).
Definition (Scope-Controlled Set). An activity A is within the scope-controlled set of activities of scope S if either A is S itself, or A is enclosed within S, at any depth.
Definition (Peer-Scope Dependency). If S1 and S2 are peer scopes then S2 is said to have a direct peer-scope dependency on S1 if there is an activity B within the scope-controlled set of S2, and an activity A within the scope-controlled set of S1, such that B has a control dependency on A. The peer-scope dependency relation is the transitive closure of the direct peer-scope dependency relation.
Rule 2: [SA00082] The peer-scope dependency relation MUST NOT include cycles. In other words, WS-BPEL forbids a process in which there are peer scopes S1 and S2 such that S1 has a peer-scope dependency on S2 and S2 has a peer-scope dependency on S1. A process definition containing a cyclic peer-scope dependency relation MUST be rejected. This MUST be enforced by static analysis.
In the following example, scope “SC1” and “SC2” are peer-scopes with respect to the process scope “P1” as their enclosing scope. Activities “InvA” and “RcvB” are within the scope-controlled set of activities of scope “SC1”, while “InvB” and “RcvA” are within the scope-controlled set of activities of scope “SC2”. Scope “SC1” is said to have a peer-scope dependency on scope “SC2” because of control link “LinkA”. Because of control link “LinkB”, there is a peer-scope dependency in the opposite direction. Hence, this process definition is not accepted by a WS-BPEL processor because of this cyclic dependency.
...
...
...
...
...
...
...
...
...
An effect of Rule 2 is to permit a depth-first traversal of the lexical scope tree for default compensation, respecting the control dependency relation among peer scopes as dictated by Rule 1. Default compensation order of a scope resulting from these rules is dependent only on the compensation of its nested scopes. The default compensation order mandated by the rules here is consistent with strict reverse order of completion. Strict reverse order of completion applied to compensation of all scopes might not be in depth-first order, and could require interleaving of nested compensations across peer scopes. Processes that require interleaving of nested compensations across peer scopes are disallowed by the rules above.
12.5.3. Relation between Compensation Handlers and Isolated Scopes
Compensation handlers may run concurrently with other activities including other compensation handlers, therefore it is necessary to allow compensation handlers to use isolation scope semantics (see section 12.8. Isolated Scopes). Compensation handlers do not run within the isolation domain of their associated scopes, but fault handlers do. This creates difficulties in the isolation semantics of compensation handlers for scopes nested inside an isolated scope. Such compensation handlers MUST NOT use isolated scopes themselves because isolated scopes cannot be nested. However, their isolation environment would be uncertain because they may be invoked from either a fault handler within the isolation domain of their enclosing scope or within the compensation handler of the same enclosing scope which is not in that isolation domain.
In order to ensure consistency of behavior, WS-BPEL mandates that the compensation handler of an isolated scope will itself have isolated behavior implicitly, although it will create a separate isolation domain from that of its associated scope.
12.5.4. Handling WS-BPEL Standard Faults
If the value of the exitOnStandardFault attribute on a scope is set to "yes", then the process MUST exit immediately, as if an activity has been reached, when any WS-BPEL standard fault other than bpel:joinFailure reaches the scope. If the value of this attribute is set to "no", then the process can handle a WS-BPEL standard fault using a fault handler. The default value for this attribute is "no". When this attribute is not specified on a it inherits its value from its enclosing or
.
12.6 Termination Handlers
The behavior of a fault handler for a scope C begins by implicitly terminating all activities enclosed within C that are currently active. Note that the completion condition in may also trigger termination of enclosed scopes. The following paragraphs define the rules that MUST be followed for all WS-BPEL activity types.
The activities are sufficiently short-lived that they MAY be allowed to complete rather than being interrupted when termination is forced. The evaluation of expressions when already started is also allowed to complete. An enforced termination MAY also be allowed as WS-BPEL does not mandate a particular behavior for assignments and expression evaluations.
Each , , and activity MUST be interrupted and terminated prematurely. When a request-response is interrupted and terminated prematurely, the response (if received) for such a terminated activity MUST be ignored.
The , and activities MAY be allowed to complete. The activity, once started, MUST NOT be terminated.
All structured activity behavior is interrupted. The iteration of , , and serial MUST be interrupted and termination MUST be applied to the loop body activity. For a parallel , termination MUST be applied to all parallel executing branches. If an or
activity has already selected a branch, then the termination MUST be applied to the activity of the selected branch. If either of these activities has not yet selected a branch, then the or activity itself MUST be terminated immediately. The and constructs MUST be terminated by terminating their behavior and applying termination to all nested activities currently active within them.
The and activity MUST be terminated by propagating the termination to the invoked compensation handler instances and applying termination to the activities of the compensation handlers.
Termination handlers provide the ability for scopes to control the semantics of forced termination to some degree. The syntax is as follows:
activity
The forced termination of a scope begins by terminating its primary activity and all running event handler instances. Following this, the custom for the scope, if present, is run. Otherwise, the default termination handler is run.
Forced termination for a scope applies only if the scope is in normal processing mode. If the scope has already invoked fault handling behavior, then the termination handler is uninstalled, and the forced termination has no effect. The already active fault handling is allowed to complete. If the fault handler itself throws a fault, this fault is propagated to the next enclosing scope.
The termination handler for a scope is permitted to use the same range of activities as a fault handler, including the or activity. However, a termination handler cannot throw any fault. Even if an uncaught fault occurs during its behavior, it is not rethrown to the next enclosing scope. This is because: (a) the enclosing scope has already either faulted or is in the process of being terminated, which is what is causing the forced termination of the nested scope or (b) the scope being terminated is a branch of a parallel and the early completion mechanism has triggered the termination, as the of was fulfilled.
A fault in a termination handler MUST cause all running contained activities to be terminated (see also section 12.4.4.3. Compensation within FCT-Handlers).
Forced termination of nested scopes occurs in innermost-first order as a result of the rule (stated above) that the termination handler is run after terminating its primary activity.
12.7. Event Handlers
Each scope, including the process scope, can have a set of event handlers. These event handlers can run concurrently and are invoked when the corresponding event occurs. The child activity within an event handler MUST be a activity. There are two types of events. First, events can be inbound messages that correspond to a WSDL operation. Second, events can be alarms, that go off after user-set times. The grammar for the set of event handlers associated with a scope or process is:
?
portType="QName"?
operation="NCName"
( messageType="QName" | element="QName" )?
variable="BPELVariableName"?
messageExchange="NCName"?>*
?
+
?
+
...
*
(
duration-expr
|
deadline-expr
)?
?
duration-expr
...
[SA00083] An event handler MUST contain at least one or element. This MUST be statically enforced.
The portType attribute on is optional. If the portType attribute is included, the value of the portType attribute MUST match the portType value implied by the value of the partnerLink's myRole attribute. All instances of MUST use exactly one of messageType, element, or .
Event handlers are considered a part of the normal behavior of the scope, unlike FCT-handlers.
The activity enclosed within and MUST be a .
When discussing event handlers, the following two terms are used to explain semantics:
associated scope: the scope directly defined within or
ancestor scopes: the chain of enclosing or
elements of the event handler
12.7.1. Message Events
The element indicates that the specified event waits for a message to arrive. The interpretation of this element and its attributes is very similar to a activity. The partnerLink attribute references the partner link that contains the myRole endpoint reference on which the message is expected to arrive. [SA00084] The partnerLink reference MUST resolve to a partner link declared in the process in the following order: the associated scope first and then the ancestor scopes. This requirement MUST be enforced during static analysis. As with the partnerRole endpoint reference is ignored for purposes of executing the receive semantics of an event handler. The portType and operation attributes define the port type and operation that is invoked by the partner in order to cause the event.
The variable attribute, if it exists, identifies a variable local to the event handler that will contain the message received from the partner. [SA00087] The messageType attribute specifies the type of the variable by referencing a message type definition using its QName. The type of the variable (as specified by the messageType attribute) MUST be the same as the type of the input message defined by operation referenced by the operation attribute. Optionally the messageType attribute may be omitted and instead the element attribute substituted if the message to be received has a single part and that part is defined with an element type. That element type MUST be an exact match of the element type referenced by the element attribute. The variable and messageType/element attributes constitute the implicit declaration of a variable of that name and type within the associated scope associated of the event handler. If an element attribute is used then the binding of the incoming message to the variable declared in the event handler occurs as specified for the receive activity in section 10.4. Providing Web Service Operations – Receive and Reply .
An alternative to the use of the variable attribute is the use of a collection of elements. The syntax and semantics of the elements as used on the element are the same as specified in section 10.4. Providing Web Service Operations – Receive and Reply for the receive activity. [SA00085] This includes the restriction that if elements are used on an element then the variable, element and messageType attributes MUST NOT be used on the same element, and [SA00047] the rules regarding the optional nature of the variable attribute or elements. When using the elements, each element constitutes an implicit declaration of a variable of that name within the associated scope of the event handler. The variable type is derived from the type of the corresponding message part. The message type of the WSDL operation can be deduced without any ambiguity, as WS-BPEL does not support WSDL with overloaded operations (see section 3. Relationship with Other Specifications).
Variables referenced by the variable attribute of elements or the variable attribute of an element are implicitly declared in the associated scope of the event handler. [SA00086] Variables of the same names MUST NOT be explicitly declared in the associated scope. This requirement MUST be enforced by static analysis.
[SA00090] If the variable attribute is used in the element, either the messageType or the element attribute MUST be provided in the element. This requirement MUST be enforced during static analysis.
Upon receipt of the inbound message the event handler assigns the inbound message to the variable(s) before proceeding to perform the the activity enclosed by the event handler. Since the variable(s) are declared within a scope associated with the event handler, each instance of the event handler (whether executed serially or concurrently relative to other instances) contains a private copy of the variable(s), which is not shared with other instances. [SA00095]The variable references are resolved to the associated scope only and MUST NOT be resolved to the ancestor scopes.
The operation specified in the event handler may be either a one-way or a request-response operation. In the latter case, the event handler is expected to use a activity to send the response.
The usage of is exactly the same as for activities, with the following addition: it is possible, from an event handler's inbound message operation, to use correlation sets that are declared within the associated scope. [SA00088] The resolution order of the correlation set(s) referenced by MUST be first the associated scope and then the ancestor scopes.
portType="ns:agent"
operation="travelUpdate"
messageType="ns:travelStatsUpdate"
variable="travelUpdate">
...
properties="ns:updateCode" />
...
...
In this example a process is managing travel reservations for a customer and needs to handle reservation updates from the travel booking system. The construct is used to receive the update messages which are correlated using the travelCode correlation set, which is defined and initialized elsewhere in the process. However, sometimes the event handler needs to contact the travel booking system to follow up on an update message. To do that the outgoing message needs not only the value in the travelCode correlation set, but also the value in an update code included in the travel update message. This is where the updateCode correlation set, declared locally to the construct comes in. When the update message is received the updateCode correlation set is initialized and its value made available only to the event handler instance.
Scope S2 is an immediately enclosed scope of S1. The compensation handler on scope S1 invokes the compensation handler on scope S2, which is associated with the event handler. If S2's compensation handler were invoked, the variable used to receive the message for the event handler as well as any correlation sets declared in the associated scope would be visible to the compensation handler, and as parts of the scope snapshot.
The semantics of are identical to those of a receive activity regarding the optional nature of the variable attribute or elements, the handling of race conditions, and the constraint regarding simultaneous enablement of conflicting receive actions. For the last case, see the bpel:conflictingReceive fault and its related semantics in section 10.4. Providing Web Service Operations – Receive and Reply .
When the operation specified in the element is a request-response operation, a message exchange is used to associate the response from a activity with the inbound message operation specified in the element. A message exchange is always used to pair up request and response messages. This is true even when the messageExchange attribute is not specified explicitly on the element, since omission of the attribute signifies use of a default message exchange (see section 10.4.1. Message Exchanges). [SA00089] When the messageExchange attribute is explicitly specified, the resolution order of the message exchange referenced by messageExchange attribute MUST be first the associated scope and then the ancestor scopes.
Event handlers do not carry the createInstance attribute, since the event handler cannot be enabled until the instance is created.
When the message constituting an event arrives, the activity specified in the corresponding event handler is executed. Business processes are enabled to receive such messages concurrently with the normal activity of the scope to which the event handler is attached, as well as concurrently with other event handler instances. This allows such events to occur at arbitrary times and an arbitrary number of times while the corresponding scope (which may be the entire business process instance) is active.
The following example shows the usage of an event handler to halt a process instance immediately through an external message. This event handler is attached to the
scope and is therefore available during the lifetime of the entire business process instance.
...
portType="ns:car"
operation="haltOrder"
messageType="ns:haltOrderMsgType"
variable="haltDetails">
...
...
In this example, if the buyer invokes the haltOrder operation, the activity is executed, which results in immediate termination of the process instance without the ongoing work being compensated. Alternatively, the event handler could throw a fault to cause the ongoing work to be undone and compensated.
12.7.2. Alarm events
The element marks a time-driven event. In an element, the and expressions are mutually exclusive. There MUST be at least one , , or expression. The expression specifies the duration after which the event will be signaled. The clock for the duration starts at the point in time when the parent scope (the scope which directly encloses the event handler) starts. The alternative expression specifies the specific point in time when the alarm will be fired. Only one of these two expressions may occur in any event. 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. The optional expression also specifies a duration. When the expression is specified, the alarm will be fired repeatedly each time the duration period expires, while the parent scope is active. The expression may be specified on its own or with either the or the expression. If the expression is specified alone, the clock for the very first duration starts at the point in time when the parent scope starts. If the expression is specified with either the or the expression, the first alarm is not fired until the time specified in the or expression expires; thereafter it is fired repeatedly at the interval specified by the expression. The duration for the is calculated when the parent scope starts. If the specified duration value for is zero or negative then the standard fault bpel:invalidExpressionValue MUST be thrown.
12.7.3. Enablement of Events
The event handlers associated with a scope are enabled when the parent scope starts. If the event handler is enclosed by the
scope, the event handler is enabled as soon as the process instance is created. This allows the alarm time for a global alarm event to be specified using the data provided within the message that creates a process instance, as shown in the following example:
...
The element specifies a timer event that is fired when the duration specified in the processDuration part of the orderDetails variable is exceeded. The value of the part is provided via the getOrder activity that receives message containing the order details and causes the creation of a process instance for that order.
12.7.4. Processing of Events
The following subsections provide rules that MUST be adhered to during processing of alarm or message events.
12.7.4.1. Alarm Events
The clock for the duration starts at the point in time when the parent scope starts. An alarm event goes off when the specified time or duration has been reached. Except for the alarm, an alarm event is executed at most once while the containing scope is active; the event is disabled for the rest of the lifespan of the parent scope after it has occurred and the specified processing has been executed. While the parent scope is active, the alarm event is created repeatedly each time the duration expires. If the specified duration value for is zero or negative then the standard fault bpel:invalidExpressionValue MUST be thrown.
12.7.4.2. Message Events
A message event occurs when the appropriate message is received. When such an event occurs, the associated activity is executed. However, the event handler remains enabled, even for concurrent use. While the parent scope is active, a particular message event can occur multiple times (see section 12.7.7. Concurrency Considerations below for concurrency considerations).
12.7.5. Disablement of Events
When the primary activity of a scope is complete, all its contained event handlers are disabled. The already running instances of the event handlers MUST be allowed to complete, and the completion of the scope as a whole is delayed until they complete.
12.7.6. Fault Handling Considerations
When a fault occurs within the inbound message operation specified in itself (e.g. bpel:invalidVariables or bpel:conflictingReceive) or its associated scope, the fault MUST be propagated to the associated scope first. If unhandled, the fault will be propagated to the ancestor scopes chain.
12.7.7. Concurrency Considerations
Multiple and events can occur concurrently and they are treated as concurrent activities even if they correspond to a request-response operation from the same partner link. The constraint that there can be at most one outstanding request for a request-response operation on a given partner link also applies (see bpel:conflictingRequest related semantics in section 10.4. Providing Web Service Operations – Receive and Reply ).
When considering concurrent invocation of event handlers, including both and with a expression, isolated scopes can be used to control access to shared variables (see section 12.8. Isolated Scopes).
12.8. Isolated Scopes
The isolated attribute of a scope, when set to "yes", provides control of concurrent access to shared resources: variables, partner links, and control dependency links. Such a scope is called an isolated scope. The default value of the isolated attribute is "no".
Suppose two concurrent isolated scopes, S1 and S2, access a common set of variables and partner links (external to them) for read or write operations. The semantics of isolated scopes ensure that the results would be no different if all conflicting activities (read/write and write/write activities) on all shared variables and partner links were conceptually reordered so that either all such activities within S1 are completed before any in S2 or vice versa. The same isolation semantics apply to properties also. Properties are merely projections of variables and thus are always coupled with them. Access to properties is identical to access to variables, controlled by the enclosing isolated scope. It is useful to note that the semantics of isolated scopes are very similar to the standard isolation level "serializable" used in database transactions. The actual mechanisms used to ensure this are implementation dependent.
[SA00091] Isolated scopes MUST NOT contain other isolated scopes, but MAY contain scopes that are not marked as isolated. In the latter case, access to shared variables from within such enclosed scopes is controlled by the enclosing isolated scope.
Any message exchange referenced in a scope serves only to provide a handle to access a facet of the state of its associated partner link and is intrinsically stateless. Hence, the control exerted by the enclosing isolated scope does not apply to message exchange.
Any partner links referenced within an isolated scope have their access protected by that enclosing scope. The protection applies specifically to the endpointReference part, and not the message exchange parts of the partnerLink state. The same conflict isolation semantics for shared variable access are applied to the endpointReference part of a shared partner link state.
By definition, correlation sets are only mutable at initiation and are immutable throughout the remainder of their lifecycle. Hence any correlation sets referenced within an isolated scope do not have their access controlled by the enclosing scope. However, the initiation of a correlation set is performed in an atomic fashion – in the same sense as that of an operation – ensuring that the correlation set will not be partially initiated.
The used handlers in an isolated scope MUST follow these rules:
The event handlers for an isolated scope share the isolation domain of the associated scope. The rule that isolated scopes must not be nested applies to the associated scope of an event handler as well.
The fault handlers for an isolated scope share the isolation domain of the associated scope. In case a fault occurs in an isolated scope, the behavior of the fault handler is considered part of the isolated behavior.
The termination handler for an isolated scope shares the isolation domain of the associated scope. When the termination handler of an isolated scope is invoked, its behavior is considered part of the isolated behavior.
The compensation handler for an isolated scope does not share the isolation domain of the associated scope. The isolation domain ends and the scope snapshot is created when the normal processing of that isolated scope completes. Afterwards, the compensation handler is installed. If the invoker of the compensation handler (i.e. or activities or implicit invoking invoking FCT-handler of the immediately enclosing scope) is not within an isolation domain, the execution of the compensation handler associated with an isolated scope will be implicitly isolated. Such an implicit isolation domain ends when the execution of such a compensation handler ends (see scope "FH_P" and scope "Q" in the example below). If the invoker of the compensation handler is already within an isolation domain and the invoked compensation handler is associated with an isolated scope, such a scope definition is a case of nested isolated scopes and MUST be disallowed by static analysis (if scope "FH_P" below is isolated, then such a scope definition is disallowed). (See also [SA00091]).
...
...
...
...
...
...
In the above example, the activity is NOT already within an isolation domain (assuming scope "P" is the root scope of the process). The execution of the compensation handler of scope "Q" will be isolated automatically. This isolation domain ends when the execution of the compensation handler of scope "Q" ends.
The compensation handler associated with a non-isolated scope actually shares the isolation domain of the invoker of the compensation handler, when the invoker is already within an isolation domain (see scope "FH_X" in the following example).
...
...
...
...
...
In the above example, the activity will invoke the compensation handler of scope "Y" (which performs sequence "undoY_seq") in the isolation domain of scope "FH_X".
The status of links leaving an isolated scope (see also section 11.6.2. Link Semantics) will not be visible at the target until the scope completes, whether successfully or unsuccessfully. If the scope completes unsuccessfully, the status of links leaving the scope is false regardless of what it was at the time the source activity completed. There are no special rules for links which enter isolated scopes.
Yüklə 2.65 Mb.