WS-BPEL takes it as a general principle that conformant implementations MUST perform basic static analysis listed in Appendix B to detect and reject process definitions that fail any of those static analysis checks. Please note that such analysis might in some cases prevent the use of processes that would not, in fact, create situations with errors, either in specific uses or in any use. For example, a WS-BPEL implementation will reject a process with activity referring to an undefined variable, where the activity may not be actually reached during execution of the process.
A WS-BPEL implementation MAY perform extra static analysis checking beyond the basic static analysis required by this specification to signal warnings or even reject process definitions. Such an implementation SHOULD be configurable to disable these non-specified static analysis checks.
5. Defining a Business Process
5.1. Initial Example
Before describing the structure of business processes in detail, this section presents a simple example of a WS-BPEL process for handling a purchase order. The aim is to introduce the most basic structures and some of the fundamental concepts of the language.
The operation of the process is very simple, and is represented in Figure 1: Purchase Order Process Outline. Dotted lines represent sequencing. Free grouping of sequences represents concurrent sequences. Solid arrows represent control links used for synchronization across concurrent activities. Note that this is not meant to be a definitive graphical notation for WS-BPEL processes. It is used here informally as an aid to understanding.
On receiving the purchase order from a customer, the process initiates three paths concurrently: calculating the final price for the order, selecting a shipper, and scheduling the production and shipment for the order. While some of the processing can proceed concurrently, there are control and data dependencies between the three paths. In particular, the shipping price is required to finalize the price calculation, and the shipping date is required for the complete fulfillment schedule. When the three concurrent paths are completed, invoice processing can proceed and the invoice is sent to the customer.
Figure 1: Purchase Order Process - Outline
The WSDL port type offered by the service to its customers (purchaseOrderPT) is shown in the following WSDL document. Other WSDL definitions required by the business process are included in the same WSDL document for simplicity; in particular, the port types for the Web Services providing price calculation, shipping selection and scheduling, and production scheduling functions are also defined there. Observe that there are no bindings or service elements in the WSDL document. A WS-BPEL process is defined by referencing only the port types of the services involved in the process, and not their possible deployments. Defining business processes in this way allows the reuse of business process definitions over multiple deployments of compatible services.
The
s included at the bottom of the WSDL document represent the interaction between the purchase order service and each of the parties with which it interacts (see section 6. Partner Link Types, Partner Links, and Endpoint References).
s can be used to represent dependencies between services, regardless of whether a WS-BPEL business process is defined for one or more of those services. Each
defines up to two "role" names, and lists the port types that each role must support for the interaction to be carried out successfully. In this example, two
s, "purchasingLT" and "schedulingLT", list a single role because, in the corresponding service interactions, one of the parties provides all the invoked operations: The "purchasingLT"
represents the connection between the process and the requesting customer, where only the purchase order service needs to offers a service operation ("sendPurchaseOrder"); the "schedulingLT"
represents the interaction between the purchase order service and the scheduling service, in which only operations of the latter are invoked. The two other
s, "invoicingLT" and "shippingLT", define two roles because both the user of the invoice calculation and the user of the shipping service (the invoice or the shipping schedule) must provide callback operations to enable notifications to be sent ("invoiceCallbackPT" and "shippingCallbackPT" port types).
The business process for the order service is defined next. There are four major sections in this process definition. Note that the example provides a simple case. In order to complete it, additional elements may be needed such as .
The
section defines the different parties that interact with the business process in the course of processing the order. The four
definitions shown here correspond to the sender of the order (customer), as well as the providers of price (invoicing provider), shipment (shipping provider), and manufacturing scheduling services (scheduling provider). Each
is characterized by a partnerLinkType and either one or two role names. This information identifies the functionality that must be provided by the business process and by the partner service for the relationship to succeed, that is, the port types that the purchase order process and the partner need to implement.
The section defines the data variables used by the process, providing their definitions in terms of WSDL message types, XML Schema types (simple or complex), or XML Schema elements. Variables allow processes to maintain state between message exchanges.
The section contains fault handlers defining the activities that must be performed in response to faults resulting from the invocation of the assessment and approval services. In WS-BPEL, all faults, whether internal or resulting from a service invocation, are identified by a qualified name. In particular, each WSDL fault is identified in WS-BPEL by a qualified name formed by the target namespace of the WSDL document in which the relevant port type and fault are defined, and the NCName of the fault.
The rest of the
definition contains the description of the normal behavior for handling a purchase request. The major elements of this description are explained in the section following the process definition.
This section provides a quick summary of the WS-BPEL syntax. It provides only a brief overview; the details of each language construct are described in the rest of this document.
queryLanguage. This attribute specifies the query language used in the process for selection of nodes in assignment. The default value for this attribute is: "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0", which represents the usage of [XPath 1.0] within WS-BPEL 2.0.
expressionLanguage. This attribute specifies the expression language used in the
. The default value for this attribute is: "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0", which represents the usage of [XPath 1.0] within WS-BPEL 2.0.
suppressJoinFailure. This attribute determines whether the joinFailure fault will be suppressed for all activities in the process. The effect of the attribute at the process level can be overridden by an activity using a different value for the attribute. The default for this attribute is "no" at the process level. When this attribute is not specified for an activity, it inherits its value from its closest enclosing activity or from the
if no enclosing activity specifies this attribute.
exitOnStandardFault. If the value of this attribute is set to “yes”, then the process MUST exit immediately as if an activity has been reached, when a WS-BPEL standard fault other than bpel:joinFailure is encountered1. If the value of this attribute is set to “no”, then the process can handle a 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
.
[SA00003] If the value of exitOnStandardFault of a or
is set to “yes”, then a fault handler that explicitly targets the WS-BPEL standard faults MUST NOT be used in that scope. A process definition that violates this condition MUST be detected by static analysis and MUST be rejected by a conformant implementation.
The syntax of Abstract Process has its own distinct target namespace. Additional top-level attributes are defined for Abstract Processes.
The value of the queryLanguage and expressionLanguage attributes on the
element are global defaults and can be overridden on specific constructs, such as of a activity, as defined later in this specification. In addition, the queryLanguage attribute is also available for use in defining WS-BPEL es in WSDL. WS-BPEL processors MUST:
statically determine which languages are referenced by queryLanguage or expressionLanguage attributes either in the WS-BPEL process definition itself or in any WS-BPEL property definitions in associated WSDLs and
[SA00004] if any referenced language is unsupported by the WS-BPEL processor then the processor MUST reject the submitted WS-BPEL process definition.
Note that: construct may be added to virtually all WS-BPEL constructs as the formal way to annotate processes definition with human documentation. Examples of construct can be found in the previous sections. Detailed description of is provided in the next section 5.3. Language Extensibility.
Each business process has one main activity.
A WS-BPEL activity can be any of the following:
The syntax of each of these elements is described in the following paragraphs.
The activity allows the business process to wait for a matching message to arrive. The activity completes when the message arrives. The portType attribute on the activity is optional. [SA00005] If the portType attribute is included for readability, the value of the portType attribute MUST match the portType value implied by the combination of the specified partnerLink and the role implicitly specified by the activity (see also partnerLink description in the next section). The optional messageExchange attribute is used to associate a activity with a activity.
portType="QName"?
operation="NCName"
variable="BPELVariableName"?
createInstance="yes|no"?
messageExchange="NCName"?
standard-attributes>
standard-elements
?
+
?
+
The activity allows the business process to send a message in reply to a message that was received by an inbound message activity (IMA), that is, , , or . The combination of an IMA and a forms a request-response operation on a WSDL portType for the process. The portType attribute on the activity is optional. If the portType attribute is included for readability, the value of the portType attribute MUST match the portType value implied by the combination of the specified partnerLink and the role implicitly specified by the activity (see also partnerLink description in the next section). The optional messageExchange attribute is used to associate a activity with an IMA.
portType="QName"?
operation="NCName"
variable="BPELVariableName"?
faultName="QName"?
messageExchange="NCName"?
standard-attributes>
standard-elements
?
+
?
+
The activity allows the business process to invoke a one-way or request-response operation on a portType offered by a partner. In the request-response case, the invoke activity completes when the response is received. The portType attribute on the activity is optional. If the portType attribute is included for readability, the value of the portType attribute MUST match the portType value implied by the combination of the specified partnerLink and the role implicitly specified by the activity (see also partnerLink description in the next section).
portType="QName"?
operation="NCName"
inputVariable="BPELVariableName"?
outputVariable="BPELVariableName"?
standard-attributes>
standard-elements
?
pattern="request|response|request-response"? />+
faultVariable="BPELVariableName"?
faultMessageType="QName"?
faultElement="QName"?>*
activity
?
activity
?
activity
?
+
?
+
The activity is used to update the values of variables with new data. An construct can contain any number of elementary assignments, including assign elements or data update operations defined as extension under other namespaces.
standard-elements
(
from-spec
to-spec
|
assign-element-of-other-namespace
)+
The activity is used to validate the values of variables against their associated XML and WSDL data definition. The construct has a variables attribute, which points to the variables being validated.
standard-elements
The activity is used to generate a fault from inside the business process.
faultVariable="BPELVariableName"?
standard-attributes>
standard-elements
The activity is used to wait for a given time period or until a certain point in time has been reached. Exactly one of the expiration criteria MUST be specified.
standard-elements
(
duration-expr
|
deadline-expr
)
The activity is a "no-op" in a business process. This is useful for synchronization of concurrent activities, for instance.
standard-elements
The activity is used to define a collection of activities to be performed sequentially in lexical order.
standard-elements
activity+
The activity is used to select exactly one activity for execution from a set of choices.
standard-elements
bool-expr
activity
*
bool-expr
activity
?
activity
The activity is used to define that the child activity is to be repeated as long as the specified is true.
standard-elements
bool-expr
activity
The activity is used to define that the child activity is to be repeated until the specified becomes true. The is tested after the child activity completes. The activity is used to execute the child activity at least once.
standard-elements
activity
bool-expr
The activity iterates its child scope activity exactly N+1 times where N equals the minus the . If parallel="yes" then this is a parallel where the N+1 instances of the enclosed activity SHOULD occur in parallel. In essence an implicit flow is dynamically created with N+1 copies of the 's activity as children. A may be used within the to allow the activity to complete without executing or finishing all the branches specified.
standard-attributes>
standard-elements
unsigned-integer-expression
unsigned-integer-expression
?
successfulBranchesOnly="yes|no"?>?
unsigned-integer-expression
...
The
activity is used to wait for one of several possible messages to arrive or for a time-out to occur. When one of these triggers occurs, the associated child activity is performed. When the child activity completes then the
activity completes.
The portType attribute on the activity is optional. If the portType attribute is included for readability, the value of the portType attribute MUST match the portType value implied by the combination of the specified partnerLink and the role implicitly specified by the activity. The optional messageExchange attribute is used to associate a activity with a activity.
standard-elements
portType="QName"?
operation="NCName"
variable="BPELVariableName"?
messageExchange="NCName"?>+
?
+
?
+
activity
*
(
duration-expr
|
deadline-expr
)
activity
The activity is used to specify one or more activities to be performed concurrently. can be used within a to define explicit control dependencies between nested child activities.
standard-elements
?
+
activity+
The activity is used to define a nested activity with its own associated
, , , , , , , and .
standard-attributes>
standard-elements
?
... see above under
for syntax ...
?
... see above under
for syntax ...
?
... see above under
for syntax ...
?
... see above under
for syntax ...
?
... see above under
for syntax ...
?
...
?
...
?
... see above under
for syntax ...
activity
The activity is used to start compensation on a specified inner scope that has already completed successfully. [SA00007] This activity MUST only be used from within a fault handler, another compensation handler, or a termination handler.
standard-elements
The activity is used to start compensation on all inner scopes that have already completed successfully, in default order. [SA00008] This activity MUST only be used from within a fault handler, another compensation handler, or a termination handler.
standard-elements
The activity is used to immediately end a business process instance within which the activity is contained.
standard-elements
The activity is used to rethrow the fault that was originally caught by the immediately enclosing fault handler. [SA00006] The activity MUST only be used within a fault handler (i.e. and elements). This syntactic constraint MUST be statically enforced.
standard-elements
The element is used to extend WS-BPEL by introducing a new activity type. The contents of an element MUST be a single element that MUST make available WS-BPEL's standard-attributes and standard-elements.
<anyElementQName standard-attributes>
standard-elements
anyElementQName>
The "standard-attributes" referenced above are:
name="NCName"? suppressJoinFailure="yes|no"?
where the default values are as follows:
name: No default value (that is, the default is unnamed)
suppressJoinFailure: When this attribute is not specified for an activity, it inherits its value from its closest enclosing activity or from the process if no enclosing activity specifies this attribute.
The "standard-elements" referenced above are:
?
?
bool-expr
+
?
+
?
bool-expr
5.3. Language Extensibility
WS-BPEL supports extensibility by allowing namespace-qualified attributes to appear on any WS-BPEL element and by allowing elements from other namespaces to appear within WS-BPEL defined elements. This is allowed in the XML Schema specifications for WS-BPEL.
Extensions are either mandatory or optional (see section 14. Extension Declarations). [SA00009] In the case of mandatory extensions not supported by a WS-BPEL implementation, the process definition MUST be rejected. Optional extensions not supported by a WS-BPEL implementation MUST be ignored.
In addition, WS-BPEL provides two explicit extension constructs: and . Specific rules for these constructs are described in sections 8.4. Assignment and 10.9. Adding new Activity Types – ExtensionActivity.
Extensions MUST NOT contradict the semantics of any element or attribute defined by the WS-BPEL specification.
Extensions are allowed in WS-BPEL constructs used in WSDL definitions, such as
, , and . The same syntax pattern and semantic rules for extensions of WS-BPEL constructs are applied to these extensions as well. For the WSDL definitions transitively referenced by a WS-BPEL process, extension declaration directives of this WS-BPEL process are applied to all extensions used in WS-BPEL constructs in these WSDL definitions (see section 14. Extension Declarations).
The optional construct is applicable to any WS-BPEL extensible construct. Typically, the contents of are for human targeted annotation. Example types for those content are: plain text, HTML and XHTML. Tool-implementation specific information (e.g. the graphical layout details) should be added through elements and attributes of other namespaces, using the general WS-BPEL extensibility mechanisms.
5.4. Document Linking
A WS-BPEL process definition relies on XML Schema and WSDL 1.1 for the definition of datatypes and service interfaces. Process definitions also rely on other constructs such as partner link types, variable properties and property aliases (defined later in this specification) which are defined within WSDL 1.1 documents using the WSDL 1.1 language extensibility feature.
location="anyURI"?
importType="anyURI" />*
The element is used within a WS-BPEL process to declare a dependency on external XML Schema or WSDL definitions. Any number of elements may appear as children of the
element. Each element contains one mandatory and two optional attributes.
namespace. The namespace attribute specifies an absolute URI that identifies the imported definitions. This attribute is optional. An import element without a namespace attribute indicates that external definitions are in use which are not namespace qualified. [SA00011] If a namespace is specified then the imported definitions MUST be in that namespace. [SA00012] If no namespace is specified then the imported definitions MUST NOT contain a targetNamespace specification. If either of these rules are not met then the process definition MUST be rejected by a conforming WS-BPEL implementation. The namespace http://www.w3.org/2001/XMLSchema is imported implicitly. Note, however, that there is no implicit XML Namespace prefix defined for http://www.w3.org/2001/XMLSchema.
location. The location attribute contains a URI indicating the location of a document that contains relevant definitions. The location URI may be a relative URI, following the usual rules for resolution of the URI base (XML Base and RFC 2396). The location attribute is optional. An element without a location attribute indicates that external definitions are used by the process but makes no statement about where those definitions may be found. The location attribute is a hint and a WS-BPEL processor is not required to retrieve the document being imported from the specified location.
importType. The mandatory importType attribute identifies the type of document being imported by providing an absolute URI that identifies the encoding language used in the document. [SA00013] The value of the importType attribute MUST be set to "http://www.w3.org/2001/XMLSchema" when importing XML Schema 1.0 documents, and to "http://schemas.xmlsoap.org/wsdl/" when importing WSDL 1.1 documents. Other importType URI values MAY be used here.
Observe that according to these rules, it is permissible to have an element without namespace and location attributes, and only containing an importType attribute. Such an element indicates that external definitions of the indicated type are in use which are not namespace qualified, and makes no statement about where those definitions may be found.
[SA00010] A WS-BPEL process definition MUST import all XML Schema and WSDL definitions it uses. This includes all XML Schema type and element definitions, all WSDL port types and message types as well as and definitions used by the process. [SA00053], [SA00054] A WS-BPEL processor MUST verify that all message parts referenced by a , , , , and are found in their respective WSDL message definitions. In order to support the use of definitions from namespaces spanning multiple documents, a WS-BPEL process MAY include more than one import declaration for the same namespace and importType, provided that those declarations include different location values. elements are conceptually unordered. [SA00014] A WS-BPEL process definition MUST be rejected if the imported documents contain conflicting definitions of a component used by the importing process definition (as could be caused, for example, when the XSD redefinition mechanism is used).
Schema definitions defined in the types section of a WSDL document which is imported by a WS-BPEL process definition are considered to be effectively imported themselves and are available to the process for the purpose of defining XML Schema variables. However, documents (or namespaces) imported by an imported document (or namespace) MUST NOT be transitively imported by the WS-BPEL processor. In particular, this means that if an external item is used by a WS-BPEL process, then a document (or namespace) that defines that item MUST be directly imported by the process; observe however that this requirement does not limit the ability of the imported document itself to import other documents or namespaces. The following example clarifies some of the issues related to the lack of transitivity of imports.
Assume a document D1 defines a type called d1:Type. However, d1:Type's definition could depend on another type called d2:Type which is defined in document D2. D1 could include an import for D2 thus making d2:Type's definition available for use within the definition of d1:Type. If a WS-BPEL process refers to d1:Type it must import document D1. By importing D1 the WS-BPEL process can legally refer to d1:Type. But the WS-BPEL process could not refer to d2:Type even though D1 imports D2. This is because transitivity of import is not supported by WS-BPEL. Note, however, that D1 can still import D2 and d1:Type can still use d2:Type in its definition. In order to allow the WS-BPEL process to refer to d2:Type it would be necessary for the WS-BPEL process to directly import document D2.
5.5. The Lifecycle of an Executable Business Process
As noted in the introduction, the interaction model that is directly supported by WSDL is essentially a stateless client-server model of request-response or uncorrelated one-way interactions. WS-BPEL, builds on WSDL by assuming that all external interactions of the business process occur through Web Service operations. However, WS-BPEL business processes represent stateful long-running interactions in which each interaction has a beginning, defined behavior during its lifetime, and an end. For example, in a supply chain, a seller's business process might offer a service that begins an interaction by accepting a purchase order through an input message, and then returns an acknowledgement to the buyer if the order can be fulfilled. It might later send further messages to the buyer, such as shipping notices and invoices. The seller's business process remembers the state of each such purchase order interaction separately from other similar interactions. This is necessary because a buyer might be carrying on many simultaneous purchase processes with the same seller. In short, a WS-BPEL business process definition can be thought of as a template for creating business process instances.
The creation of a process instance in WS-BPEL is always implicit; activities that receive messages (that is, activities and
activities) can be annotated to indicate that the occurrence of that activity causes a new instance of the business process to be created. This is done by setting the createInstance attribute of such an activity to "yes". When a message is received by such an activity, an instance of the business process is created if it does not already exist (see sections 10.4. Providing Web Service Operations – Receive and Reply and 11.5. Selective Event Processing – Pick).
A start activity is a or a
activity annotated with a createInstance="yes" attribute. [SA00015] Each executable business process MUST contain at least one start activity (see section 10.4. Providing Web Service Operations – Receive and Reply for more details on start activities).
If more than one start activity exists in a process and these start activities contain then all such activities MUST share at least one common (see the example in section 9.2. Declaring and Using Correlation Sets).
If a process contains exactly one start activity then the use of is unconstrained. This includes a pick with multiple branches; each such branch can use different or no .
A business process instance ends either normally or abnormally. The process ends normally when the main activity and all event handler instances of the process complete without propagating any fault. The process ends abnormally if either:
a process level (explicit or default) fault handler completes without propagating any fault or
the execution of a process level fault handler itself faults (the effect of this particular case is similar to an activity) or
the process instance is explicitly ended by an activity (see section 10.10. Immediately Ending a Process – Exit).
5.6. Revisiting the Initial Example
In the purchaseOrderProcess example in section 5.1. Initial Example, the structure of the main activity of the process is defined by the outer element, which states that the three activities contained inside are performed in order. The customer request is received ( element), then processed (inside a section that enables concurrent behavior), and a reply message with the final approval status of the request is sent back to the customer (). Note that the and elements are matched respectively to the and
Yüklə 2.65 Mb.
