Issue - 110 - Proposal for Vote

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

Replace Section 11.3 with:

BPEL processes can call Web Services to perform work on their behalf 
(see Partner Link Types, Partner Links and Endpoint References). A BPEL 
process invokes a web service using the invoke activity.

<invoke partnerLink="ncname" portType="qname"? operation="ncname"
	requestVariable="ncname"? responseVariable="ncname"?
	standard-attributes>
	standard-elements
	<correlations>?
	     <correlation set="ncname" initiate="yes|no"?
		pattern="request|response|request-response"/>+
	    </correlations>
	<catch faultName="qname" faultVariable="ncname"?
                           faultMessageType="qname"?>*
	        activity
	</catch>
	<catchAll>?
	        activity
	</catchAll>
	<compensationHandler>?
	      activity
	</compensationHandler>
</invoke>

The invoke activity is used anytime a BPEL process wishes to send a 
message to another web service. In the case of a one-way message 
exchange pattern (MEP) the invoke activity will return as soon as the 
message is sent. In the case of a request/response MEP the invoke 
activity will not return until the response is received, this behavior 
applies even if the underlying request/response MEP is asynchronous.

On a one-way MEP the requestVariable attribute is used to specify the 
message to be sent. The responseVariable attribute is not used as no 
response is sent to a one-way MEP. On a request/response MEP the 
requestVariable attribute is used to specify the message to be sent and 
the responseVariable attribute is used to record the response that is 
returned.

The partnerLink, portType and operation attributes play their usual 
roles of identifying exactly what message is to be sent and to whom.

Correlation sets MAY be used on invoke activities to coordinate with 
stateful partner processes. See Correlation for more information.

The invoke activity has an in-line fault handler. The in-line fault 
handler allows the invoke activity to handle any WSDL fault messages 
that may be received in response to a request/response MEP directly 
within the invoke activity itself. If the invoke activity's fault 
handler does not catch a WSDL or other fault then the fault will be 
thrown to the scope that encloses the activity (see Scopes and Fault 
Handlers).

Note that a WSDL fault is identified in BPEL by a qualified name formed 
by the target namespace of the corresponding portType and the fault 
name. This uniform naming mechanism must be followed even though it does 
not accurately match WSDL’s fault naming model. Because WSDL does not 
require that fault names be unique within the namespace where the 
service operation is defined, all faults sharing a common name and 
defined in the same namespace are indistinguishable in BPEL. In WSDL 1.1 
it is necessary to specify a portType name, an operation name, and the 
fault name to uniquely identify a fault. This limits the ability to use 
fault-handling mechanisms to deal with invocation faults.

Finally, the invoke activity has an in-line compensation handler. This 
compensation handler can be invoked either explicitly or by the default 
compensation handler of the enclosing scope (see Scopes and Compensation 
Handlers).

Semantically, the specification of local fault and/or compensation 
handlers is equivalent to the presence of an implicit scope immediately 
enclosing the activity and providing those handlers. The name of such an 
implicit scope is always the same as the name of the activity it encloses.

The following example shows an invocation with a nested compensation 
handler. Other examples are shown throughout the specification.

<invoke partnerLink="Seller" portType="SP:Purchasing"
	operation="SyncPurchase"
	requestVariable="sendPO"
	responseVariable="getResponse">
       <compensationHandler>
	<invoke partnerLink="Seller" portType="SP:Purchasing"
	     operation="CancelPurchase"
	    requestVariable="getResponse"
	    responseVariable="getConfirmation">
       </compensationHandler>
</invoke>

Section 10.2

From: Finally, in the case of invoke, when the operation invoked is 
synchronous request/response, a pattern attribute is used to indicate 
whether the correlation applies to the outbound (request) message, the 
inbound (response) message, or both.

To: Finally, in the case of invoke, when the operation invoked is a 
request/response message exchange pattern, a pattern attribute is used 
to indicate whether the correlation applies to the request message, the 
response message, or both.

Entire Spec:

A global replace of inputVariable with requestVariable and 
outputVariable with responseVariable as well as a global replace of all 
values of pattern from in|out|out-in to request|response|response-request.

Schema:

tInvoke

From: <attribute name="inputVariable" type="NCName" use="optional"/>
       <attribute name="outputVariable" type="NCName" use="optional"/>

To: <attribute name="requestVariable" type="NCName" use="optional"/>
     <attribute name="responseVariable" type="NCName" use="optional"/>

tCorrelationWithPattern

From: <enumeration value="in"/>
       <enumeration value="out"/>
       <enumeration value="out-in"/>

To: <enumeration value="request"/>
     <enumeration value="response"/>
     <enumeration value="response-request"/>