$URL: svn+ssh://christianc@svn.forge.objectweb.org/svnroot/barracudamvc/Barracuda2/trunk/WEB-INF/src_docs/architecture/comp/overview.html $ - $Revision: 125 $

Event Model FAQ

This document tries to answer frequently asked questions (FAQ) about the Barracuda Event Model.

  1. What is an event?
  2. Why do we even need events?
  3. Why do we need to support multiple listeners for an event?
  4. Will a client action ever generate more than one event?
  5. Can events be modified by Event Listeners?
  6. Why must events be associated with Java classes?
  7. What should event handlers be allowed to do?
  8. Why do all these EventHandler examples use inner classes?
  9. Can there be multiple EventBrokers? How many?
  10. How does the Barracuda approach differ from that seen in DiscRack?

Q1: What is an event?

An event is a, well...an event! It means something happened. In the web-app paradigm, events usually correspond with a client side action -- a user pressing a button or clicking a link. Any time an event is sent from the client to be handled by the server, the event is encapsulated in the form of a URL. Events can also be generated and handled entirely on the server side, in which case they are handled by event listeners that have expressed an interest in the particular event. Finally, some events can be generated and handled entirely on the client side. In most cases this would be done through a scripting language like Javascript.

In all of these cases, an event is an action whose occurrence will result in event listeners being notified. Events delivered through HTTP will always require an HTTP response as well.

Q2: Why do we even need events? After all, it takes additional overhead to convert a request into an event and then dispatch it to listeners. Why not just route the actual HTTP request?

The problem with HTTP requests is that many parties may be interested in a particular request, while only one of them can actually respond to that request. Consequently, without an event model whoever receives the request must have initimate knowledge of ALL interested listeners to decide who actually gets to do something with, to, or as a result of the request. This would result in a very tightly coupled system.

A true event model provides much greater flexibility because it allows interested parties to be loosely coupled. None of the event listeners needs to have any knowledge of the others existance. They simply know that if an event happens they will be notified so they can do their particular task. This greatly increases reusability. In addition, an event model allows listeners to fire additional events, which can be handled by other listeners. There is no way to do this if the request is considered the event. Furthermore, virtually all OO languages recognize the benefits of a true event model for complex development. Finally, it should be noted that the J2EE Blueprint strongly promotes this basic model of turning requests into events. Presentation frameworks that fail to adhere to this proposition may have a difficult time intergrating with J2EE.

While we could certainly create a presentation layer that did not have a true event model, it is almost equally certain that it would not be up to the task of creating a more complex component model down the road.

If you'd like a more in-depth answer to this question, refer to the Reasons for Events As Objects document.

Q3: Why do we need to support multiple listeners for an event?

Well, in most cases we won't. However, past experience with event models in stated client-server types systems indicates that there will be cases where this type of thing is not only useful but essential. Basically, the idea behind an event is that "something happened". Typically, you have a number of things you need to do in response to that "something". To maximize reusability, you don't want to code all that logic in one place, you want to break it up into pieces, and allow each piece of code to "do one thing and do it well".

As an example, lets say I have a 10 different servlets in an application, each of which have different logic to render error pages. Each one of these servlets could handle an "Error Event" in different ways. Now let's say I want to add a new event listener, which logs all "Error Events" in the app. I should not have to go and modify each of the 10 servlets that deal with error handling. I should be able to add a new listener and create the code in one place. This is what loose coupling is all about. 

Basically, we feel support for multiple listeners is essential to facilitate reuse. Also, if you look at Swing, it takes the same type of approach. Components that generate events always support multiple listeners.

Q4: Will a client action ever generate more than one event?

No. A client action (or gesture), will always result in one HTTP request, which directly corresponds with one HttpRequestEvent (and thus at least one HTTPResponseEvent and ultimately exactly one HTTP response). That said, there may be multiple listeners on the server who need to be notified that this event occured. In addition, some of these listeners may fire additional Server-to-server events. Nevertheless there is still only one root event, and there will always be a one-to-one correspondance between a Client-to-server event and the HTTP request which carries it.

Q5: Can events be modified by Event Listeners?

No, but event listeners should be able to dispatch additional events in response to the original event.

Q6: Why must events be associated with Java classes? Why not just use parameters or path info?

The advantage of using classes is that we can invoke methods based on interface name, without using reflection. If we were to try to map parameters or path info to "method" event handlers, we would have to either manually build case statements or else invoke the methods using reflection. Neither of these options is particularly desirable.

Q7: What should event handlers be allowed to do? Should event handlers be limited to updating the MVC model? Or can they also render the view? 

I think a case can be made for both. There will be some scenarios where it make sense to have the event handler generate a response and send it back to the client. A good example of this might be an error page. There are other cases which might involve more complex views. In situations like these, it probably makes sense to have the handlers simply update the model and then rely on a default handler to render the screen for the client. Consequently, we should support both cases.

The real question here is, "Should the Event model have any knowledge of the MVC model?"  If you look at Swing, there is a clean separation between these two layers. Most web-app implementations of MVC, however, do not really even have an event model -- it ends up being part of the MVC layer because it's assumed that "events" only come as HTTP requests from actions initiated on the client. Consequently, many Model 2 implementations (especially in template engines) don't give you the option of rendering -- servlets (acting as event handlers) update the "Model" and the template engines actually render the "View" by parsing the scripting language embedded in the template (which just pulls data out of the model).

What we are saying here is that there should really be a distinct Event layer that has no a-priori knowledge of the MVC layer. This will allow us to handle a greater number of developer scenarios. In some cases (ie. w/in MVC) event handlers may just want to update the underlying data model. In other cases, however, it may be better to just generate the HTTP response directly from the handler. We think there may be cases where developers want to do both, so we think a framework should allow for both.

Q8: Why do all these EventHandler examples use inner classes?

You are never forced to use inner classes to handle events. This is for convenience sake, much like in Swing. One advantage is it makes it possible to keep local event handling code in the same physical proximity as the rest of the code for a page or screen. More importantly, by making event handlers real classes (rather than just methods), we force them to be first class Java objects -- we can then require them to conform to known interfaces, which means we do not need to invoke them through introspection, and allows us to make the Event dispatching implementations much more robust.

Q9: Can there be multiple EventBrokers? How many?

Yes, as many as you need. In stated apps, there is often one master event queue. This forms a potential bottleneck in web-apps, since you could have thousands of requests being generated simultanteously. We do not wish to force servlets to share an EventBroker. Instead, we support the notion of allowing any number of EventBrokers, while at the same time using a factory pattern to minimize overhead. Generally, it will be a good idea to maintain one instance of an event broker per instance of servlet.

 


$Date: 2006-01-02 15:59:13 -0500 (Mon, 02 Jan 2006) $