Hi Alex,
Thanks for the feedback. Comments below:
[1] Ok, I see your point on issue 120.2,
so we’ll limit there refernce to variable and correlationSet as you
suggest.
[2] Good point. Especially since I would
have thought that the missingReply fault would have been thrown by S2 to S1. I
view fault handlers as applying to the contents of the scope not to the scope
activity itself. This is already an issue as when the process ends with
outstanding replies it throws a missingReply fault (section 14.4). I assumed it
is not caught by a process level catch or catchall. It would be good to get
others opinions on this point.
[3] Ok, I’ll take another crack at
wordsmithing the last paragraph with some of your suggestions.
- Chris
From: Alex Yiu [mailto:]
Sent: Wednesday, December 07, 2005
3:49 PM
To:
Cc: 'ws bpel tc'; Alex Yiu
Subject: Re: [wsbpel] Issue 123 -
Proposal for vote
Hi Chris,
Thank you very much for sending the updated proposal out.
Here are some suggestions to fine-tune and supplement to the proposal text:
[1]
From:
"This resolution follows the same scoping rules as variable, partnerLink
and correlationSet resolution."
To:
"This resolution follows the same scoping rules as variable and
correlationSet resolution."
Because, without passing any new resolution e.g. Issue 120.2, the resolution
rule of partnerLink is different those of variable/correlationSet in the case
of <onEvent>.
[2]
About bpws:missingReply,
"Further if an open IMA goes out of scope prior to being closed by a reply
activity then the scope MUST throw a bpws:missingReply fault. In other
words a scope which declares a partnerLink or messageExchange used by an IMA
will not complete normally if that IMA is open when the scope is to
complete." ...
It may not be 100% clear which scope the fault would be thrown to. (Please see
the example below.) Is the missingReply fault thrown to S1 by S2? or the fault
is thrown to S2 by S2 itself? My current interpretation would be: the fault
thrown to S2 by S2.
(Side note: the same missReply fault can happen to the top-level process)
It may be beneficial to add more elaboration by an example:
==============================
For example:
------------------
<scope
name="S1">
...
<scope
name="S2">
<partnerLinks>
<partnerLink name="pl1" ... />
</partnerLinks>
<sequence>
<receive partnerLink="pl1" ... />
<!-- receive without reply -->
</sequence>
</scope>
...
</scope>
------------------
The bpws:missingReply fault is thrown by scope S2 to scope S2 itself.
==============================
[3]
From:
"Default message exchanges are uniquely provided by the process scope,
onEvent scope and the immediate child scope of forEach activities marked as
parallel. A default message exchange is created each time the default message
exchange provider is executed. For example each time an onEvent is
executed (i.e. when a new message arrives for processing) it creates a new
default message exchange. "
To
"Default message exchanges are implicitly declared at the process,
onEvent scope and the immediate child scope of forEach activities marked as
parallel. A default message exchange instance, just like any other
non-default message exchange, is created each time the default
message exchange declaring construct is executed. For example each
time an onEvent is executed (i.e. when a new message arrives for processing) it
creates a new default message exchange instance associated with each onEvent
instance."
Maybe, using "declare" and
"declaring construct" may be better wordings than
"provide" or "provider". Because, it would be parallel
to the notion of declaring a variable or a CS. (Not a strong preference
here ... though)
I would suggest to change from
"process" to "process scope". Because, people may
confuse it with the situation of the direct child scope under process.
It would be a good idea to add
"instance" to message exchange here. Similar to an instance of
variable and etc.
The creation of default message exchange instance
is similar to the creation of non-default message exchange instance. It
would be better to stress that. So people would not mis-interprete that
semantics are specific to default message exchange.
I hope all these suggestions sounds reasonable to you.
Thanks!
Regards,
Alex Yiu
Chris Keller wrote:
Below is the updated proposal for vote where a
default message exchange has been introduced in the last paragraph.
- Chris
Issue 123 - Proposed changes to current draft for
scoped messageEchange:
In section 6.2 add to the informal syntax describing
the XML grammar for both the process element and the scope element between
partnerLinks and variables the following:
<messageExchanges>?
<messageExchange
name="ncname"/>+
</messageExchanges>
Change the following paragraphs from Section 11.4:
The optional messageExchange attribute is used to
associate a <reply> activity with an inbound message activity, such as,
<receive>, <onMessage> and <onEvent>, when there are multiple
simultaneously incomplete inbound message activities which requires a reply
message to complete.
A reply activity is associated with a inbound message
activity based on the tuple - partnerLink, operation, and messageExchange. The
value defined in messageExchange is scoped to the combination of partnerLink
and operation. That is, it is legal to use the same messageExchange value in
multiple simultaneously incomplete receive activities so long as the
combination of partnerLink and operation on the receives are all different from
each other. An incomplete inbound message activity describes the state of a
BPEL process from the point that a request/response receive activity starts
execution until its associated reply begins execution.
If there should ever be multiple simultaneous
incomplete inbound message activities which have the same partnerLink,
operation and messageExchange tuple then the bpws:conflictingRequest fault MUST
be thrown within the BPEL process on the conflicting inbound message activities
subsequent to the execution of the successful incomplete receive.
If a reply activity cannot be associated with an
incomplete receive activity by matching the tuples and this error situation is
not caught during static analysis, then bpws:missingRequest fault MUST be
thrown within the BPEL process on the reply activity. Because conflicting
requests should have been rejected at the time inbound message activity is
executed, there cannot be more than one corresponding inbound message activity
at the time <reply> is executed.
If the messageExchange attribute is not specified on
a receive then its value is taken to be empty. For matching purposes two empty
messageExchange values with the same partnerLink and operation values are said
to match. Empty value does not match with other non-empty values.
To the following:
A reply activity is associated with an inbound
message activity (IMA), such as, <receive>, <onMessage> and
<onEvent> based on the tuple - partnerLink, operation, and
messageExchange. The name used in the optional messageExchange attribute
MUST resolve to a messageExchange declared in a scope (where the process is
considered the root scope) which encloses the reply activity and its
corresponding IMA. This resolution follows the same scoping rules as
variable, partnerLink and correlationSet resolution.
An open IMA describes the state of a Web service
operation from the point that a request/response IMA starts execution until an
associated reply begins execution. It is illegal to have multiple simultaneous
open IMAs, which have the same partnerLink, operation and messageExchange
tuple. A BPEL process MUST throw a bpws:conflictingRequest fault when the
conflicting IMA begins execution. Note that it is legal to use the same
messageExchange in multiple simultaneously open IMAs so long as the combination
of partnerLink and operation on the IMAs are all different from each other.
If a reply activity cannot be associated with an open
IMA by matching the tuples (partnerLink, operation, and messageExchange) then a
bpws:missingRequest fault MUST be thrown within the BPEL process on the reply activity.
Because conflicting requests MUST be rejected at the time the IMA begins
execution there cannot be more than one corresponding IMA at the time a reply
activity is executed. Further if an open IMA goes out of scope prior to being
closed by a reply activity then the scope MUST throw a bpws:missingReply
fault. In other words a scope which declares a partnerLink or
messageExchange used by an IMA will not complete normally if that IMA is open
when the scope is to complete.
If the messageExchange attribute is not specified on
an IMA or reply then the activity's messageExchange is automatically associated
with a default message exchange with no name. Default message exchanges
are uniquely provided by the process scope, onEvent scope and the immediate child
scope of forEach activities marked as parallel. A default message
exchange is created each time the default message exchange provider is
executed. For example each time an onEvent is executed (i.e. when a new
message arrives for processing) it creates a new default message exchange. This
prevents an onEvent handler, which doesn't specify a messageExchange, for
request-reply operations from faulting when a message is received while there
is already another instance of the onEvent handler processing a message that
has not reached its reply point. Similarly it allows most parallel
forEach receive(or pick)-reply pairs to be described without the need to
introduce a messageExchange. The use of messageExchange for most
applications is required only for cases where the execution of a flow can
result in receives(or pick)-replies on the same partnerLink and operation
executed simulateneously so the application must mark the relationship between
the pairs.
