[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]