Concrete handlers, derived from an abstract handler,
must provide a method, such as operate(Event)
that can be called by the reactor
when the handler is selected after receiving an event.
slide: The Reactor Pattern - interaction
The interaction between the application, its handlers, the
reactor and the environment from which
the events originate is depicted
in slide [reactor-interaction].
First, the reactor must be initialized,
then one or more handlers can be registered,
providing a binding for particular types of events.
The reactor must then start to execute
its eventloop.
When it receives an event from the environment,
it selects a handler and dispatches the event to that handler,
by calling operate(Event).
Consequences
Modularity is
one of the advantages of an event-driven software architecture.
Handlers can be composed easily, since their
invocation is controlled by the reactor.
Another advantage is the decoupling of
application-independent mechanisms from
application-specific policies.
In other words, handler objects need not be aware
of how events are dispatched. This is the responsibility
of the system or framework.
The fact that control is handed over to
the environment has, however, also some disadvantages.
First of all, as experience with student assignments shows,
it is difficult to learn in the beginning.
But even when mastered, applications may be hard
to debug, since it is not always clear why a particular handler
was invoked, and because it may be difficult to repeat
the computation preceding the fault.
Applicability
Some variant of the reactor pattern is
used in Unix (X) Windows, (MS) Windows, and also GUI libraries
such as Interviews, ET++ and hush.
Another example is the Orbacus object request broker, that
supports a reactor mode for
server objects, which allows for receiving messages
from multiple sources in a single thread.
The Orbacus broker, however, also allows for multi-threaded
servers.