[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. Danny 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 > OASIS > 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]