[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. 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 >. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]