Hypertext-based applications usually employ a front controller architecture, as described by the Model-View-Controller (MVC) paradigm [Kr88] which suggests the separation of user interface, application logic and control logic. However, many MVC implementations do not fully separate application and control logic. For example, in the Jakarta Struts framework, the action objects which implement the application logic also decide where to forward a request, and the controller just executes that forward command (Figure 1).

Figure 1: Coarse architecture of the Jakarta Struts framework (dialog control logic and flow spec shaded)

In this approach, the dialog control logic and dialog flow specification is distributed over all actions. This allows the actions to make only relatively isolated dialog flow decisions, and exacerbates the implementation of more complex dialog structures with higher-order constructs like nested dialog modules. Also, the hard-coded decentral implementation of the dialog control logic is relatively inflexible, almost unsuitable for reuse and hard to maintain. Finally, achieving presentation channel independence would require additional effort and possibly redundant work: Since the dialog flow depends on the presentation channel, while the application logic does not, their close coupling forbids the reuse of actions on multiple presentation channels.

In contrast, the Dialog Control Framework presented in this thesis features a very strict implementation of the MVC paradigm, completely separating not only the application logic and user interface, but also the dialog flow specification and control logic: Here, the controller decides where to forward requests by using a central dialog flow model to look up the receivers of events generated by dialog masks and actions (Figure 2).

Figure 2: Coarse architecture of the Dialog Control Framework (dialog control logic and flow spec shaded)

The Dialog Control Framework was implemented in the Java programming language. Channel servlets receive the requests coming in from clients on various presentation channels, extract the events encoded in them and send them to the central Dialog Controller. The Dialog Controller keeps track of the state of the users' nested dialog modules in compound stacks, and determines how to handle incoming events by looking them up in an object structure that models the application's dialog flow. Depending on the type of event and the user's current dialog state, the Dialog Controller may dispatch the request to an action, forward it to a dialog mask, or nest or terminate dialog modules by pushing them onto the compound stack or removing them again. To use this framework, the application developer only needs to provide a set of Java Server Pages representing the dialog masks, a set of action classes containing the application logic, and two XML documents containing the dialog flow specification and the mapping of elements to their implementations. These documents are machine-readable representations of dialog graph diagrams drawn in the Dialog Flow Notation, and parsed upon initialization of the framework to build the dialog flow model's object structure.

< 1. Motivation | 3. The Dialog Flow Notation >