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: Issue 112 - Proposal For Vote


Issue 112 - Input/Output Elements on Messaging Activities

Proposal: Allow for the use of <fromPart> and <toPart> elements in 
messaging activities to make it easier to handle multi-part messages.

Note: This issue originally proposed using input/output elements but 
this proved confusing on receive/reply/pick so <fromPart> and <toPart> 
were substituted.

Section 11.3:

Add the following to the end of the BNF for invoke:
<toPart part=”ncname”>*
    from-spec
</toPart>
<fromPart part=”ncname”>*
    to-spec
</fromPart>

NOTE: The previous BNF change is also needed in section 6.2

Add the following to the end of section 11.3:

<toPart> elements are a short cut that makes it easier to create 
outgoing multi-part WSDL messages from the contents of BPEL variables. 
The inputVariable attribute MUST NOT be used on an Invoke activity that 
also contains a <toPart> element. The <toPart> elements, as a group, act 
as a single virtual assign where each <toPart> is turned into a copy in 
the virtual assign. The destination of all the copies is an anonymous 
temporary WSDL variable, of the type specified by the relevant WSDL 
operation, which will then be used to send the actual message created by 
the virtual assign. Each <toPart> is turned into a copy by:

1)	Making the from-spec of the copy the same as the from-spec from the 
<toPart> and
2)	Making the to-spec of the copy into a pointer to the part of the 
anonymous temporary WSDL variable referenced in the <toPart>.

The virtual assign MUST follow the same semantics and use the same 
faults as a real assign. When <toPart> is used in an Invoke there MUST 
be a <toPart> for every part in the WSDL message definition and listed 
in the same order as the WSDL definition. The previous requirement MUST 
be enforced statically.

<fromPart> elements are a similar short cut to <toPart> elements, but in 
the inverse. <fromPart> elements are used to pull data out of an 
incoming multi-part WSDL message and place it into individual BPEL 
variables. The outputVariable attribute MUST NOT be used on an Invoke 
activity that also contains a <fromPart> element. The <fromPart> 
elements, as a group, act as a single virtual assign. When a WSDL 
message is received on an Invoke activity that uses <fromPart> the 
message is placed in an anonymous temporary WSDL variable, of the type 
specified by the relevant WSDL operation. The <fromPart> elements are 
then gathered together to form a single virtual assign where each 
<fromPart> is turned into a copy. Each <fromPart> is turned into a copy by:

1)	Making the from-spec of the copy point at the part of the anonymous 
temporary WSDL variable referenced in the <fromPart> and
2)	Making the to-spec of the copy the same as the to-spec from the 
<fromPart>.

The virtual assign MUST follow the same semantics and use the same 
faults as a real assign. When <fromPart> is used in an Invoke there MUST 
be a <fromPart> for every part in the WSDL message definition and listed 
in the same order as the WSDL definition. The previous requirement MUST 
be enforced statically.

A single Invoke can contain any combination of <toPart> elements, 
<fromPart> elements, outputVariable and inputVariable with the 
exception, as previously specified, that if <toPart> elements are used 
then the inputVariable attribute cannot be used and if <fromPart> 
elements are used then the outVariable attribute cannot be used. The 
virtual assign created as a consequence of the use of input or output 
elements occurs as part of the scope of the Invoke activity and 
therefore any faults that are thrown can be caught by the Invoke’s 
inline fault handler. Also note that it is legal to use 
<toPart>/<fromPart> with WSDL messages that only have a single part.

Section 11.4

From:  In addition, it may specify a variable that is to be used to 
receive the message data received.

To: In addition, it may specify a variable, using the variable 
attribute, that is to be used to receive the message data received.

Add the following text to the end of the first paragraph:

An alternative to the variable attribute are <fromPart> elements. The 
syntax and semantics of the <fromPart> elements as used on the receive 
activity are the same as specified in section 11.3 for the Invoke 
activity. This includes the restriction that if <fromPart> elements are 
used on a receive activity then the variable attribute MUST NOT be used 
on the same activity.

Add the following to the receive BNF:

<fromPart part=”ncname”>*
    to-spec
</fromPart>

NOTE: The previous BNF change is also needed in section 6.2

From: A reply activity may specify a variable that contains the message 
data to be sent in reply.

To: A reply activity may specify a variable, using the variable 
attribute, that contains the message data to be sent in reply.

Add the following text to the end of the paragraph that contains the 
previous sentence:

An alternative to the variable attribute are <toPart> elements. The 
syntax and semantics of the <toPart> elements as used on the reply 
activity are the same as specified in section 11.3 for the Invoke 
activity. This includes the restriction that if <toPart> elements are 
used on a reply activity then the variable attribute MUST NOT be used on 
the same activity.

Add the following to the reply BNF:
<toPart part=”ncname”>*
    from-spec
</toPart>

NOTE: The previous BNF change is also needed in section 6.2

Section 12.4

From: 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.

To: 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, the constraint regarding simultaneous enablement of conflicting 
receive actions and the optional use of <fromPart> elements.

Modify the Pick BNF to:

    <onMessage partnerLink="ncname" portType="qname"?
	operation="ncname" variable="ncname"?
         messageExchange="ncname"? >+
      <correlations>?
	<correlation set="ncname" initiate="yes|no"?/>+
      </correlations>
      <fromPart part=”ncname”>*
            to-spec
      </fromPart>
      activity
    </onMessage>

NOTE: The previous BNF change is also needed in section 6.2




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