OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Fw: [wsbpel] Issue - 145 - Proposal For Vote



Yaron's proposal in line in text:

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. Clarify the matching rules for properties/propertyAliases/variables. Update the terminology to make message properties a type of variable properties.  Also fixed a bug where there is an ambiguity as to what happens if two propertyaliases for the same property on the same message type, the new text requires this to be statically detected and rejected.

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="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

To
<wsbpel@lists.oasis-open.org>
cc
Subject
[wsbpel] Issue - 145 - Proposal For Vote





I'm sitting in the meeting so I don't have time to translate this to text. Sorry.
Yaron
bscribe 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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]