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

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

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

7. Variable Properties

7.1. Motivation

7.1.1 Motivation for Message Properties

The data in a message consists conceptually of two parts: application data and protocol relevant data, where the protocols can be business protocols or infrastructure protocols providing higher quality of service. An example of business protocol data is the correlation tokens that are used in (see section 9.2. Declaring and Using Correlation Sets). Examples of infrastructure protocols are security, transaction, and reliable messaging protocols. The business protocol data is usually found embedded in the application-visible message parts, whereas the infrastructure protocols almost always add implicit extra parts to the message types to represent protocol headers that are separate from application data. Such implicit parts are often called message context because they relate to security context, transaction context, and other similar middleware context of the interaction. Business processes might need to gain access to and manipulate both kinds of protocol-relevant data. The notion of message properties is defined as a general way of naming and representing distinguished data elements within a message, whether in application-visible data or in message context. For a full accounting of the service description aspects of infrastructure protocols, it is necessary to define notions of service policies, endpoint properties, and message context. This work is outside the scope of WS-BPEL. Message properties are defined here in a sufficiently general way to cover message context consisting of implicit parts, but the use in this specification focuses on properties embedded in application-visible data that is used in the definition of Abstract and Executable Business Processes.

7.1.2 Motivation for Variable Properties

Message properties are an instance of a more generic mechanism, properties. All variables in WS-BPEL can have properties defined on them. Properties are useful on non-message variables as a way to isolate the WS-BPEL process’s logic from the details of a particular variable’s definition. Using properties a WS-BPEL process can isolate its variable initialization logic in one place and then set and get properties on that in order to manipulate it. If the ’s definition is later changed the rest of the WS-BPEL process definition that manipulates that variable can remain unchanged.

7.2. Defining Properties

A definition creates a unique name for a WS-BPEL process definition and associates it with an XML Schema type. The intent is to create a name that has semantic significance beyond the type itself. For example, a sequence number can be an integer, but the integer type does not convey this significance, whereas a named sequence-number property does. Properties can refer to any parts of a variable.

A typical use for a in WS-BPEL is to name a token for correlation of service instances with messages. For example, a social security number might be used to identify an individual taxpayer in a long-running multiparty business process regarding a tax matter. A social security number can appear in many different message types, but in the context of a tax-related process it has a specific significance as a taxpayer ID. Therefore a name is given to this use of the type by defining a , as in the following example:

targetNamespace="http://example.com/properties.wsdl"

xmlns:tns="http://example.com/properties.wsdl"

xmlns:txtyp="http://example.com/taxTypes.xsd"

xmlns:vprop="http://docs.oasis-open.org/wsbpel/2.0/varprop"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

...

In correlation, the property name must have process-wide significance to be of any use. Properties such as price, risk, response latency, and so on, which are used in conditional behavior in a business process, have similar significance. It is likely that they will be mapped to multiple messages, and therefore they need to be named as in the case of correlation properties.

Even in the general case of properties on XML typed WS-BPEL variables the property name should maintain its generic nature. The name is intended to identify a certain kind of value, often with an implied semantic. Any variable on which the property is available is therefore expected to provide a value that meets not just the syntax of the property definition but also its semantics.

The WSDL extensibility mechanism is used to define properties. The target namespace and other useful aspects of WSDL are available to them.

The syntax for a property definition is a new kind of WSDL definition as follows:

...

[SA00019] Either the type or element attributes MUST be present but not both. Properties used in business protocols are typically embedded in application-visible message data.

7.3 Defining Property Aliases

The notion of aliasing is introduced to map a property to a field in a specific message part or variable value. The property name becomes an alias for the message part and/or location, and can be used as such in expressions and assignments. As an example, consider the following WSDL message definition:

targetNamespace="http://example.com/taxMessages.wsdl"

xmlns:txtyp="http://example.com/taxTypes.xsd"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">

element="txtyp:taxPayerInfoElem" />

...

The definition of a property and its location in a particular field of the message are shown in the next WSDL fragment:
targetNamespace="http://example.com/properties.wsdl"

xmlns:tns="http://example.com/properties.wsdl"

xmlns:txtyp="http://example.com/taxTypes.xsd"

xmlns:txmsg="http://example.com/taxMessages.wsdl" ...>

...

messageType="txmsg:taxpayerInfoMsg" part="identification">

txtyp:socialsecnumber

element="txtyp:taxPayerInfoElem">

txtyp:socialsecnumber

The first defines a named property tns:taxpayerNumber as an alias for a location in the identification part of the message type txmsg:taxpayerInfoMsg.

The second provides a second definition for the same named property tns:taxpayerNumber but this time as an alias for a location inside of the element txtyp:taxPayerInfoElem.

The presence of both aliases means that it is possible to retrieve the social security number from both a variable holding a message of messageType txmsg:taxpayerInfo as well as an element defined using txtyp:taxPayerInfoElem.

The syntax for a definition is:

messageType="QName"?

part="NCName"?

type="QName"?

element="QName"?>

?

queryContent

...

The interpretation of the messageType and part attributes, as well as the element is the same as in the corresponding from-spec in copy assignments (see section 8.4. Assignment). The one exception is that the default value of the queryLanguage attribute for the element within a is urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0.

[SA00020] A element MUST use one of the three following combinations of attributes:

messageType and part,
type or
element.

If a is defined with the messageType/part combination then the property MUST be available on all WS-BPEL variables where the messageType QName of the variable declaration is identical to that of the . The part attribute and element are applied against the WS-BPEL messageType variable to either set or get the property variable in the same way that the part attribute and element are used in the first from and to specs in assignments.

If a is defined with a type attribute then the property MUST be available on all WS-BPEL variables where the type QName of the variable declaration is identical to that of the . The query is applied against the WS-BPEL variable to either set or get the property variable in the same way that the query is used in the first from and to specs in copy assignments when applied against WS-BPEL variables defined using a type.

If a is defined with an element attribute then the property MUST be available on all WS-BPEL variables where the element QName of the variable declaration is identical to that of the . The query is applied against the WS-BPEL variable to either set or get the property variable in the same way that the query is used in the first from and to specs in copy assignments when applied against WS-BPEL variables defined using an element definition.

Using the same “tns:taxpayerNumber” example from above, for a message variable “myTaxPayerInfoMsg” of messageType txmsg:taxpayerInfoMsg:

and

$myTaxPayerInfoMsg.identification/txtyp:socialsecnumber

have the same output (see section 8.4. Assignment for details).

[SA00022] A WS-BPEL process definition MUST NOT be accepted for processing if it defines two or more property aliases for the same property name and WS-BPEL variable type. For example, it is not legal to define two property aliases for the property tns:taxpayerNumber and the messageType txmsg:taxpayerInfoMsg. The same logic would prohibit having two property aliases on the same element QName and property name value or two property aliases on the same type QName and property name value.

[SA00021] Static analysis MUST detect property usages where property aliases for the associated variable's type are not found in any WSDL definitions directly imported by the WS-BPEL process. As described in 8. Data Handling and 9. Correlation, property usages in WS-BPEL include , getVariableProperty functions as well as assign activity copy and property formats.

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