RE: [wsbpel] Comments on Event Handlers

["Furniss, Peter" <Peter.Furniss@choreology.com>]

I've linked the existing messages with this title to issue 36. But it's
easier (for me) if follow up messages
have Issue - ## - in them.

the links are in the current "editor's working copy" on
http://www.choreology.com/external/WS_BPEL_issues_list.html. I intend to
upload the then issues list as a TC document about 24 hours before our
next call.

Peter

> -----Original Message-----
> From: Monica J. Martin [mailto:monica.martin@sun.com] 
> Sent: 18 July 2003 20:25
> To: edwink@collaxa.com
> Cc: 'Dieter Roller'; wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] Comments on Event Handlers
> 
> 
> Edwin Khodabakchian wrote:
> 
> >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.
> >  
> >
> mm1: Since Edwin and Dieter are attaching this conversation 
> to Issue 36, 
> I would ask you provide it in the formal Subject line so the comments 
> will be added to the issue and be available to the TC in that 
> context.  
> Thanks.
> 
> >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
> >>
> >>
> >>    
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> >For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> >
> >  
> >
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> 
>