cool stuff
/src_docs/architecture/event/sample_event_flows.html, v125

Sample Event Flows

This document just describes the basic program flow for various presentation frameworks.

  1. Barracuda
  2. Turbine
  3. Struts

Barracuda

It might be helpful to provide a basic summary of how events are delivered.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. The EventBroker uses the DispatcherFactory provided by the application gateway to get an actual instance of an EventDispatcher
  7. 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.
  8. 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).
  9. 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).
  10. 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.
  11. 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). 
  12. Once the dispatcher has a reference to the actual listeners, it notifies them of the event.
  13. 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.
  14. 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.

Turbine

Suppose we have a form which whose action is mapped to a URL that looks something like this http://<server>/servlet/Turbine/template/AddUser.wm/action/NewUser and whose form buttons might be named doSubmit, doCancel, etc. When the user presses a button, the following sequence would occur.

Struts

Struts initially loads an ActionServlet which (as described in the javadoc) has the following responsibilities:

For the example application all urls ending with a ".do" extension are mapped to this Action Servlet. At initialization time, the action servlet reads in a action.xml file which provides additional routing information that is used during request processing. The basic application flow runs something like this:

If you'd like to document a framework not listed here, we'd love to hear about it.

 


Put all your content above this line

Last Modified: 2006-01-02 15:59:13 -0500 (Mon, 02 Jan 2006)