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.
--------------------------------------------------------
RFC 2119 "MUST" language for static analysis?
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