OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Hi DK,

Just a reminder of what I mentioned in the conf call:
(4) I would prefer keeping "inputVariable" and "outputVariable"  (that 
is not renaming to "requestVariable" and "responseVariable"). Reasoning: 
As Danny mentioned, it would be odd to use a "requestVariable" attribute 
on a ONE-WAY operation. As Dieter himself mentioned, the inputVariable 
and outputVariable do match the input/output in WSDL definition.
(5) We need to incorporate the latest syntax fromPart and toPart in the 
updated proposal with consolidated <invoke> syntax.


Alex Yiu

Dieter Koenig1 wrote:

>As discussed in the last call and f2f meeting, I am resending the original
>proposal for vote:
>(1) replace the terms "asynchronous" and "synchronous" in references to the
>pattern attribute with "one-way" and "request/response", respectively
>(2) restrict the use of the pattern attribute to invokes of
>request-response operations only, i.e. do not use pattern together with
>one-way operations
>(3) replace pattern="in|out|out-in" with
>Part (1) has been done already for the whole spec in response to the
>resolution of issue 122.
>Part (3) had been withdrawn by Yaron at the f2f meeting - we may discuss
>this part and amend the proposal ...
>Kind Regards
>----- Forwarded by Dieter Koenig1/Germany/IBM on 17.11.2005 17:52 -----
>             "Yaron Y. Goland"                                             
>             <ygoland@bea.com>                                             
>                                                                        To 
>             16.09.2004 03:15          wsbpeltc                            
>                                       <wsbpel@lists.oasis-open.org>       
>                                                                        cc 
>             Please respond to                                             
>                  ygoland                                          Subject 
>                                       [wsbpel] 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>
>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
>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
>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
>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>
>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.
>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"/>
>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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]