Issue - 12 - Proposal For Vote

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

Issue 12 - XML types and WS Interactions

Proposal: Allow messaging activities involving messageTypes with a 
single part defined using an element (e.g. a WS-I doc/lit) to submit a 
BPEL variable of the same element type as the part directly to the 
message activity rather than having to submit a BPEL messageType variable.

Rationale: Today all message activities in BPEL require the use of a 
WSDL messageType variable. But moving forward it is expected that WS-I’s 
doc/lit design pattern will be a common Web Services design pattern. 
This pattern requires that a message have exactly one part and that the 
part be defined using an element. In other words messages having to look 
something like:

<xsd:element name="myElem">
     <xsd:complexType>
        <xsd:sequence>
           <xsd:element name="xsdtns:detail" ... />
        </xsd:sequence>
     </xsd:complexType>
</xsd:element>
...
<wsdl:message name="myMsgType">
     <wsdl:part name="myPartName" element="xsdtns:myElem" />
</wsdl:message>

Rather than requiring users to wrap the single element of content into a 
messageType variable it would be much simpler to allow, in these cases, 
for the user to directly submit an element BPEL variable to the message 
operation. The consequence is that a BPEL which only deals with WS-I 
compliant doc/lit operations would never need to use messageType 
variables at all. They could just use element variables.

Allowing this optimization, besides making BPEL code simpler, would also 
put BPEL in very good shape for the eventual transition to WSDL 2.0. 
WSDL 2.0 messages do not have any parts at all and are defined 
exclusively using XML elements. So by allowing for message activities 
that interact with WSDL 1.1 messages with a single element-based part to 
avoid using messageType variables and just use XML variables we make it 
much easier for BPEL 2.0 code to make the transition to a WSDL 2.0 world.

Changes Required: This proposal depends on issue 93 and 145. In the case 
where a messageType consists of a single part defined using an element 
it will be legal to submit a BPEL element variable instead of a 
messageType variable to messaging activities. The onEvent handler will 
be extended to have an element attribute in addition to a messageType 
attribute. The catch semantics are extended so that if there is no 
messageType based catch that matches a fault whose data is a messageType 
then if the messageType has one part defined using an element then a 
matching element based catch can grab it.

Section 11.3

Add to the end of the section:
If the WSDL operation used to send and/or receive a message in an invoke 
activity is defined as a message containing exactly one part which 
itself is defined using an element then a BPEL variable of the same 
element type as used to define the part MAY be submitted directly to the 
invoke activity. The result of submitting a BPEL variable in the 
previously defined circumstance MUST be the equivalent of declaring an 
anonymous temporary WSDL message variable based on the associated WSDL 
message type. In the case of an inputVariable the value of the submitted 
BPEL variable will be used to set the value of the part in the anonymous 
temporary WSDL message variable. In the case of an outputVariable the 
value of the received part in the temporary WSDL message variable will 
be used to set the value of the submitted BPEL variable.

Section 11.4

Insert after the paragraph that begins “It is permissible to have the 
createInstance attribute”:
If the WSDL operation used to receive or send a message in a 
request/reply activity is defined as a message containing exactly one 
part which itself is defined using an element then a BPEL variable of 
the same element type as used to define the part MAY be submitted 
directly to the request/reply activity. The result of submitting a BPEL 
variable in the previously defined circumstance MUST be the equivalent 
of declaring an anonymous temporary WSDL message variable based on the 
associated WSDL message type. In the case of a receive activity, the 
incoming part’s value will be used to set the value of the submitted 
BPEL variable. In the case of a reply activity the value of the 
submitted BPEL variable will be used to set the value of the part in the 
anonymous temporary WSDL message variable that is sent out. In the case 
of a reply that is sending a fault the same logic applies but using a 
fault name rather than an operation name.

Section 12.4

Change: Each pick activity MUST include at least one onMessage event. 
The semantics of the onMessage event is identical to a receive activity 
regarding the optional nature of the variable attribute, the handling of 
race conditions, and the constraint regarding simultaneous enablement of 
conflicting receive actions.

To: Each pick activity MUST include at least one onMessage event. The 
semantics of the onMessage event is identical to a receive activity 
regarding the optional nature of the variable attribute, the handling of 
race conditions, the single element-based part message short cut and the 
constraint regarding simultaneous enablement of conflicting receive actions.

Section 13.4

Change: A fault response to an invoke activity is one source of faults, 
with obvious name and data aspects based on the definition of the fault 
in the WSDL operation.

