$URL: svn+ssh://alci@svn.forge.objectweb.org/svnroot/barracudamvc/Barracuda2/tags/2.1/WEB-INF/src_docs/architecture/event/overview.html $ - $Revision: 158 $
Put all your content below this line

High Level Overview

This document attempts to provide a very high level overview of the Barracuda Event Model strategy by answering a lot of basic questions. We start with the obvious...

  1. What is an Event?
  2. What is a Listener?
  3. What is an Event Model?
  4. Uh, what's the purpose of Barracuda again?
  5. What is a Presentation Framework?
  6. What are the basic approaches to Content Creation?
  7. What is MVC?
  8. What is the Model 2 approach?
  9. What are some existing Presentation Frameworks?
  10. How do they deal with Events?
  11. Evaluating the Model 2 approach
  12. So why do we need an Event Model?
  13. Ok, so what does the Barracuda Model 2 approach look like?
  14. How about some sample apps?

Q: What is an Event?

An event is an indicator that something happened. In the web-app paradigm, events usually correspond with a client side action -- a user pressing a button or clicking a link. However, event's can also happen on the server -- perhaps a user session expires or some kind of persistent data changes. Finally events may trigger other events -- if one event causes data in a "model" to be changed, it may send out several events in response, one to log the action, one to let interested listeners know that the "model" has changed.

Q: What is a Listener?

A listener is anything that is interested in being notified when an event occurs. For instance, in the previous example, one listener might be interested in knowing when the model changes so that a data log can be updated. Another listener may be responsible for re-rendering a view. There may be multiple listeners for one event. Listeners generally handle events, and may in turn generate additional events.

Q: What is an Event Model?

An Event Model is the mechanism responsible for delivering Events to the Listeners that are interested in those events.

In the client server world, the event model is simpler in some ways because the client and server portions of the application are generally stated. The client can notify the server of an event and the server can notify the client. Typically, events generate as the result of a client action, and are handled immediately when the component which generated the event actually notifies all listeners in that event.

Things are a little different in the web-app paradigm. First of all, the client "view" is generally rendered in HTML or WML, which has no real capacity to perform event notification. The business logic that renders the view exists on a remote server, which in turn has no way of notifying the client if an event occurs on the server because of the nature of HTTP.  So, in very simple terms an event model for web-apps is a framework that resides on the server and is capable of translating an HTTP Request (about the only thing a client can generate) into an "Event" and then delivering that event to the appropriate listeners.

Q: Uh, what's the purpose of Barracuda again?

The purpose of Barracuda is NOT to create an Event Model. The purpose of Barracuda is to create a Presentation Framework.  We just see an Event model as a vital prerequisite to achieving that goal.

Q: What is a Presentation Framework?

A presentation framework is like any framework -- it's an abstraction designed to make it easier to work with the target domain. The JDBC framework, for instance, insulates developers from having to know which database they are communicating with. Object-relational mapping frameworks make it easier to interact with JDBC by mapping the data to an object hierarchy. These frameworks are aimed at the business and data layers of an application.

MVC frameworks like Swing are aimed squarely at the presentation layer, making it easier to interact with GUI components in a stated client-server environment. Interestingly, there's not much out there aimed at the presentation layer within a web-app environment. In this latter case, we're really talking about responding to an HTTP Request - how do we process the request, figure out what to do (and do it), and then return an HTTP response to the client which can be rendered in the client browser (whatever that may be HTML, WML, XML, etc).

So then, our goal is to make it easier for the developer to process requests and generate responses in an HTTP based web-app environment. A presentation framework, then, is designed to facilitate content creation.

Q: What are the basic approaches to Content Creation?

One of the reasons it is difficult to create content in a web-app environment is that we have a mixing of metaphors. Business logic is usually expressed in Java or some other high level language. The content itself is usually rendered in some kind of markup language (HTML, WML or XML) which potentially contains additional scripting language for the client. In short, rather than processing business rules and manipulating the client directly, we must generate one or more types of intermediate content which is in turn processed and rendered in the client.

