Note: This new proposal adds text to the original proposal to provide a
more robust model to explain exactly how the local message variable and
inline correlation sets on an onEvent handler actually work. But this
proposal does not add or remove any functionality from the original
proposal.
Issue 126 - Event Handlers with local partnerLinks & Correlation Sets
Disclaimer: This proposal is contingent on my propose for 139 passing
Proposal: Add the ability to declare correlation sets inside of an
onEvent handler for use within a specific onEvent instance.
Rationale: Issue 126 brought up two questions. The first question was
based on my assumption that partnerRoles are used to filter incoming
messages on receives/picks/onEvent handlers. My proposal for issue 139
would make that assumption invalid and so remove my first question.
My second question had to do with correlation set initialization on
event handlers. In some cases, such as the example I gave in the issue
list, we want to be able to have a correlation set whose value is local
to a single event handler instance.
Section 13.5.1
From: The usage and interpretation of correlation is exactly the same as
for receive activities.
To: The usage and interpretation of correlation is exactly the same as
for receive activities with the addition that it is possible to declare
correlation sets inline to an onEvent handler instance. These inline
correlation sets can then be used as part of onEvent’s receive. In
effect something like a virtual scope is declared around the onEvent
handler which contains a local variable declaration for the variable
used to receive the incoming message, a local correlation set
declaration for any correlation sets declared inline to the onEvent
handler and a sequence with a receive, reflecting the receive parameters
of the onEvent handler, and finally the actual activity contained within
the onEvent handler declaration. However this virtual scope is
fundamentally different than a real scope in that it has neither fault
nor compensation handlers, default or otherwise, it also has no name.
The scope exists, such as it can be said to exist at all given that it
is only intended as a model to understand the onEvent handler's variable
behavior and not as an actual entity, only to provide lexical scoping
for the local message variable and inline correlation sets. For example:
…
<scope name="S1">
<compensationHandler>
<sequence>
<compensate scope="S2"/>
</sequence>
</compensationHandler>
<eventHandlers>
<onEvent partnerLink=”travelAgency”
portType=”ns:agent”
operation=”travelUpdate”
messageType=”ns:travelStatsUpdate”
variable=”travelUpdate”>
<correlationSets>
<correlationSet name=”updateCode” properties=”ns:updateCode”/>
</correlationSets>
<correlations>
<correlation set=”travelCode” initialize=”no”/>
<correlation set=”updateCode” initialize=”yes”/>
</correlations>
<scope name="S2">
...
</scope>
</eventHandlers>
…
</scope>
...
In this example a process is managing travel reservations for a customer
and needs to handle reservation updates from the travel booking system.
The onEvent handler is used to receive the update messages which are
correlated using the travelCode property, which is defined and
initialized elsewhere in the process. However sometimes the event
handler needs to contact the travel booking system to follow up on an
update message. To do that the outgoing message needs both the value in
the travelCode property but also the value in an update code included in
the travel update message. This is where the updateCode correlation set,
declared locally to the onEvent handler comes in. When the update
message is received the updateCode correlation set is initialized and
its value made available only to the onEvent handler instance. Note that
the compensation handler on scope S1 directly invokes the compensation
handler on scope S2 defined inside the onEvent handler. This invocation
is legal because the 'notional' virtual scope described above to handle
lexical scoping issues for the onEvent handler does not exist for
purposes of determining which scopes are considered a child of the
parent scope S1. Therefore, from the perspective of the compensation
handler scope S2 is a child of scope S1. Note however that if S2's
compensation handler was invoked the variable used to receive the
message for the onEvent handler as well as any in-line correlation sets
would be visible as the 'notional' virtual scope does have existence for
the purpose of defining the lexical scope for the onEvent handler's
variables.
The BNF for eventHandlers needs to be updated in sections 6.2 and 13.5
to the following:
<eventHandlers>?
<!-- Note: There must be at least one onEvent or onAlarm handler. -->
<onEvent partnerLink="ncname" portType="qname"?
operation="ncname" messageType="qname" variable="ncname"
messageExchange="ncname"? >*
* <correlationSets>?
* <correlationSet name="ncname"
properties="qname-list"/>+
* </correlationSets>
<correlations>?
<correlation set="ncname"
initiate="yes|rendezvous|no"?/>+
</correlations>
activity
</onEvent>
<onAlarm>*
( <for expressionLanguage="anyURI"?>duration-expr</for> |
<until expressionLanguage="anyURI"?>deadline-expr</until> )?
<repeatEvery
expressionLanguage="anyURI"?>duration-expr</repeatEvery>? activity
</onAlarm>
</eventHandlers>
