Issue 126 - Proposal For Vote

["Yaron Y. Goland" <ygoland@bea.com>]

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>