Re: [wsbpel] Issue - 110 - Proposal for Vote

[Alex Yiu <alex.yiu@oracle.com>]

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