$URL: svn+ssh://christianc@svn.forge.objectweb.org/svnroot/barracudamvc/Barracuda2/trunk/WEB-INF/src_docs/architecture/comp/overview.html $ - $Revision: 125 $
Event Delivery Flow
It might be helpful to provide a basic summary of how events are
delivered.
- Everything starts in the ApplicationGateway. When the servlet is
initialized, we can add any known EventGateways, and these in turn will
be used to register EventHandlers with the EventBroker.
- When the application gateway receives an HTTP request, it must first
figure out what event the URL maps to. The URL must specify an event
name, and optionally may specify specific listener IDs that should
receive the event. If the URL does NOT correspond to a valid event, OR
if the event is not an instance of HttpRequestEvent, it will not be
dispatched. Instead, a generic HttpRequestEvent will be created and
delivered.
- Once the application gateway knows the name of the event, it either
instantiates the event itself (slightly slower, because this requires
reflection), OR, it asks the EventPool for an instance of the event.
- The EventPool keeps a reference to all known events based on the
event class signature. When an event is requested, the pool looks up the
list of events for the given event class, and either return a previously
instantiated event or if necessary, create a new one. This is somewhat
faster because, even though we are still using reflection for
instantiation, the instantiation only occurs a handful of times, after
which the events are simply reused. The downside of event pooling is
that it does require more resources to keep event instances around.
Generally, however, such overhead is minimal.
- Once the application gateway has an instance of the event, it
instantiates a DispatchQueue, indicates that it requires a response,
adds the initial event to the queue, and then passes it all to the
EventBroker for dispatching.
- The EventBroker uses the DispatcherFactory provided by the
application gateway to get an actual instance of an EventDispatcher
- The DispatcherFactory is responsible for instantiating the actual
instance of the EventDispatcher. Generally, it will return a new
instance each time, although optionally it may reuse the same instance
of the dispatcher. In this latter case, however, the dispatcher factory
should synchronize access to the dispatcher to ensure thread safety.
- When a DispatchQueue is passed in to be dispatched, the
EventDispatcher will iterate through the queue and dispatch all events.
As described above, in the case of the DefaultEventDispatcher, this is a
2 Phase Model 2 style dispatch in which non-Response events are
dispatched first, followed by all Response events (see above for
detailed description).
- Note that prior to actually dispatching an event in the queue, the
dispatcher will examine the event to see if it implements Polymorphic,
and if it does, it will dispatch it's parent events first (starting with
the highest event in the chain that implements Polymorphic all the way
down to the actual event itself).
- For every event in the queue, the dispatcher must determine which
listeners should be notified. This is determined by first looking to see
if the event is addressed to specific listener IDs. If not, the
dispatcher queries the event broker for a list of listener factories
that have expressed interest in the particular class.
- Once the dispatcher has a list of listener factories, it uses them
to obtain a reference to the actual listener (same rules apply as in the
dispatcher factory--return a new instance or synchronize).
- Once the dispatcher has a reference to the actual listeners, it
notifies them of the event.
- Event listeners generally do something in response to events. In
many cases Request events typically process business logic and then
redirect flow to the approriate view by adding a Response event to the
queue. They may however, simply log the event or update an underlying
data structure, or possibly even just ignore the event. If a listener
does something in response to an event, however, it should be marked as
handled.
- If no one handles the event and it implements Exceptional, then the
dispatcher appends the parent event to the queue. This will occur
recursively until someone handles the event or we reach the root, in
which case an UnhandledEventException will be thrown by the dispatch.
The ApplicationGateway generally catches this event and provides a
default response.
$Date: 2006-01-02 15:59:13 -0500 (Mon, 02 Jan 2006) $