Re: [wsbpel] Issue - 145 - Proposal For Vote

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

+1.

This really makes properties more useful, consistent, and will improve 
the readability and maintainability of of BPEL process definitions. I 
like it!

-Ron

Yaron Y. Goland wrote:

> 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.
>
>
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. 
>
>

S/MIME Cryptographic Signature