active objects and events

title: Event-handling with active objects -- dealing with non-determinism in high-performance applications

log

5/2 (14.00) -- first version
5/2 (21.00) -- added fragments (see below)
6/2 (15.00) -- reworked fragments: abstract, 1, 2, 5, 6

restrictions

5-7 pages
www.ashland.edu/~iajwa/conferences/

time schedule

wednesday: 13 new draft
monday 18: final draft
22 submission

main argument

Event-handling with (passive) listener objects lead to problems in high-performance applications, which require non-blocking actions on the occurrence of events. Active objects provide a uniform approach to robust event-handling, both with respect to the registration and (de)activation of listener objects, as well as the (non-blocking) dispatching of events. As a benefit, from a software engineering perspective, our approach allows for a more modular approach to event-based systems and better insight in the flow of control between listeners and the application.

structure

Abstract (1/4)
1. Introduction (1/2)
2. Event-handling reconsidered (1/2)
3. Active objects in Java (1)
4. Example -- non-blocking GUI application (2)
5. Software engineering perspectives (1/2)
6. Conclusions (1/4)
References
Appendix: The active supervisor pattern

lenght indicated inbetween brackets

notes

1. general issues of event-handling, interactive applications, software engineering
2. a dissection of event-handling: non-determinism, event (dispatch) loop, (registration of) callback functions, listener objects, issues of blocking and multithreading
3. expose of active objects in sJava, synchronous calls and accept (keep this simple)
4. example: a comparison of approaches (based on the two pictures of the flow of control)
5. software engineering perspectives: handler registration, modularity and reusability of code, non-blocking (high-performance) applications, reverse engineering of flow of control
6. conclusions: added robustness
appendix: take from section X.

comments on previous version and explanation

