[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 123 - Proposal to Vote
Well, in theory
I could receive a request in a scope and then use an eventHandler for the reply
because the reply is dependent on another message which occurs
non-deterministically relative to the scope. I know, we may then exit the
scope prematurely and there may be better options J S. From: Alex Yiu [mailto:alex.yiu@
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 resolves to a
messageExchange declared in a scope (where the process is considered the root
scope) which encloses the reply activity and its corresponding IMA. The
messageExchange resolution follows follows common lexical scoping rules,
similar to variable resolution. A messageExchange resolves to the nearest
enclosing scope.
Issue 123 - Proposed changes to the 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 correspond to a messageExchange declared in a scope (where the process is
considered the root scope) which encloses the reply activity and its
corresponding IMA. 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 said to be null. For
matching purposes two null messageExchanges are said to match. However a null
messageExhange does not match a non-null messageExchange. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]