Hi,
Sorry for joining the conversation a bit late.
We share reservation about this term changes with Danny from TIBCO.
The "request/response" terms ties too much to:
(a) a RPC-like / network-sync protocol. And,
(b) a WSDL 1.1 MEP term which may not exist in WSDL 2.0
However, I agree that we may need to spend some effort to clarify the
terms used in correlation pattern.
Thanks!
Regards,
Alex Yiu
Yaron Y. Goland wrote:
> 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"/>
>
> To unsubscribe from this mailing list (and be removed from the roster
> of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.
>
>
