[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 110 - Proposal for Vote
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"/>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]