|
 |
 |
 |
 |
 |
 |
Barracuda Event Model - Event Delivery Flow |
 |
 |
 |
Event Delivery FlowIt 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.
|
|
 |
 |
 |
 |
 |
 |
For all the latest information on
Barracuda, please refer to http://barracudamvc.org
Questions, comments, feedback? Let
us know... |
|