[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 110 - Proposal for Vote
Danny, I added a sentence with RFC 2119 "MUST" language for static
analysis.
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. Any
violation of this rule MUST be detected during 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
Danny van der
Rijn
<dannyv@tibco.com To
> wsbpeltc
<wsbpel@lists.oasis-open.org>
08.12.2005 18:37 cc
Subject
Re: [wsbpel] Issue - 110 - Proposal
for Vote
Dieter Koenig1 wrote:
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
--------------------------------------------------------------------- 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]