RE: [wsbpel] Comments on Event Handlers

["Edwin Khodabakchian" <edwink@collaxa.com>]

Dieter,

Thank you very much for this detailed description. I have one piece of
comment inline. I would concur with you that the current behavior and the
use serializable scopes offer granular control to the developer.

If this ended up not being acceptable and we where to look for alternative
designs, I am not sure that option #1 (ignoring) concurrent requests would
be viable because the eventHandlers/onMessage...reply could be mapped to a
"getStatus" request/response operation that allows partners to query the
stage of processing of a BPEL process instance. Ignoring a request could be
problematic.

Best,

Edwin

> 
> -----Original Message-----
> From: Dieter Roller [mailto:ROL@de.ibm.com] 
> Sent: Friday, July 18, 2003 6:55 AM
> To: wsbpel@lists.oasis-open.org
> 
> The purpose of event handlers is to carry out some task in 
> parallel to the main task of the business process. An event 
> handler is either attached to a scope or the whole process. 
> An event handler is made ready when the scope/process is 
> entered and disabled when the scope/process exits. An event 
> handler is either invoked through a message received or 
> through some timer interrupt. Whenever a message arrives or 
> the time interrupts, an instance of the appropriate message 
> triggered event handler is created and carried out.
> 
> We have used three different examples for designing event handlers:
> 
> (1) Provide the capability for requestors to obtain some 
> information relative to the current execution of a process 
> instance (query capability).
> 
> (2) Provide the capability for requestors to modify the 
> current processing of a process instance, such as terminating 
> the process instance.
> 
> (3) Provide the capability to perform a certain action at a 
> certain time, such as informing somebody about the business process.
> 
> By its very nature, an event handler shares data with the 
> main stream of the business process or even impacts the main 
> stream (for example by issuing a terminate), but is 
> self-contained. As a consequence, no links must leave the 
> event handler (this is documented in 12.5). This limitation 
> should address issue #36.
> 
> Based on scenario 1, we felt that the specification should 
> assume the parallel processing of several messages; that 
> means the concurrent execution of multiple instances of the 
> same event handler. This behavior results in the concurrency 
> behavior as correctly described in issue #36.
> 
> If this behavior is not acceptable, several approaches can be taken:
> 
> (1) Do not do parallel processing. Process only one message 
> for a particular event handler at a time. If another message 
> for the same event handler arrives when the event handler is 
> processes a message, this new message is ignored
> 
> (2) Add a parameter to the <onMessage> element that specifies 
> the processing behavior of the event handler with different 
> values for different behaviors. Specifying 
> <processing="sharedParallel"> results in the current 
> behavior, specify <processing="oneInstanceOnly" would result 
> in the behavior listed in (1).  I could envision other types 
> of behavior; however that needs more time.
> 
> If data is shared between event handlers and the main part of 
> the process or between event handlers, access to the 
> variables can be controlled by establish appropriate scopes 
> and specify serializability.
> 
> Cheers,
> 
> dieter
> 
> 
> Dieter Roller
> IBM Senior Technical Staff Member (STSM) Member IBM Academy 
> of Technology IBM Germany Development Inc.
> Phone :                 +49-7031-164476
> Fax :                    +49-7031-164890
> e-mail                   rol@de.ibm.com
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> 
>