[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 123 - Proposal for vote
The following contains some textual updates suggested in an
email from Alex last week. No substantive changes were made. - Chris Issue 123 - Proposed changes to current draft for scoped
messageExchange: 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 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
implicitly declared by the process, onEvent scope and the immediate child scope
of forEach activities marked as parallel. Default message exchange
instances, just like non-default messages exchanges, are 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 instance associated with each onEvent instance.
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 simultaneously so the application must mark the relationship between
the pairs. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]