Web Services Business Process Execution Language Version 0 Public Review Draft 02, 20 November, 2006

səhifə	7/23
tarix	27.06.2016
ölçüsü	2.65 Mb.

1 2 3 4 5 6 7 8 9 10 ... 23

8. Data Handling

Business processes specify stateful interactions involving the exchange of messages between partners. The state of a business process includes the messages that are exchanged as well as intermediate data used in business logic and in composing messages sent to partners. The maintenance of the state of a business process requires the use of variables. Furthermore, the data from the state needs to be extracted and combined in interesting ways to control the behavior of the process, which requires data expressions. Finally, state update requires a notion of assignment. WS-BPEL provides these features for XML data types and WSDL message types. The XML family of standards in these areas is still evolving, and using the process-level attributes for query and expression languages allows for the incorporation of future standards.

Both Executable and Abstract Processes are permitted to use the full power of data selection and assignment. Executable Processes are not permitted to use opaque expressions, while Abstract Processes are permitted to use them to hide behavior. Detailed differences are specified in the following sections.

8.1. Variables

Variables provide the means for holding messages that constitute a part of the state of a business process. The messages held are often those that have been received from partners or are to be sent to partners. Variables can also hold data that are needed for holding state related to the process and never exchanged with partners.

WS-BPEL uses three kinds of variable declarations: WSDL message type, XML Schema type (simple or complex), and XML Schema element. The syntax of the declaration is:

messageType="QName"?

type="QName"?

element="QName"?>+

from-spec?

An example of a declaration using a message type declared in a WSDL document with the targetNamespace "http://example.com/orders":

name="orderDetails"

messageType="ORD:orderDetails" />

Each is declared within a and is said to belong to that scope. Variables that belong to the global process scope are called global variables. Variables may also belong to other, non-global scopes, and such variables are called local variables. Each variable is visible only in the scope in which it is defined and in all scopes nested within the scope to which it belongs. Thus, global variables are visible throughout the process. It is possible to hide a variable declared in an outer scope by declaring a variable with an identical name in an inner scope. These rules are exactly analogous to those in programming languages with lexical scoping of variables.

[SA00023] The name of a MUST be unique among the names of all variables defined within the same immediately enclosing scope. This requirement MUST be statically enforced. [SA00024] Variable names are NCNames (as defined in XML Schema specification) but in addition they MUST NOT contain the “.” character. This restriction is necessary because the “.” character is used as a delimiter in WS-BPEL's default binding to XPath 1.0 (i.e. the binding identified by "urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"). The delimiter separates the WS-BPEL message type variable name and the name of one of its WSDL message parts. The concatenation of the WSDL message variable name, the delimiter and the WSDL part name is used as an XPath variable reference which manifests the XML Infoset of the corresponding WSDL message part.

In this specification, the type BPELVariableName is used to describe the name of a . It is derived from the XML Schema NCName as described below. The type BPELVariableNames is used to describe a list of variable names.

Variable access follows common lexical scoping rules. A variable resolves to the nearest enclosing scope, regardless of the type of the variable, except as described in 12.7. Event Handlers. If a local variable has the same name as a variable defined in an enclosing scope, the local variable will be used in local assignments and/or the bpel:getVariableProperty function (as defined below).

[SA00025] The messageType, type or element attributes are used to specify the type of a variable. Exactly one of these attributes MUST be used. Attribute messageType refers to a WSDL message type definition. Attribute type refers to an XML Schema type (simple or complex). Attribute element refers to an XML Schema element.

Using [Infoset] terminology, the infoset for a WS-BPEL element variable consists of a Document Information Item (DII) that contains exactly one child, an Element Information Item (EII) which is referenced by the document element property. The EII is the value of the element variable.

If a WS-BPEL implementation chooses to manifest a simple type variable as an XML infoset, the infoset SHOULD consist of a DII that contains exactly one child, which is an EII referenced by the document element property. The properties of the document element, specifically the namespace name and local name properties, are undefined by this specification. An implementation MUST specify a namespace name/local name value. However the children of the document element MUST exclusively consist of a series of Character Information Items (CIIs) that represent the simple type value. A WS-BPEL implementation MAY choose to map simple type variables to non-XML-infoset data-models defined in the expression/query language being used (e.g. Boolean in XPath 1.0).

