MentorWizard Architecture
Previous  Top  Next

This section describes, in general terms, a technical architecture for a MentorWizard system. This architecture can be implemented with commercially available toolkits, including development environments that employ the Java, .NET or C++ languages. The following description is intended as a guide for system designers in general, regardless of the specific implementation technology employed. I use the word "architecture" here in the sense of a system design pattern, rather than a specification or blueprint.


What is it that drives a MentorWizard? Instead of the usual pages that a classic wizard manages in a fixed sequence, MentorWizard steps are loaded dynamically, as they are needed, from data stored outside the MentorWizard runtime executable. Step definitions can be stored in ordinary text files, in one or more databases, or retrieved over the Internet from web servers (much as a web browser acquires HTML pages over the Internet). In addition, MentorWizard steps are not restricted to a linear sequence but can be presented in any order that is appropriate for a task.

The major components in a MentorWizard system are shown in the following figure:

Mentor Wizard Structure  
There are three major components. The user interacts with a client runtime engine. Domain experts construct and modify applications with a step editor. Both the runtime engine and the step editor are supported by an enterprise server system that serves up steps and handles data retrieval and storage. The latter is readily available in the marketplace: examples include WebSphere (IBM), Sun ONE Application Server, WebLogic (BEA), .NET (Microsoft) and Tomcat (Apache). These server systems support MentorWizard applications the same way they support browser-based applications. The difference is that web application pages are defined in HTML files, while MentorWizard applications use step definition files in XML format.

The runtime engine runs on a client computer with support from the local operating system (for example Windows, Linux, Unix, or Macintosh). The MentorWizard runtime engine connects to the Internet just like a web browser. The enterprise server is also connected to the Internet so that the MentorWizard client can retrieve step definitions from the server exactly the same way a web browser retrieves web pages. The step definitions reside in text records, one per step, and may be stored in files, in a database, or they may be generated dynamically on demand.

MentorWizard step definitions may be located on the client computer and/or on one or more web servers accessed by the MentorWizard runtime engine via the Internet. When a step definition is present on both the client and server, the runtime engine checks the version of each copy. If the network copy is newer, it replaces the local copy. However, if the local step definition is up to date, it is immediately shown to the user. As is true for web pages, if a server-resident step is modified, all users will see the modified step the next time they access the step. In this way, applications can be changed on the fly without user interruptions or re-installation of executable files.

The enterprise server builds steps on demand when they display dynamic data such as information stored in an enterprise database. Dynamic steps are built with the same tools and in the same way as dynamic web pages. For example, dynamic steps can be built with technologies such as JSP, servlets, or ASP.NET.

The following sections describe various aspects of the MentorWizard architecture. The first presents the ways in which a MentorWizard system can be partitioned into tiers. Then the system is described from the point of view of an end user. Finally, the mechanisms used to deliver the user experience are discussed. Finally, MentorWizard is described with UML diagrams.

Tier Architecture

MentorWizard delivers an application via a user interface on a client system. Applications delivered via a browser use a similar architecture. However, a browser-based application's web server delivers pages coded with HTML to a browser whereas a MentorWizard application's web server delivers steps coded with XML to the MentorWizard runtime engine.

The MentorWizard concepts can be realized in a variety of tier configurations. The MentorWizard runtime engine always delivers the user interface. However, the MentorWizard steps and the data manipulated by an application may be distributed across servers organized into tiers. For very small applications, all MentorWizard components may reside on the client system. Normally, however, the client acquires steps from the server via the Internet and a server provides access to the application's data. The server may process dynamic steps locally, for example with JSP technology. These in turn may access additional tiers such as database servers, using ODBC, JDBC, EJB, or similar technologies.

The following diagram suggests a number of possible tier architectures for applications implemented with MentorWizard:

Mentor Wizard Architecture

Application State

For an application that is delivered to the user via a web browser, all application state is managed on a server. MentorWizard, however, holds object state on the client in the Task Cache (described below). Additional application state may be maintained on the enterprise server (all requests to the server include the client's identifier so cookies are not needed). The application state maintained on the MentorWizard client is a combination of user interface state (the step stack, the undo/redo stacks, and the user history) plus temporary application-specific data (the application parameters). Since all of this state data is held in the Task Cache, automatic backups can be used to enhance the client system's robustness.