Web Services Business Process Execution Language Version 0 Public Review Draft 02, 20 November, 2006
|
|  Yüklə 2.65 Mb.
|
12.3. Error Handling in Business ProcessesBusiness processes are often of long duration. They can manipulate business data in back-end databases and line-of-business applications. Error handling in this environment is both difficult and business critical. The use of ACID transactions is usually limited to local updates because of trust issues and because locks and isolation cannot be maintained for the long periods during which fault conditions and technical and business errors can occur in a business process instance. As a result, the overall business transaction can fail or be cancelled after many ACID transactions have been committed. The partial work done must be undone as best as possible. Error handling in WS-BPEL processes therefore leverages the concept of compensation, that is, application-specific activities that attempt to reverse the effects of a previous activity that was carried out as part of a larger unit of work that is being abandoned. There is a history of work in this area regarding the use of Sagas [Sagas] and open nested transactions [Trends]. WS-BPEL provides a variant of such a compensation mechanism by providing the ability for flexible control of the reversal. WS-BPEL achieves this by providing the ability to define fault handling and compensation in an application-specific manner, in support of Long-Running Transactions (LRT’s). The notion of LRT described here is purely local and occurs within a single business process instance. There is no distributed coordination necessary regarding an agreed-upon outcome among multiple-participant services. The achievement of distributed agreement is an orthogonal problem outside the scope of this specification. As an example, consider the planning and fulfillment of a travel itinerary. This can be viewed as an LRT in which individual service reservations can use nested transactions within the scope of the overall LRT. If the itinerary is cancelled, the reservation transactions must be compensated for by cancellation transactions, and the corresponding payment transactions must be compensated accordingly. For ACID transactions in databases the transaction coordinator(s) and the resources that they control know all of the uncommitted updates and the order in which they must be reversed, and they are in full control of such reversal. In business transactions, the compensation behavior is itself a part of the business logic and protocol, and must be explicitly specified. In this example, there might be penalties or fees applied for cancellation of an airline reservation depending on the class of ticket and the timing of the cancellation. If a payroll advance has been given to pay for the travel, the reservation must be successfully cancelled before the payroll advance for it can be reversed in the form of a payroll deduction. This means the compensation actions might need to run in the same order as the original transactions, which is not the standard or default in most ACID transaction systems. Using activity
As explained in section 10.3. Invoking Web Service Operations – Invoke, there is a special shortcut for the operation="Purchase" inputVariable="sendPO" outputVariable="getResponse">
pattern="request" /> operation="CancelPurchase" inputVariable="getResponse" outputVariable="getConfirmation">
In this example, the original Without the portType="SP:Purchasing" operation="CancelPurchase"
inputVariable="getResponse" outputVariable="getConfirmation">
portType="SP:Purchasing" operation="Purchase"
inputVariable="sendPO" outputVariable="getResponse">
pattern="request" /> Note that the variable getResponse is not local to the If the The process state consists of the current state of all scopes that have been started. This includes scopes that have completed successfully but for which the associated compensation handler has not been invoked. For successfully completed (but uncompensated) scopes, their state is kept at the time of completion. Such scopes are not running, yet they are still reachable. This is because their compensation handlers are still available, and therefore the execution of such scopes may continue during the execution of their compensation handlers, which can be thought of as an optional continuation of the behavior of the associated scope. A scope may have been executed several times (e.g. in a The behavior of a compensation handler can use the state of the associated scope as it has been left. This includes variables, partner links, message exchanges, and correlation sets in both the associated scope and all scopes that enclose it. For the variables in the associated scope, the compensation handler starts executing with the scope snapshot. The compensation handler also has access to the current state of each enclosing scope. This state is shared with any concurrent units of logic. The compensation handler may itself have been called from the compensation handler of the parent scope. It will then share the continuation of the state of the enclosing scope that its caller is using.
The picture below shows three nested scopes P, S2 and S3, a fault handler FH(P) of the process and compensation handlers CH(S2) and CH(S3). The picture is based on the XML below. When executing the process, the first scope P (the process itself) declares a variable V1 and initializes it to the value of 0. Scopes S2 and S3 are executed. At successful completion of S2 and S3, all variable values are set to 1 and are frozen into snapshots (in the timeline shown by dotted lines). Subsequently, a fault occurs within the process P (indicated by event “1” in the picture), which gets caught by the fault handler FH(P) of the process P. When the fault handler of the process calls the compensation handler CH(S2) of scope S2 (indicated by event “2” in the picture), the snapshot of S2’s state is retrieved and used while compensating. The same applies when compensating scope S3 (indicated by event “3” in the picture).
...
...
standard-elements standard-elements The Fault handlers, compensation handlers, and termination handlers are referred to as FCT-handlers. For the purpose of specifying the semantics of [SA00092]Within a scope, the name of all named immediately enclosed scopes MUST be unique. This requirement MUST be statically enforced. A FCT-handlers may themselves contain scopes. The invocation of a compensation activity is interpreted based on the immediately enclosing FCT-handler and is used to compensate the behavior of a successfully completed scope immediately enclosed inside the scope associated with that FCT-handler. There is therefore no way to use a compensation activity to compensate the scopes immediately enclosed inside an FCT-handler. An The names of all named activities immediately enclosed in a scope must be unique (see section 10.1. Standard Attributes for All Activities). [SA00078] The target attribute of a This activity is used when an FCT-handler needs to perform additional work, such as updating variables, in addition to performing default compensation for the targeted immediately enclosed scopes. User-defined FCT-handlers may use When user-defined FCT-handlers are executed, a WS-BPEL processor MUST NOT compensate immediately enclosed scopes unless the When a In the case of scope specific compensation ( If an uncaught fault occurs while executing any compensation handler instance of the group, or if compensation activities are terminated, then all running instances MUST be terminated following standard WS-BPEL activity termination semantics. All compensation handler instances of the group and compensation handler instance groups of immediately enclosed scopes are uninstalled. Completed compensation handler instances within a Compensation Handler Instance Group are not subject to further compensation. In the case of parallel Figure 4: Compensation within Fault Handlers shows a fault handler FH(S1) that contains a scope S2. Scope S2 cannot have a compensation handler CH(S2) as this compensation handler would be unreachable, but it may have a fault handler FH(S2) that is allowed to compensate an inner scope S3. A fault in a fault handler MUST cause all running contained activities to be terminated (see section 12.6 Termination Handlers). All compensation handlers contained in the fault handler MUST be uninstalled. The fault is propagated to the enclosing scope. Compensation within Compensation Handlers
A root scope enclosed by a compensation handler can be used to ensure “all or nothing” semantics, but not for reversing the work of a successfully completed compensation handler. If the compensation handler completes successfully then any installed compensation handlers for scopes nested within it are uninstalled. The successfully completed compensation cannot be reversed, because the root scope inside a compensation handler cannot have a its own compensation handler associated because it is not reachable at all from anywhere within the process. A compensation handler that faults (“internal fault”) will undo its partial work by compensating all scopes immediately enclosed by the root scope according to the fault handler of the root scope. If such a fault handler is not specified explicitly, partial work will be compensated in the default order (see section 12.5.2. Default Compensation Order). This approach can be used to provide all or nothing semantics for compensation handlers. After the partial work is undone, the compensation handler MUST be uninstalled. The fault MUST be propagated to the caller of the compensation handler. This caller is a default FCT-handler of the enclosing scope or a compensation activity contained within a user-defined handler.
Figure 5: Compensation within Compensation Handlers shows a compensation handler CH(S1) that contains a scope S2. As in the preceding figure, S2 cannot have a compensation handler CH(S2) itself but may have a fault handler FH(S2) that is allowed to compensate an inner scope S3. A fault inside a termination handler MUST NOT be not propagated to the enclosing scope (see section 12.6 Termination Handlers). Other than that, all of the statements about fault handlers apply to termination handlers as well. |