The infoset for a complex type variable consists of a DII that contains exactly one child, which is an EII referenced by the document element property. The properties of the document element, specifically the namespace name and local name properties, are undefined by this specification. An implementation MUST specify a namespace name/local name value. However the children of the document element MUST exclusively consist of the complex type values assigned to the variable.

In order to simplify data access, WSDL parts of WSDL message variables are manifested in WS-BPEL as infosets, one infoset per WSDL message part. WS-BPEL engines MUST use the following algorithm when manifesting a WSDL message part as an infoset:
for each part in the WSDL message definition,

Step 1 – Create a synthetic DII which has no children other than those specified in step 2.

Step 2a – If the WSDL message part is defined using the type attribute then create an EII as a child of the document element. The local name and namespace name of the newly created EII are determined by the WS-BPEL processor and are not specified by this document. The handling of this EII is similar to how WS-BPEL handles the containers for complex and simple type XML variables. The contents of the new EII are required to conform to the contents defined by the referenced type definition.

Step 2b – If the WSDL message part is defined using the element attribute then create an EII as a child of the document element which manifests the element defined by the referenced type definition.

The previous models are conceptual; they define how WS-BPEL submits and retrieves XML variable values using infoset definitions. WS-BPEL processors are not required to implement an infoset model. Regardless of how the variable binding is handled, the end result SHOULD duplicate the behavior defined using the infoset model above. For example, a WS-BPEL implementation may choose to bind a simple type WS-BPEL variable of type xsd:string directly to a string object in XPath 1.0. The choice of mapping MUST be consistently applied to variables and WSDL message part values of the same XML Schema type. For example, if a xsd:string variable is manifested as a string object, a xsd:string message part MUST be manifested as a string object also. For detailed definition of manifestation of WS-BPEL variables in XPath 1.0, see section 8.2.2 Binding WS-BPEL Variables In XPath 1.0.

In summary, a WS-BPEL variable is manifested as XML Infoset items in one of the following ways:

a single XML infoset item: e.g. an element or complex type variable or a WSDL message part
a sequence of CIIs for simple type data: e.g. used to manifest a string (these items may be manifested as a non XML infoset item when needed, e.g. Boolean)

A variable can optionally be initialized by using an in-line from-spec. From-spec is defined in section 8.4. Conceptually the in-line variable initializations are modeled as a virtual activity that contains a series of virtual activities, one for each variable being initialized, in the order they are listed in the variable declarations. The virtual activities each contain a single virtual whose from-spec is as given in the variable initialization and the to-spec points to the variable being created.

[SA00026] Variable initialization logic contained in scopes that contain or whose children contain a start activity MUST only use idempotent functions in the from-spec. The use of idempotent functions allows for all the values for such variables to be pre-computed and re-used on each process instance.

A global variable is in an uninitialized state at the beginning of a process. A local variable is in an uninitialized state at the start of the scope it belongs to. Note that non-global scopes in general start and complete their behavior more than once in the lifetime of the process instance they belong to. Variables can be initialized by a variety of means including assignment and receipt of a message. Variables can be partially initialized with property assignment or when some but not all parts in the message type of the variable are assigned values.

An attempt during process execution to read a variable or, in the case of a message type variable, a part of a variable before it is initialized MUST result in the standard bpel:uninitializedVariable fault. This includes the and activity, where the presence of an uninitialized part also results in the standard fault bpel:uninitializedVariable.

Variable Validation

Values stored in variables can be mutated during the course of process execution. The activity can be used to ensure that values of variables are valid against their associated XML data definition, including XML Schema simple type, complex type, element definition and XML definitions of WSDL parts. The activity has a variables attribute, listing the variables to validate. The attribute accepts one or more variable names (BPELVariableName), separated by whitespaces. The syntax of the validate activity is:

standard-elements

When one or more variables are invalid against their corresponding XML definition, a standard fault of bpel:invalidVariables fault MUST be thrown.

A WS-BPEL implementation MAY provide a mechanism to turn on/off any explicit validation, for example, the activity.

A WS-BPEL implementation MAY validate incoming and outgoing messages during the execution of message related activities, e.g., , ,

, and activities. If such Schema validation is enabled and messages are invalid, "bpel:invalidVariables" fault SHOULD be thrown during those message activities.

1 2 3 4 5 6 7 8 9 10 ... 23