This document tries to answer frequently asked
questions (FAQ) about the Barracuda Event Model.
- What is an event?
- Why do we even need events?
- Why do we need to support multiple listeners for an event?
- Will a client action ever generate more than one event?
- Can events be modified by Event Listeners?
- Why must events be associated with Java classes?
- What should event handlers be allowed to do?
- Why do all these EventHandler examples use inner classes?
- Can there be multiple EventBrokers? How many?
- How does the Barracuda approach differ from that seen in DiscRack?
Q1: What is an event?
A: 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?"
A: 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?
A: 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?
A: 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?
A: 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?
A: 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?
A: 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?
A: 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?
A: 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.
Q10: How does the Barracuda approach differ from that seen in
DiscRack?
A: We've provided a detailed answer to this question here on the Barracuda DiscRack page. |