WS-BPEL activities perform the process logic. Activities are divided into 2 classes: basic and structured. Basic activities are those which describe elemental steps of the process behavior. Structured activities encode control-flow logic, and therefore can contain other basic and/or structured activities recursively. Structured activities are described in section 11. Structured Activities.
10.1. Standard Attributes for All Activities
Each activity has two optional standard attributes: the name of the activity and suppressJoinFailure (see section 5.2. The Structure of a Business Process for the definition) indicating whether a join fault should be suppressed if it occurs. WS-BPEL language extensibility allows for other namespace-qualified attributes to be added. The name attribute is used to provide machine-processable names for activities. WS-BPEL only makes programmatic use of the names of scope activities. See section 12.4.3. Invoking a Compensation Handler for uniqueness constraints of the name attribute. For a full discussion of the suppressJoinFailure attribute, see section 11.6. Parallel and Control Dependencies Processing – Flow.
name="NCName"?
suppressJoinFailure="yes|no"?
10.2. Standard Elements for All Activities
Each activity has optional containers and , which contain standard elements and respectively. WS-BPEL language extensibility allows these to be extended by adding namespace-qualified elements. These, source and target, elements are used to establish synchronization relationships through links (see section 11.6. Parallel and Control Dependencies Processing – Flow).
?
?
bool-expr
+
?
+
?
bool-expr
10.3. Invoking Web Service Operations – Invoke
The activity is used to call Web Services offered by service providers (see section 6. Partner Link Types, Partner Links, and Endpoint References). The typical use is invoking an operation on a service, which is considered a basic activity. The activity can enclose other activities, inlined in compensation handler and fault handlers, as detailed below. Operations can be request-response or one-way operations, corresponding to WSDL 1.1 operation definitions. WS-BPEL uses the same basic syntax for both, with some additional options for the request-response case.
One-way invocation requires only the inputVariable (or its equivalent elements) since a response is not expected as part of the operation (see section 10.4. Providing Web Service Operations – Receive and Reply ). Request-response invocation requires both an inputVariable (or its equivalent elements) and an outputVariable (or its equivalent elements). If a WSDL message definition does not contain any parts, then the associated attributes, inputVariable or outputVariable, MAY be omitted, [SA00047] and the or construct MUST be omitted. Zero or more correlationSets can be specified to correlate the business process instance with a stateful service at the partner’s side (see section 9. Correlation).
If an activity is used on a partnerLink whose partnerRole EPR is not initialized then a bpel:uninitializedPartnerRole fault MUST be thrown.
In the case of a request-response invocation, the operation might return a WSDL fault message. This results in a fault identified in WS-BPEL by a QName formed by the target namespace of the corresponding port type and the fault name. To ensure consistent fault identification, this uniform naming mechanism MUST be followed even though it does not match the WSDL’s fault-naming model. WSDL 1.1 does not require fault names to be unique within the namespace where the service operation is defined. Therefore, in WSDL 1.1 it is necessary to specify a port type name, an operation name, and the fault name to uniquely identify a fault. Using WSDL 1.1's scheme would limit the ability to use fault-identification and handling mechanisms to deal with invocation faults. In WSDL it is possible to define an operation that declares more than one fault using the same data type. Certain WSDL bindings do not provide enough information for the WS-BPEL processor to determine which fault was intended. In this case, the WS-BPEL processor MUST select the fault that:
Occurs first in lexical order in the operation definition.
A result of this requirement is that a process, which uses the construct based on faultName and deals with such an operation definition, may have different behavior when deployed against different bindings.
Faults in WS-BPEL are defined only in terms of a fault name and optional fault data. This means, for example, that if a fault is generated from a messaging activity (as opposed to the activity (see section 10.6. Signaling Internal Faults) or a system fault), there is no need to keep track of the port type or operation the message activity was using when the fault was received. In consequence, all faults sharing a common name, defined in the same namespace and sharing the same data type (or lack thereof) are indistinguishable in WS-BPEL. Faults of a particular name may be associated with multiple variable types. The construct in WS-BPEL facilitates differentiation of faults with the same name, but with different message or variable types. For details regarding fault handling and , see section 12.5. Fault Handlers.
An activity can be associated with another activity that acts as its compensation action. Thus, a can be invoked either explicitly, or by the default of the enclosing scope (see sections 12. Scopes and 12.3. Error Handling in Business Processes).
Semantically, the specification of local fault handlers and/or a local compensation handler is equivalent to the presence of an implicit activity immediately enclosing the providing these handlers. The implicit activity assumes the name of the activity it encloses, its suppressJoinFailure attribute, as well as its and . For example, the following:
suppressJoinFailure="yes"
partnerLink="Seller"
portType="SP:Purchasing"
operation="Purchase"
inputVariable="sendPO"
outputVariable="getResponse">
...
portType="SP:Purchasing"
operation="CancelPurchase"
inputVariable="getResponse"
outputVariable="getConfirmation" />
is equivalent to:
...
portType="SP:Purchasing"
operation="CancelPurchase"
inputVariable="getResponse"
outputVariable="getConfirmation" />
partnerLink="Seller"
portType="SP:Purchasing"
operation="Purchase"
inputVariable="sendPO"
outputVariable="getResponse" />
In this example, the call to the Purchase operation can be compensated, if necessary, by a call to the CancelPurchase operation (see section 12.4. Compensation Handlers for details).
[SA00048] When the optional inputVariable and outputVariable attributes are being used in an activity, the variables referenced by inputVariable and outputVariable MUST be messageType variables whose QName matches the QName of the input and output message type used in the operation, respectively, except as follows: if the WSDL operation used in an activity uses a message containing exactly one part which itself is defined using an element, then a variable of the same element type as used to define the part MAY be referenced by the inputVariable and outputVariable attributes respectively. The result of using a variable in the previously defined circumstance MUST be the equivalent of declaring an anonymous temporary WSDL message variable based on the associated WSDL message type. The copying of the element data between the anonymous temporary WSDL message variable and the element variable acts as a single virtual with one operation whose keepSrcElementName attribute is set to "yes". The virtual MUST follow the same semantics and use the same faults as a real . In the case of an inputVariable, the value of the variable referenced by the attribute will be used to set the value of the part in the anonymous temporary WSDL message variable. In the case of an outputVariable, the value of the received part in the temporary WSDL message variable will be used to set the value of the variable referenced by the attribute.
10.3.1. Mapping WSDL Message Parts
The element provides an alternative to explicitly creating multi-part WSDL messages from the contents of WS-BPEL variables. By using the element, an anonymous temporary WSDL variable is declared based on the type specified by the relevant WSDL operation's input message. The elements, as a group, act as the single virtual , with each acting as a . Each operation copies data from the variable indicated in the fromVariable attribute into the part of the anonymous temporary WSDL variable referenced in the part attribute of the element (see section 8.4. Assignment). If the operation is copying an element variable to an element part then the keepSrcElementName option for the operation is set to "yes". The virtual MUST follow the same semantics and use the same faults as a real . [SA00050] When is present in an , it is not required to have a for every part in the WSDL message definition, nor is the order in which parts are specified relevant. Parts not explicitly represented by elements would result in uninitialized parts in the target anonymous WSDL variable used by the or activity. Such processes with missing elements MUST be rejected during static analysis. [SA00051] The inputVariable attribute MUST NOT be used on an activity that contains elements.
The element is similar to the element. The element is used to retrieve data from an incoming multi-part WSDL message and place it into individual WS-BPEL variables. When a WSDL message is received on an activity that uses elements, the message is placed in an anonymous temporary WSDL variable of the type specified by the relevant WSDL operation's output message. The elements, as a group, act as a single virtual , with each acting as a . Each operation copies the data at the part of the anonymous temporary WSDL variable referenced in the part attribute of the into the variable indicated in the toVariable attribute. If the operation is copying an element part to an element variable then the keepSrcElementName option for the operation is set to "yes". The virtual MUST follow the same semantics and generate the same faults as a real (see section 8.4. Assignment). When a is present in an , it is not required to have a for every part in the WSDL message definition, nor is the order in which parts are specified relevant. Parts not explicitly represented by elements are not copied from the anonymous WSDL variable to the variable. [SA00052] The outputVariable attribute MUST NOT be used on an activity that contains a element.
The choice to use the inputVariable form instead of the form, or vice versa, creates no restriction on which outputVariable or form is used. Similarly, the choice to use the outputVariable form instead of the form, or vice versa, creates no restriction on which inputVariable or form is used.
The virtual created as a consequence of the or elements occurs as part of the scope of the activity and therefore any fault that is thrown are caught by an ’s inline fault handler when defined. The or elements MAY be used with WSDL messages that only have a single part.
See section 9. Correlation for an explanation of the correlation semantics.
10.4. Providing Web Service Operations – Receive and Reply
A business process provides services to its partners through inbound message activities (IMA - ,
and ) and corresponding activities. This section describes the details of and activities (see sections 11.5. Selective Event Processing – Pick and 12.7.1. Message Events for ).
A activity specifies the partnerLink that contains the myRole used to receive messages, the portType (optional) and operation that it expects the partner to invoke. The value of the partnerRole in the partnerLink is not used when processing a activity. In addition, specifies a variable, using the variable attribute, that is to be used to receive the message data. An alternative to the variable attribute is the use of elements. The syntax and semantics of the elements as used on the activity are the same as specified for the activity in section 10.3.1. Mapping WSDL Message Parts. [SA00055] Including the restriction that if elements are used on a activity then the variable attribute MUST NOT be used on the same activity. If a WSDL message definition does not contain any parts, then the associated variable attribute MAY be omitted, [SA00047] and the construct MUST be omitted. The syntax of the activity is summarized below:
portType="QName"?
operation="NCName"
variable="BPELVariableName"?
createInstance="yes|no"?
messageExchange="NCName"?
standard-attributes>
standard-elements
?
+
?
+
The activity plays a role in the lifecycle of a business process. The only way to instantiate a business process in WS-BPEL is to annotate a activity (or a
activity) with the createInstance attribute set to "yes" (see section 11.5. Selective Event Processing – Pick for a variant). The default value of this attribute is "no". A start activity is a or
activity that is annotated with a createInstance="yes" attribute, or an child element. In order for the child element to qualify as a start activity, it MUST exhibit the behavior of receiving an inbound message. [SA00056] Non-start activities except , , or activities MUST have a control dependency on a start activity (see section 12.5.2. Default Compensation Order for the definition of a control dependency). If an does not have a control dependency on a start activity then the child element MUST be a structured activity containing the start activity. This structured activity MUST be consistent with the WS-BPEL process instantiation model, that is, it MUST not be a repeatable activity. If an child element is itself a start activity or contains a start activity then the namespace of the child element MUST be declared with mustUnderstand="yes". For other semantic constraints, see section 5.3. Language Extensibility. The logical order of performing activities is determined by static analysis. For an explanation of the messageExchange attribute, see the activity description in section 10.4.1. Message Exchanges.
It is permissible to have multiple start activities. An initial start activity is the start activity that caused a particular process instance to be instantiated. As specified in section 12. Scopes, the initial start activity MUST complete execution before any other start activities are allowed to execute. This allows any inbound message used in start activities to create the process instance since the order in which these messages arrive is unpredictable. [SA00057] If a process has multiple start activities with correlation sets then all such activities MUST share at least one common correlation set and all common correlation sets defined on all the activities MUST have the value of the initiate attribute be set to "join" (see section 9. Correlation). Conforming implementations MUST ensure that only one of the inbound messages that match a single process instance actually instantiate the business process. (It will usually be the first one to arrive, but this is implementation dependent) Other incoming messages in the concurrent initial set MUST be delivered to the corresponding activities in the already created instance.
The following example is not allowed, since the activity is not a start activity:
The following example is allowed, since the activity will not be performed prior to or simultaneously with the activity:
...
[SA00058] In a or activity, the variable referenced by the variable attribute MUST be a messageType variable whose QName matches the QName of the input (for ) or output (for ) message type used in the operation, except as follows: if the WSDL operation uses a message containing exactly one part which itself is defined using an element, then a WS-BPEL variable of the same element type as used to define the part MAY be referenced by the variable attribute of the or activity. The result of using a WS-BPEL variable in the previously defined circumstance MUST be equivalent to declaring an anonymous temporary WSDL message variable based on the associated WSDL message type. The copying of the element data between the anonymous temporary WSDL message variable and the element variable acts as a single virtual with one operation whose keepSrcElementName attribute is set to "yes". The virtual MUST follow the same semantics and use the same faults as a real . In the case of a activity, the incoming part’s value will be used to set the value of the variable referenced by the variable attribute. In the case of a activity the value of the variable referenced by the variable attribute will be used to set the value of the part in the anonymous temporary WSDL message variable that is sent out. In the case of a sending a fault, the same logic applies.
The element in a activity is used as an alternative to indicate that the data from a received message is to be directly copied to WS-BPEL variables from a corresponding anonymous WSDL message variable. Similarly, the element is used as an alternative to have data from WS-BPEL variables directly copied into an anonymous WSDL message used by the activity (see section 10.3.1. Mapping WSDL Message Parts for rules on the use of these two elements).
A is a blocking activity in that it will not complete until a matching message is received by the process instance. A business process instance MUST NOT simultaneously enable two or more activities for the same partnerLink, portType, operation and correlationSet(s) (including WS-BPEL processor-specific correlation). If during the execution of a business process instance, two or more receive activity instances for the same partnerLink, operation and correlationSet(s) are simultaneously enabled, then the standard fault bpel:conflictingReceive MUST be thrown (note bpel:conflictingReceive differs from bpel:conflictingRequest, see section 10.4.1. Message Exchanges). There may be receive activity instances on an operation where the partnerLink and correlationSet(s) are different, yet indistinguishable to a WS-BPEL processor at runtime. In these cases, a WS-BPEL processor SHOULD throw a bpel:conflictingReceive fault. If a business process instance simultaneously enables two or more IMAs for the same partnerLink, portType, operation but different correlationSet(s), and the correlations of multiple of these activities match an incoming request message, then the bpel:ambiguousReceive standard fault MUST be thrown by all IMAs whose correlation set(s) match the incoming message. For the purpose of these constraints, an clause in a
and an event handler are equivalent to a (see sections 11.5. Selective Event Processing – Pick and 12.7.1. Message Events).
Race conditions may occur in a business process execution. Messages that target a particular process instance may arrive before the corresponding activity is started. For example, consider a process that receives a series of messages in a loop where all the messages use the same correlation. At runtime, the messages will arrive independent of the iterations of the loop. The fact that the correlation is already initiated, however, should enable the runtime engine and messaging platform to recognize that these messages are correlated to the process instance, and handle those messages appropriately. Another example is a process that may invoke a remote service then initiate a correlation set for an expected callback message. For a variety of reasons, the callback message may arrive before the corresponding activity is started. The correlation data in the arriving message should enable the engine to recognize that the message is targeted for this process instance. Process engines MAY employ different mechanisms to handle such race conditions. This specification does not mandate any specific mechanism. Details of message delivery mechanisms are outside of the scope of this specification. However, a WS-BPEL processor should deliver messages to the process instance according to the quality of service of the underlying message delivery and transport mechanisms. For the purposes of handling race conditions, an clause in a
and an event handler are equivalent to a receive (see sections 11.5. Selective Event Processing – Pick and 12.7.1. Message Events).
The activity is used to send a response to a request previously accepted through an inbound message activity such as the activity. These responses are only meaningful for request-response interactions. A one-way “response” can be sent by invoking the corresponding one-way operation on the partnerLink. A activity may specify a variable attribute that references the variable that contains the message data to be sent. If a WSDL message definition does not contain any parts, then the associated variable attribute MAY be omitted, [SA00047] and the construct MUST be omitted. The syntax and semantics of the elements as used on the activity are the same as specified in section 10.3.1. Mapping WSDL Message Parts for the activity, [SA00059] including the restriction that if elements are used on a activity then the variable attribute MUST NOT be used on the same activity.
portType="QName"? operation="NCName"
variable="BPELVariableName"?
faultName="QName"?
messageExchange="NCName"?
standard-attributes>
standard-elements
?
+
?
+
The activity has two potential forms. First, in a normal response, the faultName attribute is not used and the variable attribute (or its equivalent elements), when present, will indicate a variable with the response message. Second, when the response indicates a fault, the faultName attribute is used and the variable attribute (or its equivalent elements), when present, will indicate a variable for the corresponding fault. The faultName attribute SHOULD refer to a fault defined in the operation used in the activity and the variable SHOULD match the message type associated with the referenced fault as well (note: the matching semantics here refer to points #1 and #2 in related matching rules in section 12.5. Fault Handlers). WS-BPEL treats faults based on abstract WSDL 1.1 operation definitions. This limits the ability of a WS-BPEL process to determine the information transmitted when faults are returned over a SOAP binding (see section 10.3. Invoking Web Service Operations – Invoke).
10.4.1. Message Exchanges
The optional messageExchange attribute is used to disambiguate the relationship between inbound message activities (IMA) and activities. The explicit use of messageExchange is needed only where the execution can result in multiple IMA- pairs (e.g. - pair) on the same partnerLink and operation being executed simultaneously. [SA00060] In these cases, the process definition MUST explicitly mark the pairing-up relationship.
A activity is associated with an IMA, such as, , and based on the tuple partnerLink, operation, and messageExchange. [SA00061] The name used in the optional messageExchange attribute MUST resolve to a messageExchange declared in a scope (where the process is considered the root scope) which encloses the activity and its corresponding IMA. This resolution follows the same scoping rules as correlation set resolution.
An open IMA describes the state of a Web Service operation from the point that a request-response IMA starts execution until an associated activity completes successfully. If a activity faults, the IMA is still open and another activity MAY be attempted, for example from a fault handler. It is illegal to have multiple simultaneous open IMAs, with the same partnerLink, operation and messageExchange tuple. A WS-BPEL processor MUST throw a bpel:conflictingRequest fault when a conflicting IMA begins execution. It is legal to use the same messageExchange in multiple simultaneously open IMAs as long as the combination of partnerLink and operation on the IMAs are all different from each other. Note that bpel:conflictingRequest is semantically different from bpel:conflictingReceive, because it is possible to create the conflictingRequest by consecutively receiving the same request on a specific partnerLink, operation and messageExchange tuple, while conflictingReceive fault is not triggered (see section 10.4. Providing Web Service Operations – Receive and Reply above for conflictingReceive semantics).
If a activity cannot be associated with an open IMA by matching the tuple partnerLink, operation, and messageExchange then a WS-BPEL processor MUST throw a bpel:missingRequest fault on the activity. Since conflicting requests are rejected at the time the IMA begins execution there cannot be more than one corresponding IMA at the time a activity is executed.
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 open IMA using a partner link or message exchange declared in a completing or completed is termed as an orphaned IMA. Detection of orphaned IMAs will cause a bpel:missingReply fault to be thrown. Orphaned IMAs are defined and discussed in further detail in section 12.2. Message Exchange Handling. Accordingly, if a process instance completes with one or more open IMAs then a bpel:missingReply fault MUST be thrown as well.
If the messageExchange attribute is not specified on an IMA or then the activity's messageExchange is automatically associated with a default messageExchange with no name. Default messageExchange's are implicitly declared by the
and the immediate child scopes of and the parallel form of . Other occurrences of activities do not provide a default messageExchange. Default messageExchange instances, just like non-default messageExchange elements, are created each time the scope declaring the default messageExchange is executed. For example each time an is executed (i.e. when a new message arrives for processing) it creates a new default messageExchange instance associated with each instance. This allows a request-response event handler to receive messages in parallel without faulting or explicitly specifying a messageExchange. Similarly it allows the use of - or - pairs in the parallel form of without the need to explicitly specify a messageExchange.
10.5. Updating Variables and Partner Links – Assign
Variable update occurs through the activity, which is described in section 8.4. Assignment.
10.6. Signaling Internal Faults – Throw
The activity is used when a business process needs to signal an internal fault explicitly. A fault MUST be identified with a QName (see section 10.3. Invoking Web Service Operations). The activity provides the name for the fault, and can optionally provide data with further information about the fault. A fault handler can use such data to handle the fault and to populate any fault messages that need to be sent to other services.
WS-BPEL does not require fault names to be defined prior to their use in a activity. This provides a lightweight mechanism to introduce business-process faults. A fault name defined in a business process, a WSDL definition or a WS-BPEL standard fault can be directly used, by using an appropriate QName, as the value of the faultName attribute and providing a variable with the fault data if required.
standard-attributes>
standard-elements
A simple example of a throw activity that does not provide fault data is:
faultName="FLT:OutOfStock" />
10.7. Delayed Execution – Wait
The activity specifies a delay for a certain period of time or until a certain deadline is reached (see section 8.3. Expressions for the grammar of duration expressions and deadline expressions). If the specified duration value in is zero or negative, or a specified deadline in has already been reached or passed, then the activity completes immediately.
standard-elements
(
duration-expr
|
deadline-expr
)
A typical use of this activity is to invoke an operation at a certain time (in this example a constant, but more typically an expression dependent on process state):
There is often a need to use an activity that does nothing, for example when a fault needs to be caught and suppressed. The activity is used for this purpose. Another use of is to provide a synchronization point in a .
standard-elements
10.9. Adding new Activity Types – ExtensionActivity
A WS-BPEL process definition can include new activities, which are not defined by this specification, by placing them inside the element. These activities are known as extension activities. The contents of an element MUST be a single element qualified with a namespace different from WS-BPEL namespace. That single element MUST make available WS-BPEL's standard-attributes and standard-elements. If the element contained within the element is not recognized by the WS-BPEL processor and is not subject to a mustUnderstand="yes" requirement from an extension declaration then the unknown activity MUST be treated as if it were an activity that has the standard-attributes and standard-elements of the unrecognized element; all its other attributes and child elements are ignored. The standard-attributes and standard-elements MUST be treated as defined by this specification, whether the extension is understood or not.
Static analysis is performed by a WS-BPEL processor after it ignores the non-standard-attributes and non-standard-elements of an unrecognized extension activity not subject to mustUnderstand="yes". It may detect violations of some WS-BPEL required semantics. For example:
At least one start activity MUST be present – if an has a nested start activity, then a requirement could be broken if non-standard child constructs of the are ignored.
Links MUST have exactly one source and target – if an has a nested activity that is the source or target of a link that crosses the boundary, then a requirement would be broken if non-standard child constructs of the are ignored.
An MAY be also a structured activity, that means it contains other activities. If an allows a nested activity, its corresponding extension declaration SHOULD be subject to mustUnderstand="yes".
<anyElementQName standard-attributes>
standard-elements
anyElementQName>
10.10. Immediately Ending a Process – Exit
The activity is used to immediately end the business process instance. All currently running activities MUST be ended immediately without involving any termination handling, fault handling, or compensation behavior.
standard-elements
10.11. Propagating Faults – Rethrow
The activity is used in fault handlers to rethrow the fault they caught, i.e. the fault name and, where present, the fault data of the original fault. It can be used only within a fault handler ( and ). Modifications to the fault data MUST be ignored by . For example, if the logic in a fault handler modifies the fault data and then call , the original fault data would be rethrown and not the modified fault data. Similarly if a fault is caught using the shortcut that allows message type faults with one part defined using an element to be caught by fault handlers looking for the same element type, then a would rethrow the original message type data (see section 12.5. Fault Handlers).
Yüklə 2.65 Mb.