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

Also wanted to remind people of the thought that I had:

Add a "variable" attribute that would be used for one-way operations.  
Then change "inputVariable" and "outputVariable" to "requestVariable" 
and "responseVariable" for use in request-response operations.  One more 
attribute to keep track of, but you get better semantics when you don't 
have to reuse an attribute.


Alex Yiu wrote:

> 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.
> Thanks!
> REgards,
> 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
>> pattern="request|response|request-response"
>> 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
>> DK
>> ----- 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>
>> </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 
>> .
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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