non-determinism is an intrinsic aspect of event-driven systems
(typed) listener objects are a major improvement over callback functions (and these over switch-based event-loop programming)
one typical asset of OO languages is to make explicit switches obsolete, by the inheritance mechanism. (So not the goto but the switch is the point of reference).
issues in event-driven (interactive) applications are: registration of handlers (or listeners, or objects that deal with the event), event-dispatching (this is where the accept might come in), and event-handling itself (which must in some cases be non-blocking). A (software engineering) evaluation of the approach should consider all these aspects.
wrt the figures in the (word) document: where do the events come from?
A sentence like: In the program based on synchronous calls the listeners are instantiated automatically ... This is a bit hard to swallow, and (note that listeners are still involved) what is the actual mechanism and what are the tradeoffs?
Do not go into implementation details involving the kernel,except in a separate implementation section in 3 (sJava), and a brief remark in the conclusions.
Actually, on closer consideration, active objects are another weapon against the explicit switch and if-then-else branches that haunt complex applications ... (I'll try to bring that to the foreground in section 2.)

fragments (in construction)

abstract

The non-determinism inherent in event-driven systems, encompassing both networked applications and interactive applications, makes these applications difficult to develop and maintain, despite the availability of powerful libraries. One reason for this is the so-called inversion of control needed to dispatch events to listeners provided by the application. In this paper we will argue that event-handling with (passive) listener objects lead to problems in high-performance applications, which require non-blocking actions on the occurrence of events. Active objects provide a uniform approach to robust event-handling, both with respect to the registration and (de)activation of listener objects, as well as the (non-blocking) dispatching of events. We will illustrate our approach by discussing how to develop a graphical user interface for anapplication that must access a remote database. We will also indicate that as a benefit, from a software engineering perspective, our approach allows for a more modular approach to event-based systems and better insight in the flow of control between listeners and the application.

1 Introduction

The majority of applications fall within the class of event-driven systems, encompassing both networked applications and interactive applications with a graphical user interface. The non-determinism inherent in such systems makes these applications difficult to develop and maintain, despite the availability of powerful libraries. The problem is aggravated when multithreading is needed, for example to service multiple clients or preventing the application to block when accessing a remote resource.

In this paper we propose an approach to event-handling based on active object and synchronous rendez-vous. The structure of the paper is as follows. In section 2, we will reconsider the various way event-handling is approached, and we will indicate the problems that may occur with respect to modular code development and multithreading. In section 3, we will provide a brief description of sJava, an extension of Java that supports active objects and synchronous communication by rendez-vous. In section 4, we will proved an example that illustrates how synchronousn communication allows for a more direct approach to event-handling. In section 5, we will discuss the benefits of our approach from a software engineering perspective. And in section 6, we will draw some conclusions.

related work

Our approach is related to JCSP, a Java extension based on CSP (Concurrent Sequential Processes). However, JSP uses channels for communication by rendez-vous, whereas sJava uses synchronous method calls. Channels require explicit data coding Hence, our approach fits in more naturally with an object paradigm, where communication between objects is statically characterized by method interfaces.

2 Event-handling reconsidered

Event-driven computation underlies many applications, ranging from graphical user interfaces to systems for discrete event simulation and business process modeling. An important characteristic of event-driven computation is that control is relinquished to an environment that waits for events to occur. Handler function or handler objects are then invoked for an appropriate response.

When we reconsider how events may be handled, we can distinguish between:

event loops -- explicit dispatching on type of event
callback functions -- implicit (table-based) dispatching
listener objects -- callback on objects with hook methods

Event loops are typically the most primitive way to deal with events. Within the event loop an explicit dispatch on the type of the event is needed to invoke the appropriate application code.

Callback functions are a significant improvement over plain event loops. The dispatching is implicit, based on an association between a callback function and the type of event. Note that this approach is more modular and allows for extensions since new callback functions may be associated with the events.

Listener objects, as for example used in the Java AWT and Swing GUI libraries, may be regarded as an extension of callback functions, providing an object and a hook method that is invoked on the occurrence of an event. Since listener objects can maintain state inbetween (hook) method invocations, listener objects are strictly more powerful then callback functions that must rely on ad hoc mechanisms to take the history of event occurrences into account.

The Reactor pattern, described in [Schmidt95], provides a good example of an approach to handling a multitude of events. Operationally, the Reactor approach amounts to the following steps:

register handlers for particular event types
start event loop and dispatch incoming events
for each event, locate handler and invoke hook method
within handler, take action based on state and event information

Characteristic for both callback functions and listener objects is an inversion of control, that is the application code must await until it is invoked by the (event) dispatching mechanism. Although this induces an additional complexity with regard to the program structure, it is definitely an improvement over the explicit dispatching in basic event loops.

For example, when we implement a drawing application that enables us to draw objects on a screen, button press and move events are delegated to a handler (or listener) that decides based on the type of the event and its state what actions to take. Typically we may distinguish between two states, a state where no object is being drawn and a state where the object is being drawn, which is initiated with a button press. Dependent on the state the listener may ignore events. For example button moves are only meaningful when an object is being drawn.

Even in a simple listener object as the drawing object sketched above, an explicit branching on both object state and event type is necessary. This seems to be inherent in an approach based on passive listeners.

The Reactor pattern provides a solution for event-based systems in general, including networking and interactive applications. In networking applicatations it is evident that we may wish to introduce multithreading to serve multiple clients. However, also in interactive applications the need for multithreading may occur, for example when we must connect to a remote database. Since the network connections may be unreliable, we do not wish to block the entire application while waiting for an answer. Using passive listeners, multithreading must be introduced in an ad hoc fashion, by creating threads when reacting to an event.

In the following, we will propose an approach based on active objects that allows for multithreading in a more natural and robust way. Our approach which is based on an extension of Java, that is described in the next section, also reduces the need for explicit branching on state and event type, since the invocation of listeners does not need the inversion of control, due to the semantics of rendex-vous communication.

5. Software engineering perspectives

Non-determinism is an essential ingredient of event-based system. From a software engineering perspective the problem is not to suppress this non-determinism but to develop modular and robust code, that may easily be maintained and extended when the application requirements change.

Explicit switch statements are rightfully called a maintenance nightmare, and are consequently made obsolete by the inheritance mechanism that is characteristic of object-oriented technology, [Eliens2000]. As we have argued in section 2, listener objects may be regarded as another way to suppress explicit dispatching or switch statements. However, there is a price to pay, namely we need to accept an inversion of control. Although listeners allow for a modular approach, that is an indefinite number of listeners may be created and registered to deal with events, it is not always easy to get insight in the flow of control, that is to know what part of the program is being activated in response to an event. This problem is aggravated by the need to do explicit branching on the state of the listener object and the type of the event.

Our approach, described in the previous sections, actually undoes the inversion of control, due to the semantics of active objects and synchronous communication by rendez-vous. As a consequence, it becomes more easy to analyze the flow of control and the patterns of activity displayed by the program in response to events.

Conclusions

This paper has presented an approach to event-handling based on active objects and synchronous communication. This approach is particularly well suited to the development of interactive applications relying on graphical user interfaces and network communications. In the example, we have shown that our approach allows for a more direct way of intercepting events, which leads to a significant simplification of the code. Also the flow of control becomes more easy to understand, since the use of synchronous communication obviates the need for an inversion of control as is characteristic for GUI libraries using listener objects to deal with events.

references

Schmidt D.C. (1995) Experience using design patterns to develop reusable object-oriented communication software, CACM 38(10), pp 65-74
Eliëns A. (2000) Principles of Object-Oriented Software Development, Addison-Wesley

[_]

CV media links resources _

# @