OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsbpel] Issue 126 - Proposal For Vote


Satish Thatte wrote:

>I think this would go a bit too far -- for instance we don't want to
>compensate event handler instances.
>  
>
I'm not too concerned about allowing compensation of event handlers, or 
even enclosing event handlers within event handlers. You can already do 
that by enclosing the main activity in a scope. The shortcut I'm looking 
for is to have less text in the spec to provide the same set of 
functionality.

Assaf

>-----Original Message-----
>From: Assaf Arkin [mailto:arkin@intalio.com] 
>Sent: Tuesday, March 08, 2005 2:24 AM
>To: ygoland@bea.com
>Cc: wsbpeltc
>Subject: Re: [wsbpel] Issue 126 - Proposal For Vote
>
>Why don't we just define onEvent as an extension of scope?
>
>That would allow us to have local partner links, local variable 
>declarations and local correlation sets, all of which seem quite useful 
>for event handlers that can be invoked more than once. And it will 
>simplify the specification if we don't have to explain how 
>links/variables/correlations are used in two different contexts, when 
>the usage is identical.
>
>assaf
>
>Yaron Y. Goland wrote:
>
>  
>
>>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>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
>>For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>>
>>
>>    
>>
>
>
>  
>

begin:vcard
fn:Assaf Arkin
n:Arkin;Assaf
org:Intalio
adr;dom:;;1000 Bridge Parkway Ste 210;Redwood City;CA;94065
email;internet:arkin@intalio.com
title:Chief Architect
tel;work:(650) 596-1800
x-mozilla-html:TRUE
url:http://www.intalio.com
version:2.1
end:vcard

S/MIME Cryptographic Signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]