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: Comments on Event Handlers


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




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