To: A fault response to an invoke activity is one source of faults, with 
name and data aspects based on the definition of the fault in the WSDL 
operation.

Change: Because of the flexibility allowed in expressing the faults that 
a catch activity can handle, it is possible for a fault to match more 
than one fault handler. The following rules are used to select the catch 
activity that will process a fault:
•	If the fault has no associated fault data, a catch activity that 
specifies a matching faultName value and no faultVariable attribute will 
be selected if present. Otherwise, the default catchAll handler is 
selected if present.
•	If the fault has associated fault data, a catch activity specifying a 
matching faultName value and a faultVariable whose type (WSDL message 
type) matches the type of the fault’s data will be selected if present. 
Otherwise, a catch activity with no specified faultName and with a 
faultVariable whose type matches the type of the fault data will be 
selected if present. Otherwise, the default catchAll handler is selected 
if present.
If no catch or catchall is selected, the fault is not caught by the 
current scope and is rethrown to the immediately enclosing scope (see 
Implicit Fault and Compensation Handlers for a more complete description 
of the default fault and compensation handling behavior). If the fault 
occurs in (or is rethrown to) the global process scope, and there is no 
matching fault handler for the fault at the global level, the process 
terminates abnormally, as though an exit activity had been performed.

To: Because of the flexibility allowed in expressing the faults that a 
catch activity can handle, it is possible for a fault to match more than 
one fault handler.

In the case of faults thrown without associated data the fault will be 
caught as follows:
•	If there is a catch activity with a matching faultName value that does 
not specify a faultVariable attribute then the fault is passed to the 
identified catch activity.
•	Otherwise if there is a catchAll handler then the fault is passed to 
the catchAll handler.
•	Otherwise the fault is thrown to the immediately enclosing scope.

In the case of faults thrown with associated data the fault will be 
caught as follows:
•	If there is a catch activity with a matching faultName value that has 
a faultVariable whose type matches the type of the fault data then the 
fault is passed to the identified catch activity.
•	Otherwise if the fault data is a WSDL message type where the message 
contains a single part defined by an element and there exists a catch 
activity with a matching faultName value that has a faultVariable whose 
type matches the type of the element used to define the part then the 
fault is passed to the identified catch activity with the faultVariable 
initialized to the value in the single part’s element.
•	Otherwise if there is a catch activity without a faultName attribute 
that has a faultVariable whose type matches the type of the fault data 
then the fault is passed to the identified catch activity.
•	Otherwise if the fault data is a WSDL message type where the message 
contains a single part defined by an element and there exists a catch 
activity without a faultName attribute that has a faultVariable whose 
type matches the type of the element used to define the part then the 
fault is passed to the identified catch activity with the faultVariable 
initialized to the value in the single part’s element.
•	Otherwise if there is a catchAll handler then the fault is passed to 
the catchAll handler.
•	Otherwise the fault is thrown to the immediately enclosing scope.

If the fault occurs in (or is rethrown to) the global process scope, and 
there is no matching fault handler for the fault at the global level, 
the process terminates abnormally, as though an exit activity had been 
performed. See Implicit Fault and Compensation Handlers for a more 
complete description of the default fault and compensation handling 
behavior.

Section 13.5

Change the onEvent element definition to make messageType optional and 
add an optional element attribute.

      <onEvent partnerLink="ncname" portType="qname"?
           operation="ncname" variable="ncname"?
           (messageType="qname" | element="qname" )? >

Insert after the schema: All instances of onEvent MUST use either the 
messageType or element attribute but not both.


Section 13.5.1

Change: The messageType attribute specifies the type of the variable by 
referencing a message type definition using its QName. The type of the 
variable (as specified by the messageType attribute) must be the same as 
the type of the input message defined by operation referenced by the 
operation attribute. The variable and messageType attributes constitute 
the declaration of a variable of that name and type within an implicit 
scope associated with the event handler.

To: The messageType attribute specifies the type of the variable by 
referencing a message type definition using its QName. The type of the 
variable (as specified by the messageType attribute) must be the same as 
the type of the input message defined by operation referenced by the 
operation attribute. Optionally the messageType attribute may be omitted 
and instead the element attribute substituted if the message to be 
received has a single part and that part is defined with an element type 
that matches the element type referenced by the element attribute. The 
variable and messageType/element attribute constitute the declaration of 
a variable of that name and type within an implicit scope associated 
with the event handler. If an element attribute is used then the binding 
of the incoming message to the variable declared in the onEvent handler 
occurs as specified for the receive activity in section 11.4.