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"
> <>
> To
> 16.09.2004 03:15 wsbpeltc
> <>
> 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
>.
>
>
