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.
