[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]