[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 123 - Proposal for vote
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:alex.yiu@oracle.com]
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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]