Ana səhifə

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


Yüklə 2.65 Mb.
səhifə8/23
tarix27.06.2016
ölçüsü2.65 Mb.
1   ...   4   5   6   7   8   9   10   11   ...   23

8.2 Usage of Query and Expression Languages


This section describes the relationship between Query/Expression languages and WS-BPEL from two different perspectives. The first perspective is WS-BPEL's view of the query/expression languages. That view is restricted to what information WS-BPEL will make available for use by the Query/Expression language. The second perspective is the Query/Expression language's view of WS-BPEL, specifically how XPath 1.0's execution context is initialized by WS-BPEL.

WS-BPEL provides an extensible mechanism for the language used in queries and expressions. The languages are specified by the queryLanguage and expressionLanguage attributes of the process element. WS-BPEL constructs that require or allow queries or expressions provide the ability to override the default query/expression language for individual queries/expressions. WS-BPEL implementations MUST support the use of [XPath 1.0] as the query and expression language. XPath 1.0 is indicated by the default value of the queryLanguage and expressionLanguage attribute, which is:

urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0

which represents the usage of XPath 1.0 within WS-BPEL 2.0.

If the execution of a query or an expression yields an unhandled language fault, the WS-BPEL standard fault bpel:subLanguageExecutionFault MUST be thrown.

8.2.1 Enclosing Elements


In order to describe the view that WS-BPEL provides to Query/Expression languages it is necessary to introduce a new term - Enclosing Element.

Definition (Enclosing Element). An Enclosing Element is defined as the parent element in the WS-BPEL process definition that contains the Query or Expression. In the following example, the element is the Enclosing Element.
...

$myVar/abc/def

...
The in-scope namespaces of the enclosing element are the namespaces visible to the Query/Expression language. (Note: XPath 1.0 does not have default namespace concept.)


