[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [wsbpel] Issue - 110 - Proposal for Vote
So here is 110 again, now as an official Proposal for Vote.
Part 1.
In section 10.2, add the following sentence to the end of paragraph
starting with "Correlation set names are used in invoke, ...":
--------------------------------------------------------
The pattern attribute of invoke is only allowed for request-response
operations, and disallowed when a one-way operation is invoked.
--------------------------------------------------------
Part 2.
The values of the pattern attribute are changed from
"out"|"in"|"out-in" to "request"|"response"|"request-response",
respectively (all occurrences in examples):
- in section 10.2, change "out" to "request" (4x)
- in section 10.2, change "in" to "response" (1x)
- in section 13.3.1, change "out" to "request" (4x)
- in section 16.1.3, change "out" to "request" (2x)
The explanation in section 10.2 almost matches already; change one
sentence in the paragraph starting with "Correlation set names are
used in invoke, ..." 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
synchronous request/response, a pattern attribute is used to indicate
whether the correlation applies to the outbound message ("request"),
the inbound message ("response"), or both ("request-response").
--------------------------------------------------------
Part 3.
The consolidated syntax of invoke is (duplicate in 6.2 and 11.3 :-)
as follows:
--------------------------------------------------------
<invoke partnerLink="ncname" portType="qname"? operation="ncname"
inputVariable="ncname"? outputVariable="ncname"?
standard-attributes>
standard-elements
<toPart part="ncname" fromVariable="ncname"/>*
<fromPart part="ncname" toVariable="ncname"/>*
<correlations>?
<correlation set="ncname" initiate="yes|no"?
pattern="request|response|request-response"?/>+
</correlations>
<catch faultName="qname"? faultVariable="ncname"?
faultMessageType="qname"?
faultElement="qname"?>*
activity
</catch>
<catchAll>?
activity
</catchAll>
<compensationHandler>?
activity
</compensationHandler>
</invoke>
--------------------------------------------------------
Kind Regards
DK
Alex Yiu
<alex.yiu@oracle.
com> To
Dieter Koenig1/Germany/IBM@IBMDE
07.12.2005 17:59 cc
wsbpeltc
<wsbpel@lists.oasis-open.org>, Alex
Yiu <alex.yiu@oracle.com>
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
>.
>
>
---------------------------------------------------------------------
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]