[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Comments on Event Handlers
Peter, sorry for keeping you unnecessary busy, but my note was not intended to just address issue # 36 but was to address event handlers in general as promised in the last TC call... Cheers, dieter |---------+------------------------------> | | "Furniss, Peter" | | | <Peter.Furniss@chor| | | eology.com> | | | | | | 07/21/2003 12:43 PM| | | | |---------+------------------------------> >---------------------------------------------------------------------------------------------------------------------------------------------| | | | To: "Monica J. Martin" <monica.martin@sun.com>, <edwink@collaxa.com> | | cc: Dieter Roller/Germany/IBM@IBMDE, <wsbpel@lists.oasis-open.org> | | Subject: RE: [wsbpel] Comments on Event Handlers | | | | | >---------------------------------------------------------------------------------------------------------------------------------------------| 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 > > --------------------------------------------------------------------- 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]