Proposed changes to section 8.1

["Yaron Y. Goland" <ygoland@bea.com>]

Section 8.1 as it currently exists is so abstract that even though it is 
titled 'motivation' for the Message Properties section it never actually 
uses the word property. I would therefore like to replace it with text 
that is concrete and focuses exclusively on the motivation for 
properties and their design. To that end I propose we replace the 
current section 8.1 text with:

It is common for different messages to carry the same data. For example, 
both a request and a response message may carry the same purchase order 
number, a fact that the receiver may very well use for correlation 
purposes. In theory a business process author should simply be ‘aware’ 
of where the purchase order is recorded in a message and, for example, 
be able to specify a query that points to the location where the 
purchase order data is to be set inside of the request message and be 
able to specify a different query to retrieve the purchase order 
information from the response. But requiring authors to not only know 
the two different locations in the two different message types but to 
also hard code those locations in their business process specifications 
tends to cause problems, especially if one of the messages is redefined. 
This is what led to the introduction of BPEL properties. A property is a 
way to separate out the value of a piece of common data from its 
location in any particular message type.

To fully enable the separation of the data’s value from its location 
properties are defined in two parts. The first part defines a property 
name and an associated type. The declaration of a property can be read 
as “If a property with this name is available on a message variable then 
the data associated with this property is both available and guaranteed 
to be of the specified type.”

To make a particular property available on a specific message type it is 
necessary to identify where the value associated with the property can 
be found in messages of that message type. The property alias is a 
mechanism to associated a query on a part of a message type definition 
with a particular property. The output of the query is required to be of 
the same type as the type specified in the property’s definition.
So, for example, in the previously described scenario a property called 
purchaseOrder may be declared. There would then be two property aliases 
defined, one for the request message and one for the response message. 
Each of the property aliases would reference the name of the 
purchaseOrder property and then provide a query unique to their message 
type identifying where in the message the desired value can be found.

Properties are not variables in the sense that they do not have an 
independent existence. They only exist as ‘projections’ of information 
from an underlying message variable. Whenever a property is accessed on 
a message the returned property value will equal the output of applying 
the query specified in the property alias for that message type against 
the current value of the message. Similarly when copying to a property 
on a message variable what actually occurs is that the value being 
copied is placed in the underlying message at the location identified by 
the query in the associated property alias definition.

Query languages such as XPATH 1.0 make it possible to specify queries 
whose output are not an individual attribute or element value. For 
example, a query could pull a value out of the message and then add 1 to 
it. In those cases there is no unambiguous way to handle assignment. So 
while it is legal to define property aliases of this type and to read 
the values any attempt to assign to a property on a message type where 
the property aliases query doesn’t resolve to an individual attribute or 
element value must fail.

Properties and property aliases are both defined inside of WSDL files 
because properties are so closely associated with message types which 
are themselves defined in WSDLs files. In addition properties are 
considered to be an integral part of the messageType definition and so 
likely to be used by any BPEL process that uses that messageType. 
Placing the property and property alias definitions in the WSDL file 
with the messageType encourages re-use.