[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 145 - Proposal For Vote
Issue 145 - Properties on Non-Message Variables
Proposal: Allow for the definition of properties on non-WSDL messages.
Rationale: Properties represent a fundamental design approach where
information in potentially very complex XML variables is made available
in a simple name/value fashion. This feature is just as useful for
regular XML variables as it is for WSDL messages and should be available
for both.
Changes Required: Change propertyAlias to make messageType and part
attributes optional and introduce element and type attributes. Specify
that getVariableProperty can take arbitrary BPEL variables as arguments.
Update the terminology to make message properties a type of variable
properties.
Section 1:
From: WS-BPEL uses a notion of message properties to identify
protocol-relevant data embedded in messages.
To: WS-BPEL uses a notion of message properties, which are a type of
variable property, to identify protocol-relevant data embedded in messages.
Section 6.4:
From: Process definitions also rely on other constructs such as partner
link types, message 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.
To: 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.
Section 8:
Change title to “Variable Properties”
Note: There are references in the spec to (see Message Properties) this
will need to be changed to (see Variable Properties)
Section 8.1:
Create section 8.1.1 titled “Motivation for Message Properties”, insert
current section 8.1 text there.
Create section 8.1.2 titled “Motivation for Variable Properties” with
the following value:
Message properties are an instance of a more generic mechanism, variable
properties. All variables in BPEL can have properties defined on them.
Properties are useful on non-message variables as a way to isolate the
BPEL process’s logic from the details of a particular variable’s
definition. Using properties a BPEL process can isolate its variable
initialization logic in one place and then set and get properties on
that variable in order to manipulate it. If the variable’s definition is
later changed the bulk of the BPEL process definition that manipulates
that variable can remain unchanged.
Section 8.2:
From: “Properties can occur anywhere in a message, including in the
message context.”
To “Properties can occur anywhere in a variable.”
Insert the following paragraph after the existing paragraph that begins
“In correlation, the property name must have global significance…”:
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 the property is available on is therefore
expected to provide a value that meets not just the syntax of the
property definition but also its semantics.
End section 8.2 after the schema for property definitions (which this
proposal does not change).
Insert section 8.3 titled "Defining Property Aliases", the content of
this new section is based on the text that was originally in section 8.2
after the property schema definition:
Properties used in business protocols are typically embedded in
application-visible variables. The notion of aliasing is introduced to
map a global 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 Assignment in
abstract business processes. As an example, consider the following WSDL
message definition:
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<definitions name="messages"
targetNamespace="http://example.com/taxMessages.wsdl";
xmlns:txtyp="http://example.com/taxTypes.xsd";
xmlns="http://schemas.xmlsoap.org/wsdl/";>
<!-- define a WSDL application message -->
<message name="taxpayerInfoMsg">
<part name="identification" element="txtyp:taxPayerInfoElem"/>
</message>
...
</definitions>
The definition of a global property and its location in a particular
field of the message are shown in the next WSDL fragment:
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<definitions name="properties"
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";
xmlns="http://schemas.xmlsoap.org/wsdl/";>
<!-- define a correlation property -->
<bpws:property name="taxpayerNumber" type="txtyp:SSN"/>
...
<bpws:propertyAlias propertyName="tns:taxpayerNumber"
messageType="txmsg:taxpayerInfoMsg" part="identification">
<query>
/txtyp:taxPayerInfoElem/txtyp:socialsecnumber
</query>
</bpws:propertyAlias>
<bpws:propertyAlias propertyName="tns:taxpayerNumber"
element="txtyp:taxPayerInfoElem">
<query>
/txtyp:taxPayerInfoElem/txtyp:socialsecnumber
</query>
</bpws:propertyAlias>
</definitions>
The first bpws:propertyAlias defines a globally named property
tns:taxpayerNumber as an alias for a location in the identification part
of the message type txmsg:taxpayerInfo.
The second bpws:propertyAlias provides a second definition for the same
globally 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 propertyAlias definition is:
1234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6
<definitions name="ncname"
... >
<bpws:propertyAlias propertyName="qname"
messageType="qname"? part="ncname"?
type="qname"? element="ncname"?>
<query queryLanguage="anyURI"?>?
... queryString ...
</query>
</bpws:propertyAlias>
...
</wsdl:definitions>
A property alias element MUST use one of the three following
combinations of attributes:
• messageType and part,
• type or
• element.
When a propertyAlias is used with the messageType/part combination then
the property MUST be available on all BPEL variables declared with the
same messageType. The part attribute and query element is applied
against the BPEL messageType variable to either set or get the property
variable in the same way that the part attribute and query element are
used in the first from and to specs in copy assignments.
If a propertyAlias is used with a type attribute then the property MUST
be available on all BPEL variables of that type. The query is applied
against the 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 BPEL variables defined using a type.
If a propertyAlias is used with an element attribute then the property
MUST be available on all BPEL variables declared using the same element.
The query is applied against the 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 BPEL
variables defined using an element definition.
Section 9.0
From: Abstract processes are restricted to limited manipulation of
values contained in message properties but are permitted to use
nondeterministic values to reflect the consequences of hidden private
behavior.
To: Abstract processes are restricted to limited manipulation of values
contained in variable properties but are permitted to use
nondeterministic values to reflect the consequences of hidden private
behavior.
Section 9.1
From: If the given property does not appear in any of the parts of the
variable's message type, then the semantics of the process is undefined.
To: If the referenced property is not defined or if there does not exist
a propertyAlias to associate the property with the referenced variable
then the semantics of the process is undefined.
Section 9.3
From: The third from-spec and to-spec variants allow explicit
manipulation of message properties (see Message Properties) occurring in
variables.
To: The third from-spec and to-spec variants allow explicit manipulation
of variable properties (see Variable Properties) occurring in variables.
Section 10.2
From: They are abstract in the sense that their occurrence in messages
needs to be separately specified (see Message Properties).
To: They are abstract in the sense that their occurrence in variables
needs to be separately specified (see Variable Properties).
Section 14.1
From: If the given property does not appear in any of the parts of the
variable's message type or the given property definition selects a node
set of a size other than one, then the standard fault
bpws:selectionFailure MUST be thrown by a compliant implementation.
To: If the referenced property is not defined, if there does not exist a
propertyAlias to associate the property with the referenced variable or
if the given property definition selects a node set of a size other than
one, then the standard fault bpws:selectionFailure MUST be thrown by a
compliant implementation.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]