There are 3 basic approaches to content creation.

  1. Servlets / CGI - Content is generated from a high-level language like Java, C, Perl, etc. This approach quickly becomes painful as we end up mingling markup and scripting within compilable code. The Servlets API provides one of the better high level interfaces to this approach.
     

  2. Template Engines - Template based approaches typically start on the other end of the spectrum, beginning with content in a static file (or "template") and then dynamically inserting data into the document by invoking business logic written in a high-level language. This usually results in a 3 types of media: code, content, and some flavor of scripting language embedded within the content.


    JSP is the defacto standard when it comes to this manner of generating content.  There are other template engines like TeaServlet, WebmacroFreemarker and Velocity.
     

  3. DOM Manipulation - A third approach goes one step further: content is stored and maintained separately, while business logic exists entirely in high-level code, manipulating the content via some kind of object model like DOM, SAX, or JDOM. I consider XMLC to provide the only real high level interface to this kind of approach.

Presentation frameworks generally try to improve on one of these basic approaches by further layers of abstraction to one or more of these basic approaches.  Most presentation framework development occurring today is primarily focused on the template based approach.  A majority of the existing frameworks have adopted some flavor of what Sun calls the "Model 2" approach.

Q: What is MVC?

MVC stands for Model-View-Controller. The MVC paradigm was introduced in Smalltalk as a method of architecting GUI's and has since been applied to various areas of application architecture including distributed applications.

An MVC architecture calls for a visual application to be broken up into three separate parts:

Sun thoroughly incorporated MVC into Swing (or at least a variation of it - see A Swing Architecture Overview) at a very granular level (i.e. individual components), and then forced developers to use it by defining the concepts in terms of interfaces. That said, Swing only formally specifies the Model portion of the pattern in terms of interfaces; the gui component itself comprises the view portion of the pattern, along with some of the controller aspects. As the Swing team themselves notes: it's really more of an M-VC adapation of the pattern, where the VC part is loosely defined and somewhat intermixed. When you write a Swing app, you add additional controller logic when you use event listeners to say "when this happens, do this [which may end up updating the model]". So, Swing components themselves implement MVC at a rather low level; there's nothing in the Swing framework that applies the MVC pattern to groups of components, or to application flow.

You can learn more about MVC as a distributed application architecture by reading the J2EE Blueprints, where they provide a diagram that looks something like this.

mvc.gif (43454 bytes)

 

Q: What is the Model 2 approach?

Model 2 is a term coined by Sun to describe a MVC (Model-View-Controller) architecture for web-apps (stateless) in which HTTP requests are passed from the client to a "Controller" Servlet, which updates the "Model" and then invokes the appropriate "View" renderer (JSP, Servlet, etc), which in turn renders the view from the updated model.

You can learn more about Sun's view of Model 2 by reading the JavaServer Pages Fundamentals Short Course, where they provide a diagram that looks something like this.

model2.gif (43454 bytes)

The key point to note here is that Model 2 is MVC in a completely different sense that Swing is. Model 2 is MVC focused at a much higher level; it's really more "MVCish" than "MVC" because it focuses on high-level application flow rather than low-level component interfaces. In other words, any web app can be Model 2; all it has to do is implement the "control" logic separately from the "view" logic. This is certainly a good practice to follow, but its also pretty nebulous. Swing is explicitly tied to MVC through well defined Java interfaces (Models, Listeners) that exist for all Swing components. In Model 2, we are talking about an MVC approach (i.e. we look at the general system flow and observe that it acts--loosely--like an MVC system). Swing's MVC is much more granular (and thereby much more flexible) than any of the Model 2 implementations.

Q: What are some existing Presentation Frameworks?

There are a number of presentation frameworks that provide various flavors of Sun's Model 2 paradigm. Struts (Jakarta) and Turbine (Apache) are probably the leading contenders with the most robust Model 2 implementations. Velocity and Expresso also offer Model 2 functionality.

Q: How do they deal with Events?

