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



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

12/15/2004 09:29 AM

To

<>

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.