Chapter 4. Event handling on the server side
- Table of Contents
- Overview
- Advantages
Overview
The idea of "Event driven approach" is not new at all. All the development for GUI systems, for example, use the approach because of its nature: a user performs an action --- such as a mouse click --- which is triggered in the system as an "event" having appropriate "event handler" responsible for executing procedure associated with the event (such as: close dialog box if users clicks on "Cancel" button).
JavaTM libraries applied nice idea of "events" and "event listeners", where the listeners are any components interested in receiving notification of specific event occurrence.
NOTE/ASSUMPTION: Lets consider WWW server, as an example of "a" server, in our further discussion.
If one think of a WWW application, it is also kind of GUI system. For example mail client can be a native X Windows client as well as WWW based one (see pine vs http://mail.yahoo.com). There is quite some technologies used to build WWW applications (see "Technology scan / WWW" section), but none of them (according to my knowledge) uses the idea of "event driven approach".
In the proposed server-side architecture, all requests on the server are represented by "Event" object. The instances of Event class encapsulates both the request and response context. Therefore, the Event instance is all one needs for satisfying request submitted to the server.
Figure 4.1: Class Diagram: Event Class
Such an approach abstracts from the first layer --- where the request is received. All components in other layers do not care where the event came from, their responsibility is to process the request and the "Event" instance gives them all they need to satisfy it. This unifies the design technique on the server because all the components are no longer dependent on transportation mechanism used to deliver the request.
Figure 4.2: Data Flow Diagram: Event flow
This figure shows how the event instance is created and processed: when server (HTTP in our case) receives a request it is his responsibility to create the event instance. The event instance is then passed to "EventDispatcher" for further delivery. "EventDispatcher" then looks up the appropriate listener interested in processing this event. Ones the listener is found, "EventDispatcher" passes him the event instance to process the event (satisfy the request).
Figure 4.3: Interaction Diagram: Event flow
This interaction diagram is added to bring more preciseness to the explanation. One can see that it is actually "AppServlet" who is creating the event instance. The HTTP server receives HTTP request and passes it to "AppServlet" through either of "doGet" or "doPost" methods (depending on what HTTP request method was used).
Figure 4.4: Class Diagram: All Event related components
Finally the overall class diagram shows all the entities (including their relationships) we discussed earlier. The "EventDispatcher" registers listeners interested in particular events using "addListener" method. It can lookup a listener using "lookupListener" method which utilizes the "listeners" relationship with "EventHandler" qualified by "event_id". The "event_id" (see "Event"'s attribute "id") is used to uniquely identify an event instance. If no listener is found during the lookup, then the default listener is applied (see "defListener" relationship).
There also are two "Custom*" entities. They show what components need to be customized during development and which are used as is. In our case "CustomAppServlet" is used for initializing all the components and their relationships ("initialize" method), which is done one time only during server's startup. And "CustomController" implements the custom procedure for processing the request ("handleEvent" method).