A provides the context which influences the execution behavior of its enclosed activities. This behavioral context includes variables, partner links, message exchanges, correlation sets, event handlers, fault handlers, a compensation handler, and a termination handler. Contexts provided by activities can be nested hierarchically, while the “root” context is provided by the
construct (see also sections 8.1. Variables, 12.4. Compensation Handlers and 12.5. Fault Handlers).
The
and elements share syntax constructs, which have the same semantics. However, they do have the following differences:
The
construct is not an activity; hence, standard attributes and elements are not applicable to the
construct
A compensation handler and a termination handler can not be attached to the
construct
The isolated attribute is not applicable to the
construct (see section 12.8. Isolated Scopes)
Each has a required primary activity that defines its normal behavior. The primary activity can be a complex structured activity, with many nested activities to arbitrary depth. All other syntactic constructs of a activity are optional, and some of them have default semantics. The context provided by a is shared by all its nested activities.
The syntax for scope is:
standard-attributes>
standard-elements
?
...
?
...
?
...
?
...
?
...
?
...
?
...
?
...
activity
All handlers on a are lexically subordinate to the and can access all variables, partner links, message exchanges and correlation sets defined on the and its linear ancestors. This is subject to any restrictions, unique to the handler type, specified elsewhere in this document.
A can declare variables, partner links, message exchanges and correlation sets that are visible only within the . For further information, see sections 6.2. Partner Links, 8.1. Variables, 9. Correlation and 10.4. Providing Web Service Operations – Receive and Reply , respectively.
Scope initialization occurs when a
or is entered. Scope initialization consists of instantiating and initializing the scope's variables and partner links; instantiating the correlation sets; and installing fault handlers, termination handler and and event handlers. Any partner links defined in the MUST be set before variables defined in the same whose initialization logic refers to those partner links. Scope initialization is an all-or-nothing behavior: either it all occurs successfully or a bpel:scopeInitializationFailure fault MUST be thrown to the parent scope of the failed . In the case of a failure at the process level the entire process is treated as faulted. Once scope initialization completes, the primary activity of the is executed and the event handlers are installed in parallel with each other. An exception to the previous rule applies to 's that contain a process' initial start activity. An initial start activity is the start activity that caused a particular process instance to be instantiated. If a scope contains an initial start activity then the start activity MUST complete before the event handlers are installed.
In the following example, the has a primary activity, which contains two concurrent activities. Either of the activities can receive fault responses. The for the are shared by both activities and can be used to catch the faults caused by the possible fault responses.
...
portType="Sell:Purchasing"
operation="Purchase"
inputVariable="sendPO"
outputVariable="getResponse" />
portType="Ship:TransportOrders"
operation="OrderShipment"
inputVariable="sendShipOrder"
outputVariable="shipAck" />
12.2. Message Exchange Handling
When the primary activity and the event handlers of a complete then all Web service interactions dependent on partner links or message exchanges declared inside of the need to be completed. An orphaned IMA occurs when an IMA using a partner link or message exchange, declared in the completing or its descendants, remains open. In this case, the standard fault bpel:missingReply MUST be thrown. The definition of orphaned IMA situations and how they can be detected are:
If the contained primary activity and the event handlers of the scope have completed without any unhandled fault then a check for orphaned IMA’s MUST be made. If one or more orphaned IMA’s are detected then a bpel:missingReply fault is thrown to the completing itself. When the bpel:missingReply fault is thrown, all the orphaned IMA's are encompassed by the fault and are no longer considered orphaned.
If a fault handler has completed without any unhandled fault then a check for orphaned IMA’s MUST be made. If any orphaned IMA is detected then a new bpel:missingReply is thrown to the parent scope (similar to throwing or rethrowing other faults from a fault handler). The newly thrown bpel:missingReply fault MUST encompass all orphaned IMA's, and they are no longer considered orphaned.
If a fault handler itself throws or rethrows a fault different from bpel:missingReply to the parent scope then no check for orphaned IMA's is made, and the checking is deferred to the parent . The orphaned IMA's remain as such.
The same behavior as in the previous bullet applies when a termination handler is executed.
The same checking of orphaned IMA's is performed, after the activity of a compensation handler has completed without any unhandled fault. If any orphaned IMA's are detected, a bpel:missingReply fault MUST be propagated to the invoking FCT-handler and those IMA's are no longer considered orphaned.
If an unhandled fault different from bpel:missingReply occurs during the execution of the compensation handler, that fault is propagated to the invoking FCT-handler. The checking for orphaned IMA's is deferred to the invoking FCT-handler. If any orphaned IMA's resulted from the execution of the compensation handler, they remain orphaned.
Yüklə 2.65 Mb.