Surprisingly, most of them don't (although many of them are starting to consider adding some type of event model). Instead, they tend to focus on the HTTP request (which they might loosely consider an event), and build their systems around this conception. This results in the implicit coupling of "events" with HTTP -- for every request there will only be one response; consequently, for every "event" there can only be one "event handler".  While this is fine for simple Model 2 implementations, such an approach makes it virtually impossible to create a component model that supports hierarchy or MVC like you'd see in Swing (where one event can result in many additional events, each of which is potentially handled by multiple listeners.

If you are really interested in details, you might want to take a look at some simplified "logic flows" behind some of the common presentation frameworks.

The key point here is that any flow control framework can be broken down and viewed from an event based perspective. We should also observe that many tasks are common across presentation frameworks -- making sure a user is logged in, initializing session, etc.  If we code against events (instead of against a specific presentation framework) we greatly increase cohesion while decreasing coupling...we can modify (or event switch) presentation flow by adjusting the order in which events that are fired, minimizing changes in the event handlers themselves.

Q: Evaluating the Model 2 approach

The good side of Model 2 is that it's easy to use. That not-so-good side is that a Model 2 implementation generally locks you into a very cyclical flow. For instance, if you are using one of the approaches above and decide you want to significantly alter the program flow, you're basically stuck.  If your app fits into this type of general construct, then great, it'll work for you. But the typical level of granularity is centered on the page level. This means that if you have a complex page, then your Servlet "controller" and your template "view" suddenly explode in terms of complexity, which quickly overwhelms any value you got from the framework itself. The same criticisms apply to most other approaches as well.

This is because the Model 2 approach has no means to allow for decomposing the problem domain below the page level. In other words, in Swing when you have a complex app, you decompose the problem into a subset of individual components (each of which does one thing and does it well), and then you assemble these subcomponents back into more complex components, which may themselves be used individually or as part of still more complex components. This facilitates maintenance and reusability by managing the overall complexity through object composition.

Barracuda provides a nifty implementation that is especially suited for the web-app paradigm--allowing you to create reusable, hierarchical, web-app components just the way you would in client side GUI development (they can even be packaged in a single jar file!), and enabling a much more flexible, strongly-typed implementation of MVC by providing a much higher level of granularity.

Q: So why do we need an Event Model?

Ah, we return to the crux of the matter! As we hinted at above, the reason we need an event model is because it lays the groundwork for us to build virtually any presentation framework -- from Model 2 to true Component MVC -- and then we can migrate between presentation frameworks as application complexity increases. This is because the logic that drives all presentation approaches can be broken down into a simple set of events.

By decomposing a system into events and event handlers, we can make the system more modular and reusable -- many event handlers would be identical regardless of the presentation framework they are being used in. Thus it would be much easier to move between different presentation frameworks, or to incorporate multiple presentation frameworks within the same system. In addition, by making the event model fully pluggable, it would be easy to create an entirely new presentation framework simply by creating a custom "EventDispatcher" and plugging it into the system.

Q: Ok, so what does the Barracuda Model 2 approach look like?

The default implementation of the Barracuda event model provides a built in Model 2 approach to dispatching events.

At the heart of the Barracuda event model is the notion that there are two types of events: "Request" events and "Response" events.   This closely mirrors the HTTP paradigm with it's request-response protocol; in addition, this distinction nicely suits the Model 2 approach -- event handlers which respond to Request events act as Controllers, while those which service Response events are responsible for generating the Views.

In order to provide Model 2 flow control functionality, the Event Dispatcher takes a cyclical two phased approach to dispatching events. 

In the first phase, we start by dispatching all the non-Response events in the queue. In most cases, these will be events that extend from of HttpRequestEvent (since servlets form out primary gateway), but there is nothing in the framework that ties it exclusively to HTTP.  For instance, it's entirely conceivable that we could also create an SMTP gateway, allowing mail messages to be converted into events and dispatched through the event model. Any listeners which handle these Request events loosely correspond to controllers. They have the opportunity to react to the incoming request and then determine which view should be generated by adding the appropriate Response event to the queue.

In the second phase, we dispatch all the Response events. Listeners that handle these loosely correspond to views. If a response is required and there is no response event, we use a default response event (usually of type HttpResponseEvent).   Application flow is directed to the appropriate view controller, which then sends the response back to the client and notifies the dispatcher that the response has been handled.

We repeat both these phases until there are no more events to process. Thus we see that the basic dispatching mechanism takes an inherantly Model 2 centric approach to event delivery. Note that if we want to implement a single phase dispatch (ie. in the case of a Mail based gateway where responses are not necessarily required), all we have to do is tell the dispatch queue that we do not require a response.

Q: How about some sample apps?

Glad you asked. Check out Understanding the Barracuda Simple Login App for a full explanation.

 


Put all your content above this line

$Date: 2007-02-03 14:24:13 +0100 (sam, 03 fév 2007) $