Advantages

This approach brings several advantages:

• follows standard approach already well know on the client side. The advantage of a "standard" is that many people already have experience with it and therefore it is easy to learn and use (steeper learning curve).

  It also combines the "events" with "listeners" approach known in JavaTM. This makes to use really simple and straightforward.

• makes "Model View Controller" (MVC) design pattern applicable: speaking of using standard approaches, the MVC is very well known design pattern which helps to separate data management with the presentation strategies. It is probably useless to attempt to describe the usefulness of this approach. (see [2] for more about MVC).

  It is true that the "EventListener" interface (realized by class "Controller") represents only one of the three MVC components --- the Controller obviously --- but the other sections discussing DataInstances (Models) and XObjects (example of a View) should complete the MVC picture.

• component oriented: the proposed approach clearly defines components with highly specific responsibilities without overlap. What this means? There are components which are used as is --- instances of "Event", "EventDispatcher" (future planned "AppServlet") --- and components which need to be customized --- "AppServlet" and "Controller". They all have defined scope and responsibilities: event represents an event and nothing else, "EventDispatcher" dispatches the event, and so on.

  Compare this with typical way of development of a WWW application: one class, for example "MyStoreServlet", having responsibility of receiving the request, parsing and processing input parameters, figuring out what the requested operation is, contacting (in better case) other services for some additional processing required for executing the requested operation and producing the output (most likely mixing data, business logic and presentation mechanism all together). Obviously this is the worst scenario, but (according to my experience) quite widely and frequently used.

  This "one class" design completely prevents from having code reuse, unless one uses well known copy & paste technique. It is useless to mention how bad practice this is with a tendency to produce unextensible, buggy and hard to be maintained code.

  On the other hand the clear separation of scope and responsibilities is very suitable for defining a library of standard components which might be used in a visual development tool (RAD) and thus making development with such components easier, faster and better (less bugs in the code).

• abstraction of the server layer: finally the use of "Event" and "EventDispatcher" is a vehicle for transportation layer abstraction. Since "Event" is all one need to satisfy the request then it is completely irrelevant where or how the event is created. One can switch the transportation layer (from HTTP into RMI, for example) and all the other layers remain without any alterations. This enables either switching the transportation layer or using different ones at once.

  

  Figure 4.5: Object Diagram: Event flow with multiple transportation layers

  This figure illustrates using two transportation layers --- HTTP and RMI based --- both of them creates an instance of "Event" class and pass it to the "EventDispatcher" which passes the event to an "EventListener" interested in receiving this event.