The links, variables, partnerLinks, etc. that are visible to a Query/Expression language are defined based on the entities’ visibility to the activity that the Enclosing Element is contained within. Query/Expression languages need not manifest all the different objects. Only the objects in scope to the Enclosing Element’s enclosing activity SHOULD be visible from within the Query/Expression language.
Evaluation of a WS-BPEL expression or query will yield one of the following (here we use XPath 1.0 expressions as examples):


  • a single XML infoset item: e.g. $myFooVar/lines/line[2]

  • a collection of XML infoset items e.g. $myFooVar/lines/*

  • a sequence of CIIs for simple type data
    e.g. $myFooVar/lines/line[2]/text()
    (Please note this sequence of items may be manifested as a non XML infoset item when needed. e.g. as a Boolean)

  • a variable reference: e.g. $myFooVar



8.2.2 Binding WS-BPEL Variables In XPath 1.0


With the exception of link expressions whose variable access syntax and semantics are described in section 8.2.4 Default use of XPath 1.0 for Expression Languages, WS-BPEL variables are accessible in XPath expressions via XPath variable bindings. Specifically, all WS-BPEL variables visible from the Enclosing Element of an XPath expression MUST be made available to the XPath processor by manifesting the WS-BPEL variable as an XPath variable binding whose name is the same as the WS-BPEL variable's name, except in the case of variables declared with a WSDL messageType, which requires some special handling (discussed below).

 

WS-BPEL variables declared using an element MUST be manifested as a node-set XPath variable with a single member node. That node is a synthetic DII that contains a single child, the document element, which is the value of the WS-BPEL variable. The XPath variable binding will bind to the document element. For example, given the following Schema definition:









form="qualified" />



And given the following variable declaration:



Then a WS-BPEL XPath expression to access the value of the statusDescription element, assuming the AStatus variable is in scope, would look like:

$AStatus/e:statusDescription

$AStatus points at the variable's document element, StatusContainer. So to access StatusContainer's child statusDescription it is only necessary to specify the child's element name.

WS-BPEL variables declared using a complex type MUST be manifested as a node-set XPath variable with one member node containing the anonymous document element that contains the actual value of the WS-BPEL complex type variable. The XPath variable binds to the document element. For example, given the following Schema definition:





form="qualified">





And given the following variable declaration:



Then a WS-BPEL XPath expression to access the value of the second AuctionID attribute would look like:

$Results/e:AuctionResult[2]/@AuctionID

$Results points at the variable’s document element, AuctionResult[2] points to the second AuctionResult child of the document element, and @AuctionID points to the AuctionID attribute on the selected AuctionResult element.

 

WS-BPEL messageType variables MUST be manifested in XPath as a series of variables, one variable per part in the messageType. Each variable is named by concatenating the message variable's name, the "." character and the name of the part. The data in a WS-BPEL messageType variable is not made available as one single XPath variable to general XPath processing under the default query and expression language binding. For example, if a messageType variable was named "myMessageTypeVar" and it contained two parts, "msgPart1" and "msgPart2" then the XPath binding that had "myMessageTypeVar" in scope would manifest two XPath variables, $myMessageTypeVar.msgPart1 and $myMessageTypeVar.msgPart2.


WSDL message parts are always defined using either an XSD element, an XSD complex type or a XSD simple type. As such the manifestation of these message parts in XPath can be handled in the same manner as specified herein for element, complex type and simple type WS-BPEL variables.
Below is a full example of how a WSDL message type is manifested in WS-BPEL XPath.



And given the following variable declaration:



Then a WS-BPEL XPath expression to access the second part’s statusDescription element would look like:

$StatusVariable.StatusPart2/e:statusDescription

It is possible to write XPath queries that can simultaneously query across multiple parts of a WSDL message variable by applying a union operator to create one single nodeset. For example:

( $StatusVariable.StatusPart1

| $StatusVariable.StatusPart2 )//e:statusDescription 

WS-BPEL simple type variables MUST be manifested directly as either an XPath string, Boolean or float object. If the XML Schema type of the WS-BPEL simple type variable is xsd:boolean or any types that are restrictions of xsd:boolean then the WS-BPEL variable MUST be manifested as an XPath Boolean object. If the XML Schema type of the WS-BPEL simple type variable is xsd:float, xsd:int, xsd:unsignedInt or any restrictions of those types then the WS-BPEL variable MUST be manifested as an XPath float object. Any other XML Schema types MUST be manifested as an XPath string object.

The precision of the float object in XPath 1.0 is not sufficient to capture the full value of some XML Schema data types, such as xsd:decimal. XSD numeric values that cannot be expressed without loss of accuracy as XPath float objects MUST be translated into XPath string objects by a WS-BPEL processor.


8.2.3 XPath 1.0 Perspective and WS-BPEL


The XPath 1.0 specification [XPATH 1.0] defines five points that define the context in which an XPath expression is evaluated. Those points are reproduced below:

  • a node (the context node)

  • a pair of non-zero positive integers (the context position and the context size)

  • a set of variable bindings

  • a function library

  • the set of namespace declarations in scope for the expression

The following sections define how these contexts are initialized in WS-BPEL for different types of WS-BPEL Expression and Query Language contexts.

8.2.4 Default use of XPath 1.0 for Expression Languages


When XPath 1.0 is used for an Expression Language, except as specified in the sections 8.2.5 Use of XPath 1.0 for Expression Languages in Join Conditions, the XPath context is initialized as follows:


Context node

None

Context position

None

Context size

None

A set of variable bindings

Variables visible to the Enclosing Element as defined by the WS-BPEL scope rules 

A function library

WS-BPEL and core XPath 1.0 functions MUST be available and processor-specific functions MAY be available

Namespace declaration

In-scope namespace declarations from Enclosing Element

It is worth emphasizing that as defined by the XPath 1.0 standard when resolving an XPath the namespace prefixes used inside of the variable (e.g. WS-BPEL variables) are irrelevant. The only prefixes that matter are the in-scope namespaces.

For example, imagine a WS-BPEL variable named “FooVar” of “foo” element type with value:



23

The following XPath would return the value 23:



$FooVar/b:bar/text()

Notice that in the previous example the bar element is referred to use the 'b' namespace prefix rather than the 'a' namespace prefix that is used inside the actual value.

It is also worth emphasizing that XPath 1.0 explicitly requires that any element or attribute used in an XPath expression that does not have a namespace prefix must be treated as being namespace unqualified. That is, even if there is a default namespace defined on the enclosing element, the default namespace will not be applied.

Using the same value for Foo as provided previously the following would return a bpel:selectionFailure fault (in Executable WS-BPEL), because it fails to select any node in the context of operation:



$FooVar/bar/text()

The values inside of the XPath do not inherit the default namespace of the enclosing element. So the 'bar' element referenced in the XPath does not have any namespace value what so ever and therefore does not match with the bar element in the FooVar variable which has a namespace value of http://example.com.

Allowing WS-BPEL variables to manifest as XPath variable bindings enables WS-BPEL programmers to create powerful XPath expressions involving multiple WS-BPEL variables. For example:





$po/lineItem[@prodCode=$myProd]/amt * $exchangeRate

$convertedPO/lineItem[@prodCode=$myProd]/amt



[SA00027] When XPath 1.0 is used as an expression language in WS-BPEL there is no context node available. Therefore the legal values of the XPath Expr (http://www.w3.org/TR/xpath#NT-Expr) production must be restricted in order to prevent access to the context node.

Specifically, the "LocationPath" (http://www.w3.org/TR/xpath#NT-LocationPath) production rule of "PathExpr" (http://www.w3.org/TR/xpath#NT-PathExpr) production rule MUST NOT be used when XPath is used as an expression language. The previous restrictions on the XPath Expr production for the use of XPath as an expression language MUST be statically enforced.

The result of this restriction is that the "PathExpr" will always start with a "PrimaryExpr" (http://www.w3.org/TR/xpath#NT-PrimaryExpr) for WS-BPEL expression or query language XPaths. It is worth remembering that PrimaryExprs are either variable references, expressions, literals, numbers or function calls, none of which can access the context node.

Extra restrictions are applied to XPath usage as an expression language within to-spec (see section 8.4. Assignment).

8.2.5 Use of XPath 1.0 for Expression Languages in Join Conditions


When XPath 1.0 is used as an Expression Language in a join condition, the XPath context is initialized as follows:


Context node

None

Context position

None

Context size

None

A set of variable bindings

Links that target the activity that the Enclosing Element is contained within 

A function library

Core XPath functions MUST be available, [SA00028] WS-BPEL functions MUST NOT be available, and processor-specific functions MAY be available.

Namespace declaration

In-scope namespace declarations from Enclosing Element

As explained in section 11.5.1 expressions in join conditions may only access the status of links that target the join condition's enclosing activity. No other data may be made available. To this end the only variable bindings made available to join conditions are ones that access link status.



status is obtained via XPath variable bindings, manifesting s that target the activity containing the Enclosing Element as XPath variable bindings of identical name. That is, if there is a called "ABC" that targets the activity then there must be an XPath variable binding called "ABC". Link variables are manifested as XPath Boolean objects whose value will be set to the link's value.

Below is an example of a inside of a element:









$link1 and $link2


8.2.6 Use of XPath 1.0 for Query Languages in Copy Operations and Property Aliases


When XPath 1.0 is used as Query Language in the first variant of from-spec and to-spec in assignments (also known as variable variant) or a , the XPath context is initialized as follows:

 





Variable variant from-spec or to-spec



Context node

See below

See below

Context position

1

1

Context size

1

1

A set of variable bindings

Variables visible to the Enclosing Element as defined by the WS-BPEL scope rules 

There MUST NOT be any variable bindings available when XPath is used as the query language in a

A function library

WS-BPEL and core XPath 1.0 functions MUST be available and processor-specific functions MAY be available

Core XPath functions MUST be available, [SA00029] WS-BPEL functions MUST NOT be available, and processor-specific functions MAY be available.

Namespace declaration

In-scope namespace declarations from Enclosing Element

In-scope namespace declarations from Enclosing Element (note that the Enclosing Element is in a defined in a WSDL definition)

The context node is determined as follows:



  • When the from-spec or to-spec references a messageType variable or the ’s messageType/part attributes are used:

    • If the message part is based on a complex type or an element, the context node MUST point to a node-list containing a single node which is the EII for the referenced part specified in section 8.2.2 Binding WS-BPEL Variables In XPath 1.0.

    • If the message part is based on a simple type, the context node MUST point to the XPath object specified in section 8.2.2 Binding WS-BPEL Variables In XPath 1.0.

  • When the from-spec or to-spec references an XML Schema type variable or the ’s type attribute is used:

    • If the type is a complex type, the context node MUST point to a node-list containing a single node which is the EII for the referenced part specified in section 8.2.2 Binding WS-BPEL Variables In XPath 1.0.

    • If the type is a simple type, the context node MUST point to the XPath object specified in section 8.2.2 Binding WS-BPEL Variables In XPath 1.0.

  • When the from-spec or to-spec references an XML Schema element variable or the ’s element attribute is used, the context node MUST point to a node-list containing a single node which is the EII for the referenced part specified in section 8.2.2 Binding WS-BPEL Variables In XPath 1.0.

None of the previously listed restrictions on the syntax of the XPath expression apply to a in from-spec/to-spec and because it has a defined context node. Any legal XPath expression may be used. An absolute or relative path can be used in a as both resolve to the context node which is the root node.

This example shows a using a relative XPath query. It returns an lvalue:



messageType="my:POMsg"

part="poPart">

price

In contrast, this example shows a using an absolute XPath query. It does not return an lvalue:



messageType="my:POMsg"

part="poPart">

(/p:po/price * 0.9)

There is no requirement that return lvalues. When the used in a variable variant to-spec or the of used in a property variant to-spec does not return an lvalue, an attempt to assign to such a to-spec MUST fail with a bpel:selectionFailure (as defined in section 8.4. Assignment). Multiple nodes may be selected with this feature. However, those selections may be then filtered in the rest of expression and result in one node returned.


8.3. Expressions


WS-BPEL uses several types of expressions, as follows (relevant usage contexts are listed in parentheses):

  • Boolean expressions (transition, join, while, and if conditions)

  • Deadline expressions (until expression of and )

  • Duration expressions (for expression of and , expression of )

  • Unsigned Integer expressions (, , and in )

  • General expressions ()

When the above first four types of expressions are being used, the corresponding expressions SHOULD return values which are valid according to the corresponding XML Schema types:

  • Boolean expressions should return valid values of xsd:boolean

  • Deadline expressions should return valid values of xsd:date and xsd:dateTime

  • Duration expressions should return valid values of xsd:duration

  • Unsigned Integer expressions should return valid values of xsd:unsignedInt

Otherwise, a bpel:invalidExpressionValue fault SHOULD be thrown. Implicit data conversion or casting MAY be applied when computing returned values from expressions, based on the data model or type conversion semantics established in the underlying expression language.

The following values conversion and validity checking semantics MUST be applied when WS-BPEL's default binding to XPath 1.0 is used as the expression language:



  • For WS-BPEL Boolean expressions, XPath's boolean(object) function is used to convert the expression result into a Boolean value if needed.

  • For WS-BPEL Deadline expressions, XPath's string(object) function is used to convert the expression result into a string value if needed. The string value MUST be valid values of xsd:date and xsd:dateTime. Otherwise, a bpel:invalidExpressionValue fault MUST be thrown.

  • For WS-BPEL Duration expressions, XPath's string(object) function is used to convert the expression result into a string value if needed. The string value MUST be valid values of xsd:duration. Otherwise, a bpel:invalidExpressionValue fault MUST be thrown.

  • For WS-BPEL Unsigned Integer expressions, XPath's number(object) function is used to convert the expression result into a numeric value if needed. The numeric value MUST be valid values of xsd:unsignedInt (i.e. neither negative or NaN and it must be an integer value). Otherwise, a bpel:invalidExpressionValue fault MUST be thrown.

The following XPath extension functions are defined by WS-BPEL and MUST be supported by a WS-BPEL implementation:

  • getVariableProperty, described below

  • doXslTransform, described in section 8.4. Assignment

These extensions are defined in the standard WS-BPEL namespace (see section 5.3. Language Extensibility for an overall discussion of WS-BPEL Language Extensibility) .

Any qualified names used within XPath expressions MUST be resolved by using namespace declarations currently in scope in the WS-BPEL document at the location of the expression. Null prefixes MUST be handled as specified in [XSLT 1.0] section 2.4 (i.e., a null prefix means that the empty namespace is used).

The function signature of bpel:getVariableProperty is:

object bpel:getVariableProperty(string, string)

This function extracts property values from variables. The first argument names the source variable for the data and the second is the QName of the property to select from that variable (see section 7. Variable Properties). [SA00031] The second argument MUST be a string literal conforming to the definition of QName in section 3. Relationship with Other Specifications, and these constraints MUST be enforced by static analysis.

The return value of this function is calculated by applying the appropriate for the requested property to the current value of the submitted variable.

[SA00030] The arguments to bpel:getVariableProperty MUST be given as quoted strings. The previous requirement MUST be statically enforced. It is therefore illegal to pass into a WS-BPEL XPath function any XPath variables, the output of XPath functions, a XPath location path or any other value that is not a quoted string. This means, for example, that bpel:getVariableProperty("varA","b:propB") meets the previous requirement while bpel:getVariableProperty( $varA, string(bpel:getVariableProperty("varB", "b:propB") ) does not. Note that the previous requirement institutes a restriction which does not exist in the XPath standard.

8.3.1. Boolean Expressions


These are expressions that conform to the XPath 1.0 Expr production where the evaluation results in Boolean values.

8.3.2. Deadline Expressions


These are expressions that conform to the XPath 1.0 Expr production where the evaluation results in values that are of the XML Schema types dateTime or date.

Note that XPath 1.0 is not XML Schema aware. As such, none of the built-in functions of XPath 1.0 are capable of producing or manipulating dateTime or date values. However, it is possible to write a constant (literal) that conforms to XML Schema definitions and use that as a deadline value or to extract a field from a variable (part) of one of these types and use that as a deadline value. XPath 1.0 will treat that literal as a string literal, but the result can be interpreted as a lexical representation of a dateTime or date value.


8.3.3. Duration Expressions


These are expressions that conform to the XPath 1.0 Expr production where the evaluation results in values that are of the XML Schema type duration. The preceding discussion about XPath 1.0's lack of XML Schema awareness applies here as well.

8.3.4. Unsigned Integer Expressions


These are expressions that conform to the XPath 1.0 Expr production where the evaluation results in number object values that are of the XML Schema type unsignedInt.

8.3.5. General Expressions


These are expressions that conform to the XPath 1.0 Expr production where the evaluation results in any XPath value type (string, number, or Boolean).

8.4. Assignment


The activity can be used to copy data from one variable to another, as well as to construct and insert new data using expressions. The use of expressions is primarily motivated by the need to perform simple computation (such as incrementing sequence numbers). Expressions operate on variables, properties, and literal constants to produce a new value. The activity can also be used to copy endpoint references to and from partnerLinks. It is also possible to include extensible data manipulation operations defined as extension elements under namespaces different from the WS-BPEL namespace. If the element contained within the extensionAssignOperation element is not recognized by the WS-BPEL processor and is not subject to a mustUnderstand="yes" requirement from an extension declaration then the extensionAssignOperation operation MUST be ignored. (See section 14 Extension Declarations).

Finally, it is possible to include extensible data manipulation operations defined as extension elements under namespaces different from the WS-BPEL namespace (see section 5.3. Language Extensibility).

The activity contains one or more elementary operations.

standard-elements

(

from-spec to-spec

|

assign-element-of-other-namespace

)+

The activity copies a type-compatible value from the source ("from-spec") to the destination ("to-spec"), using the element. [SA00032] Except in Abstract Processes, the from-spec MUST be one of the following variants:



?

queryContent





expression

literal value

In Abstract Processes, the from-spec MUST be either one of the above or the opaque variant described in section 13.1.3. Hiding Syntactic Elements

The to-spec MUST be one of the following variants:



?

queryContent











expression

A to-spec MUST return an lvalue. If a to-spec does not return an lvalue then a bpel:selectionFailure MUST be thrown. An lvalue, in the context of XPath, is a node-list containing a single node from a variable or a partnerLink identified by the to-spec. The restrictions listed in 8.2.4 Default use of XPath 1.0 for Expression Languages MUST apply to XPath used as a query language. [SA00033] In addition, the XPath query MUST begin with an XPath VariableReference. This restriction MUST be statically enforced.

Variable variant: in the first from-spec and to-spec variants the variable attribute provides the name of a variable. If the type of the variable is a WSDL messageType the optional part attribute may be used to provide the name of a part within that variable. [SA00034] When the variable is defined using XML Schema types (simple or complex) or element, the part attribute MUST NOT be used. An optional element may be used to select a value from the source or target variable or message part. The computed value of the query MUST be one of the following:

       a single XML information item other than a CII, for example, EII and AII

       a sequence of zero or more CIIs: this is mapped to a Text Node or a string in the XPath 1.0 data model

PartnerLink variant: the second from-spec and to-spec variants allow manipulation of the endpoint references associated with partnerLinks. The value of the partnerLink attribute is the name of a partnerLink that is in scope. In the case of from-specs, the role MUST be specified. The value “myRole” means that the endpoint reference of the process with respect to that partnerLink is the source, while the value “partnerRole” means that the partner’s endpoint reference for the partnerLink is the source. [SA00035] [SA00036] If the value “myRole” or “partnerRole” is used, the corresponding


declaration MUST specify the corresponding myRole or partnerRole attribute. This restriction MUST be statically enforced. For the to-spec, the assignment is only possible to the partnerRole, hence there is no need to specify the role. [SA00037] Therefore, the to-spec can only refer to a
of which the declaration specifies the partnerRole attribute. This restriction MUST be statically enforced. The type of the value referenced by partnerLink-style from/to-specs is always a element (see section 6. Partner Link Types, Partner Links, and Endpoint References).

An attempt during process execution to read a partner link before its partnerRole EPR is initialized MUST result in the bpel:uninitializedPartnerRole standard fault. Partner roles of partner links are read when they are referenced in an or the part of a in an activity.



Property variant: the third from-spec and to-spec variants allow data manipulation using properties (see section 7. Variable Properties). The property value generated by the from-spec is generated in the same manner as the value returned by the bpel:getVariableProperty() function. The property variants provide a way to clearly define how distinguished data elements in messages are being used.

Expression variant: in the fourth from-spec variant, an expression language, identified by the optional expressionLanguage attribute, is used to return a value. In the fourth to-spec variant, an expression language, identified by the optional expressionLanguage attribute, is used to select a value. This computed value of the expression MUST be one of the followings:

       a single XML information item other than a CII, for example, EII and AII

       a sequence of zero or more CIIs: this is mapped to a Text Node or a string in the XPath 1.0 data model

It is possible to use either the first form of from-spec/to-spec or the fourth form of from-spec/to-spec to perform copy on non-message variables and parts of message variables, as this specification defines how to manifest non-message variables and parts of message variables as XML Infoset information items. However, only the first form of from-spec/to-spec is able to copy an entire message variable including all of its parts. Other from-spec and to-spec variants are only able to refer to a single part in a WSDL message type variable and so cannot copy all of the parts at once.



Literal variant: the fifth from-spec variant allows a literal value to be given as the source value to assign to a destination. The literal value to be assigned is included within a element in order to prevent conflicts with standard extensibility elements under . The element itself does not allow standard extensibility. The type of the literal value MAY be optionally indicated inline with the value by using XML Schema's instance type mechanism (xsi:type).

The fifth from-spec variant returns values as if it were a from-spec that selects the children of the element in the WS-BPEL source code. [SA00038] The return value MUST be a single EII or Text Information Item (TII) only. This constraint MUST be enforced during static analysis.(see section 8.4.1. Selection Result of Copy Operations for the definition of TIIs). The XML parsing context of the element in the source code, such as XML Namespace, is carried into the parsing of the children within the element. An empty element returns an empty TII. Here are some examples for illustration:













]]>





















The first above copies a element with a “foo” prefix associated to “http://example.com” namespace into “myFooBarElemVar”. The second copies a string whose value is “” into “myStringVar”. The last copies an empty string into “myStringVar”.

The literal from-spec variant also allows a literal value to be assigned to a partnerLink, when used with the partnerLink variant of the to-spec.

Empty variant: The sixth from-spec variant and fifth to-spec variant are included to explicitly show that from-spec and to-spec are extensible. Note that if these variants are not extended, or the extensions are not understood, they MUST behave as if they were an expression variant returning zero nodes.

In addition to specifications, other extensibility data manipulation elements MAY be included in an assign activity, inside an element. The extensibility data manipulation elements MUST belong to a namespace different from the WS-BPEL namespace.



Attributes of Assign and Copy

The optional keepSrcElementName attribute of the construct is used to specify whether the element name of the destination (as selected by the to-spec) will be replaced by the element name of the source (as selected by the from-spec) during the copy operation (see section 8.4.2. Replacement Logic of Copy Operations).

The optional ignoreMissingFromData attribute of the construct is used to specify whether a bpel:selectionFailure standard fault is suppressed as specified in section 8.4.1. Selection Result of Copy Operations. The default value of the ignoreMissingFromData is "no".

The optional validate attribute can be used with the activity. Its default value is "no". When validate is set to "yes", the activity validates all the variables being modified by the activity. A WS-BPEL implementation MAY provide a mechanism to turn on/off any explicit validation. E.g. validate attribute at assign.

If the "validate" part of the activity fails, that is, one of the variables is invalid against its corresponding XML definition, a standard fault bpel:invalidVariables MUST be thrown.

If there is any fault during the execution of an assignment activity the destination variables MUST be left unchanged, as they were at the start of the activity (as if the assign activity were atomic). This applies regardless of the number of assignment elements within the overall assignment activity.

The assign activity MUST be executed as if, for the duration of its execution, it was the only activity in the process being executed.

The copy mechanism as described thus far, when combined with the default XPath 1.0 expression language, cannot perform complex XML transformations. To address this restriction in a portable fashion, a WS-BPEL processor MUST support the bpel:doXslTransform() XPath 1.0 extension function. The function signature of bpel:doXslTransform is:

object bpel:doXslTransform(string, node-set, (string, object)*)

where:


  • The first parameter is an XPath string providing a URI naming the style sheet to be used by the WS-BPEL processor. [SA00039] This MUST take the form of a string literal. The purpose of this constraint is to allow implementations to statically analyze the process (and named style sheets) for variable dependencies; it MUST be enforced by static analysis.

  • The second parameter is an XPath node set providing the source document for the transformation to be performed by the WS-BPEL processor. This set MUST contain a single EII (i.e. an element node in XPath 1.0 data model). If it does not, the WS-BPEL processor MUST throw a bpel:xsltInvalidSource fault. The single EII as specified by this parameter MUST be treated as the single child of the root node of the source tree for XSLT processing.

  • The optional parameters that follow MUST appear in pairs. Each pair is defined as:

    • an XPath string parameter providing the qualified name of an XSLT parameter

    • an XPath object parameter providing the value for the named XSLT parameter. It can be an XPath Expr.

[SA00040] The WS-BPEL processor MUST enforce the pairing of these parameters by static analysis (i.e., an odd number of parameters must cause a static analysis error).

  • The function MUST return the result of the transformation. The result is one of the following infoset items, depending on the XSLT output method employed by the selected style sheet:

    • A single TII (an XPath 1.0 text node), created by the XSLT "text" or "html" output methods, or

    • A single EII (an XPath element node that is the single child of the root of the result tree), which is created by the XSLT "xml" output method.

The WS-BPEL processor MUST execute the bpel:doXslTransform function such that all of the following apply:

  • The first parameter, naming the style sheet to be used, MUST be used to find the style sheet corresponding to the given URI. This is accomplished in an implementation-dependent fashion. If the style sheet corresponding to the given URI cannot be found, the WS-BPEL processor MUST throw a bpel:xsltStylesheetNotFound fault.

  • The processor MUST perform an XSLT 1.0 transformation, as described in section 5.1 (Processing Model) of the XSLT 1.0 specification, using the named style sheet as primary sheet, the provided source EII as the source document, and the result tree as the result of the transformation.

  • XSLT global parameters ([XSLT 1.0], section 11.4 of the XSLT 1.0 specification) are used to pass additional values from the WS-BPEL process to the XSLT processor. The optional parameters for doXslTransform function come in the form of name-value pair in the argument list, as described above. They are used to identify the XSLT global parameters by QName, and to supply values for the named global parameters. [SA00041] The global parameter names MUST be string literals conforming to the definition of QName in section 3 of [Namespaces in XML], and these constraints MUST be enforced by static analysis. The WS-BPEL processor MUST pass the given global parameter names and values to the XSLT processor.

  • If any XSLT processing faults occur during the transformation, then a bpel:subLanguageExecutionFault MUST be thrown.

Since XSLT is a side effect-free language, execution of the transformation cannot by definition cause any changes to WS-BPEL variables referred to in the style sheet.

The first XPath function parameter, which names the style sheet, has similar semantics as the location attribute of an element. Style sheets associated with a process (through its doXslTransform invocations) SHOULD be considered part of the process definition, like WSDL definitions and XML Schemas referenced by an element.



bpel:doXslTransform Examples

The following examples show complex document transformation and iterative document construction.



Complex document transformation. A common pattern in WS-BPEL processes involves receiving an XML document from one service, converting it to a different Schema to form a new request message, and sending the new request to another service. Such documentation conversion can be accomplished using XSLT via the bpel:doXslTransform function.







...








bpel:doXslTransform("urn:stylesheets:A2B.xsl", $A)







In the sequence, a service is invoked, and the result (foo:AElement) copied to variable A. The activity is used to transform the contents of variable A to bar:BElement, and copy the result of that transformation to variable B. Variable B is used to invoke another service.

The style sheet A2B.xsl would contain the XSL rules for converting documents of Schema foo:AElement to Schema bar:BElement.

Iterative document construction. Suppose that a document is constructed by repeatedly calling a service, and accumulating the result in an XML variable. The loop might look something like this:











...









bpel:doXslTransform( "urn:stylesheets:AddToPO.xsl",

$PO, "NewItem", $OutVar)











The optional parameters given in the doXslTransform call specify that the XSLT parameter named "NewItem" is set with the value of the WS-BPEL variable OutVar. To allow the XSLT style sheet access to this value, it contains a global (top-level) parameter with a name matching that given in the third parameter of the function call shown above.



xmlns:xsl="http://www.w3.org/1999/XSL/Transform" ...>

defaults to empty item -->





...


The style sheet contains a template that appends the value of global parameter NewItem (the value of OutVar from the process instance)to the existing list of items in the PO variable.

This template copies all existing items in the source document (lines 1 & 2) and appends the contents of the XSLT parameter NewItem to the list of items (lines 3 & 4). It tests to see if the current node is at the end of the item list (line 3) and copies the result-tree fragment from the XSLT parameter NewItem to follow the last item (line 4).

If PO has a value of:



item 1

at the beginning of an iteration of the loop and the activity returns a value of item 2, evaluation of the expression will result in a value of:





item 1

item 2

which, when the operation completes, becomes the new value of the PO variable.


8.4.1. Selection Result of Copy Operations


The selection result of the from-spec or to-spec used within a operation MUST be one of the following three Information Items: Element Information Item (EII), Attribute Information Item (AII), or Text Information Item (TII). EII and AII are defined in [Infoset], while TII is defined in this specification to bridge the gap between the XML Infoset Model and other common XML data models, such as XPath 1.0.

A Text Information Item (TII) is a sequence of zero or more Character Information Items, according to document order; as such, a TII is not manifested in and of itself directly in XML serialization. When mapped to the XPath 1.0 model, it generalizes a string object (which has zero or more characters) and text node (which has one or more characters). A TII lvalue MUST NOT be empty. A TII rvalue MAY be mapped to a text node, a string/Boolean/Number object in XPath 1.0, while a TII lvalue MUST be mapped to a text node.

If the selection result of a from-spec or a to-spec belongs to Information Items other than EII, AII or TII, a bpel:selectionFailure fault MUST be thrown. If any of the unsupported Information Items are contained within the selection result, they MUST be preserved; the only restriction is that they MUST NOT be directly selected by the from-spec or the to-spec as the top-level item.

The operation is a one-to-one replacement operation. If the optional ignoreMissingFromData attribute has the value of "yes" and the from-spec returns zero XML information items then the MUST be a "no-op"; no bpel:selectionFailure is thrown. In this case, the to-spec MUST not be evaluated. A bpel:selectionFailure MUST still be thrown in the following cases, even if the ignoreMissingFromData attribute has the value of "yes":



  1. the from-spec selects multiple XML information items

  2. the from-spec selects one XML information item and the to-spec does not select exactly one XML information item

If the ignoreMissingFromData attribute has the value of "no" this requires that both the from-spec and to-spec MUST select exactly one of the three information items described above. If the from-spec or to-spec do not select exactly one information item during execution, then the standard fault bpel:selectionFailure MUST be thrown. The following table illustrates the behavior of the ignoreMissingFromData attribute in the operation:

returned nodes

ignoreMissingFromData

from

to

“no”

“yes”

0

0

selectionFailure

no-op

0

1

selectionFailure

no-op

0

N

selectionFailure

no-op

1

0

selectionFailure

selectionFailure

1

1

copy

copy

1

N

selectionFailure

selectionFailure

N

0

selectionFailure

selectionFailure

N

1

selectionFailure

selectionFailure

N

N

selectionFailure

selectionFailure

ignoreMissingFromData Logic Table

Literal values (the literal variant of from-spec) MUST contain either a single TII or a single EII as its top-level value. When the rvalue of a from-spec is an AII, the to-spec is set to a TII constructed from the normalized value property of the AII as specified in section 8.4.2. Replacement Logic of Copy Operations.

When using the partnerLink variants of from-spec and to-spec with a non-partnerLink variant of the respective from-spec and to-spec in a operation, the partnerLink variants should be treated as if they produce an rvalue and lvalue of an EII whose [local name] is “service-ref” and [namespace name] is "http://docs.oasis-open.org/wsbpel/2.0/serviceref".

8.4.2. Replacement Logic of Copy Operations


This section provides rules for replacing data referenced by the to-spec in a operation. Detailed examples are provided in Appendix Appendix D. Examples of Replacement Logic.

Replacement Logic for WSDL Message Variables

When the from-spec and to-spec of a operation both select WSDL message variables, the value of the from-spec message variable MUST be copied, becoming the value of the to-spec message variable. If the from-spec message variable is completely uninitialized then the standard bpel:uninitializedVariable fault is thrown. If the from-spec message variable is partially initialized then any uninitialized parts of the from-spec variable result in the same parts of the to-spec variable becoming uninitialized. The original message parts of the to-spec message variable will not be available after the operation.



Replacement Table for XML Data Item

When the from-spec (Source) and to-spec (Destination) select one of three Information Items types, a WS-BPEL processor MUST use the following replacement rules identified in the table below:



Source\Destination

EII

AII

TII

EII

RE

RC

RC

AII

RC

RC

RC

TII

RC

RC

RC

Replacement Logic Table


  • RE (Replace-Element-properties):

    • Replace the element at the destination with a copy of the entire element at the source, including [children] and [attribute] properties.

      An optional keepSrcElementName attribute is provided to further refine the behavior. [SA00042] It is only applicable when the results of both from-spec and to-spec are EIIs, and MUST NOT be explicitly set in other cases. A WS-BPEL processor MAY enforce this checking through static analysis of the expression/query language. If a violation is detected during runtime, a bpel:selectionFailure fault MUST be thrown.



      • When the keepSrcElementName attribute is set to “no”, the name (i.e. [namespace name] and [local name] properties) of the original destination element is used as the name of the resulting element. This is the default value.

      • When the keepSrcElementName attribute is set to “yes”, the source element name is used as the name of the resulting destination element.



When the keepSrcElementName attribute is set to “yes” and the destination element is the Document EII of an element-based variable or an element-based part of a WSDL message-type-based variable, a WS-BPEL processor MUST make sure the name of the source element belongs to the substitutionGroup of the destination element used in the element variable declaration or WSDL part definition. The substitutionGroup relation is determined by XML Schemas known to the WS-BPEL processor. [SA00094] A WS-BPEL processor MAY enforce this checking through static analysis of the expression/query language. If a violation is detected during runtime, a bpel:mismatchedAssignmentFailure fault MUST be thrown.


  • RC (Replace-Content):

    • To obtain the source content:

      • Once the information item is returned from the source, a TII will be computed based upon it. This source content TII is based on a series of CIIs, generally based on the document order (unless a sorting specification is present in the underlying expression or query), taken from the returned information item. The CIIs are copied, concatenated together, and the resulting value is assigned to the TII. This is analogous to the XPath 1.0 string() function.

      • If the source is an EII with an xsi:nil="true", a selectionFailure fault MUST be thrown. This check is performed during EII-to-AII or EII-to-TII copy.

    • To replace the destination content:

      • If the destination is an EII, all [children] properties (if any) are removed and the source content TII is added as the child of the EII.

      • If the destination is an AII, the value of AII is replaced with the TII from the source. The value MUST be normalized, in accordance with the XML 1.0 Recommendation (section 3.3.3 Attribute Value Normalization: http://www.w3.org/TR/1998/REC-xml-19980210#AVNormalize).

      • If the destination is a TII, the TII in the destination is replaced with the TII from the source.

  • In addition, the following rules apply:

  • Information items referenced by the to-spec MUST be an lvalue. In the XPath 1.0 data model, a TII lvalue MUST be a text node.

  • A bpel:mismatchedAssignmentFailure fault MUST be thrown when the to-spec selects a TII as an lvalue, which does NOT belong to a WS-BPEL variable of an XSD string type (or a type derived from XSD string), and one of the following is computed as an rvalue from the from-spec:

    • a TII which has zero CIIs

    • an AII which has an empty string as its [normalized value]

    • an EII which has zero CIIs as its descendants, that is, its [children] and nested [children]. Note that applying XPath 1.0 string() function to this kind of EII would yield an empty string.

  • Attribute values are not text nodes in XPath 1.0. Attribute nodes have a string value that corresponds to the XML normalized attribute value, which is a TII.

Using to initialize variables

When the destination selected by the to-spec in a operation is un-initialized, which is either an entire WS-BPEL variable or a message part, that destination MUST first be initialized before executing the replacement rules defined above, as if the following has been applied:



  • For complex type and simple type variables or message parts, initialize to a skeleton structure composed of a DII and an anonymous Document Element EII.

  • For element based variables or message parts, initialize to a skeleton structure composed of a DII and an Document Element EII with the name matching the element name used in variable declaration.

This initialization behavior is an integral part of an atomic activity.

Handling Non-XML Infoset Data Objects in

Simple type variables and values MAY be allowed to manifest as non-XML infoset data objects, such as boolean, string, or float, as defined in XPath 1.0. Also expressions may return non-XML infoset data objects, for example:



number($order/amt) * 0.8

To consistently apply the above replacement rules, such non-XML infoset data are handled as TIIs. This is achieved through converting data to strings, as TII resembles a string object. More specifically, when the XPath 1.0 data model is used in WS-BPEL, "string(object)" (http://www.w3.org/TR/1999/REC-xpath-19991116#function-string) coercion MUST be used to convert boolean or number objects to strings. A WS-BPEL processor MAY skip the actual conversion if the result of remains the same.



XML Namespace Preservation

In the operation, the [in-scope namespaces] properties from the source (similar to other XML infoset item properties) MUST be preserved in the result at the destination. A WS-BPEL processor may use a namespace-aware XML infrastructure to maintain the XML namespace consistency.

In some XML Schema designs, QName may be used for attribute or element values. When a TII or an AII containing a QName value is selected via a Schema-unaware expression/query language, its data model will fail to capture the namespace property of the QName value. Therefore, the XML namespace may be lost. Note that XPath 1.0 is Schema unaware.

For example, where the value of attrX is a QName ("myPrefix:somename") and the value of "foo:bar3" is another QName ("myPrefix:somename2"). When "foo:bar2/@attrX" is copied as the source with XPath 1.0 data model, the namespace declaration for "myPrefix" might be missing in the destination.



xmlns:foo="http://example.com ">





myPrefix:somename2


8.4.3. Type Compatibility in Copy Operations


[SA00043] For a copy operation to be valid, the data referred to by the from-spec and the to-spec MUST be of compatible types.

The following situations are considered type incompatible:



  • the selection results of both the from-spec and the to-spec are variables of a WSDL message type, and the two variables are not of the same WSDL message type (two WSDL message types are the same if their QNames are equal).

  • the selection result of the from-spec is a variable of a WSDL message type and that of the to-spec is not, or vice versa (parts of variables, selections of variable parts, or endpoint references cannot be assigned to/from variables of WSDL message types directly).

  • the selection result of the from-spec is an EII, that of the to-spec is a Document EII of an element-based variable or an element-based part of a WSDL message-type-based variable, the keepSrcElementName attribute is set to “yes” and the name of the source element does not belong to the substitutionGroup of the destination (see section 8.4.2. Replacement Logic of Copy Operations).

If any incompatible types are detected during assignment, the standard fault bpel:mismatchedAssignmentFailure MUST be thrown.

8.4.4. Assignment Example


Assume the following complex type definition in the namespace "http://example.org/bpel/example":
































Assume that the following WSDL message definition exists for the same target namespace:





Also assume the following WS-BPEL variable declarations:







The example illustrates copying one variable to another as well as copying a variable part to a variable of compatible element type:















$c1.address






1   ...   4   5   6   7   8   9   10   11   ...   23

Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©atelim.com 2016
rəhbərliyinə müraciət