[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fw: [wsbpel] Issue - 145 - Proposal For Vote
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="qname"?>
<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 where the qname value used in the messageType attribute on the declaration of both the variable and the propertyAlias are identical. 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 where the qname value used in the type attribute on the declaration of both the variable and the propertyAlias are identical. 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 where the qname value used in the element attribute on the declaration of both the variable and the propertyAlias are identical. 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.
A BPEL process MUST NOT be accepted for processing if it defines two or more propertyAlias’s for the same property name and BPEL variable type. For example, it is not legal to define two propertyAlias’s for the property taxpayernumber and the messageType txmsg:taxpayerInfoMsg. The same logic would prohibit having two propertyAliases on the same element qname and property name value or two propertyAliases on the same type qname and property name value.
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.
Regards, Diane
IBM Emerging Internet Software Standards
drj@us.ibm.com
(919)254-7221 or 8-444-7221, Mobile: 919-624-5123, Fax 845-491-5709
----- Forwarded by Diane
Jordan/Raleigh/IBM on 12/15/2004 10:25 AM -----
"Yaron Goland"
<ygoland@bea.com>
12/15/2004 09:29 AM |
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]