The Distributed Object Visualization Environment

A Web-based network management and visualization system using Java and Real-time CORBA

Douglas C. Schmidt
Assistant Professor
Department of Computer Science
Washington University
St. Louis, Missouri 63130-4899
TEL: (314) 935-4215
FAX: (314) 935-7302


  1. DOVE Objectives
  2. The DOVE Software Architecture
  3. A DOVE Example
  4. Remora: A Prototype Implementation of DOVE
  5. DOVE Deliverables
  6. DOVE Technologies
  7. Related Work

DOVE Objectives

The goal of the Distributed Object Visualization Environment (DOVE) is to monitor and control the state of applications distributed throughout a network. The DOVE project has the following objectives:

The DOVE Software Architecture

The DOVE architecture is shown in Figure 1:

Figure 1: The DOVE software architecture.

DOVE consists of five components:

  1. The DOVE application
  2. The MIB
  3. The DOVE Browser
  4. The Visualization Component
  5. The DOVE agent

The role of each component in DOVE is described below:

A DOVE Example

The best way to understand the power of DOVE is through an example. In this example, an Image Server publishes the following attributes:

In addition, the Image Server can be configured with attributes that set the maximum number of threads and the size of its memory cache.

Since these quantities use only simple data types, we can use the interpreted model of DOVE, where the Visualization Component and agent communicate directly. The application uses a general interface to the MIB. The application developer uses the MIB APIs to read the max threads and cache size, and write connection information. On startup, the application announces itself by appending its name and the location of a library containing the application proxy to a list in the MIB. It's from this list the agent locates applications running on the local endsystem.

Figure 3: The DOVE Protocol for Periodic Updates

The DOVE agent negotiates the exchange of information between a DOVE browser and a DOVE application. The interaction diagrams in Figures 3 and 4 describe two possible exchange policies. The DOVE browser locates endsystems that run DOVE agents (i.e., DOVE enabled endsystems), and retrieves from them a list of applications available for visualization and control.

Once the network manager selects the image server through the browser, the browser instantiates a generic Visualization Component. This component registers itself with the agent on which the server resides. Note: In the compiled model, where the Visualization Component may have application specific functionality as well, the browser may need to download a Java Archive (JAR) file containing the Visualization Component subclass.

The Visualization Component is an invisible lightweight component (i.e., a Java Bean) whose properties are known by introspection. It is configurable by the DOVE browser. Once registered, the Visualization Component receives callbacks from the agent with the applications most recent information in the MIB.

End-users can select the policy that determines when the agent invokes callback methods on the Visualization Component for a certain piece of new information. In the periodic model of Figure 3, the agent pulls data from the MIB every time a timer of a chosen frequency expires. In the callback-on-change model of Figure 4, the MIB notifies the Agent when data changes, and the Agent delivers the new data to the Visualization Component. The Visualization Component may also pull information from the Agent. Likewise, for data read by the Application, the Agent could pull information from the Visualization Component periodically or have the Visualization Component push data to it when the data change.

Figure 4: The DOVE Protocol for Updates When Data Change

The Visualization Component is the locus of interaction between the client and the agent or application proxy with whom it's registered. It contains a set of properties and events common to all Visualization components and properties and events specific to the application. The DOVE browser assembles around the Visualization Component a default graphical visualization, assigning a monitor to each piece of read-only information and a control to each writable quantity. In addition, it also attaches a configuration component from which the user can adjust and view the common features of Visualization Components such as:

Figure 5: A Sample DOVE View

The user may then redetermine to what other components the data from the visualization component will go, choosing from a library of prewritten visualization components (e.g., strip charts, pie charts, text charts, gauges, dials, slide bars, etc...), like the example in Figure 5, or with bridges to external components.

For example, a user may wish to visualize data "online" through a series of strip charts, and "offline" by simultaneous piping of data to a Microsoft Excel spreadsheet for subsequent transmutation into a visually intuitive 3D graph.

After constructing the visualization, the user can make the finished product persistent in two ways by having the DOVE browser either: 1) serialize the components to a file, so it can be reloaded ; or 2) construct an applet or standalone application from the components, which will reconnect to the application proxy at startup.

Remora: A Prototype Implementation of DOVE

Remora is prototype implementation of the interpreted version of DOVE. It is named after the creature who enjoys a symbiotic relationship with sharks (such as JAWS), eating the detritus off of the cartilaginous carnivores.

A Remora application uses Remora_Import and Remora_Export variables to read integers from and write integers to a MIB. When the application reads the value from a Remora_Import variable, it retrieves the value from the MIB, and when it writes to a Remora_Export variable, it stores the value in the MIB. The opaque variables hide the details of MIB storage from the application.

In this implementation, the MIB is not persistent; it exists as a mapping in the agent's memory. In addition, the agent does not distinguish between statistics published by different applications. The Remora client registers with the agent for updates either periodically or when values in the MIB change. The Remora GUI provides facilities for choosing one of the two policies for each of the statistics, and adjusting the frequency of the periodic updates. Upon registration, the agent delivers to the client the names and values of the quantities being exported and imported by the application.

Figure 6: Remora Screen Shot

In the upper lefthand corner of the GUI, shown in Figure 6, the user can browse through statistics published by the application. Clicking on a label will show or hide a strip chart that plots the values as they arrive at the client. The user may also create new charts of the average of statistic over time, or the average sum, product, difference, or quotient of two statistics over time. The client displays charts in the lower half of the client.

In the upper righthand corner of the Remora client GUI, the user can adjust the values imported by an application by manipulating the slide bars. If there is a relationship between the controllable variables and the statistics, the user can observe the changes in the strip charts.

Related Work

DOVE is a hybrid of three types of applications:
  1. Network management tools -- borrowed from SNMP is the the managed d evice-MIB-agent architecture, the idea of discovering services on the network, and monitoring and configuring devices through data in a logical store (the MIB);

  2. Application steering -- online monitoring and control of performance-critical applications;

  3. Application visualization -- meaningful graphical depictions of application state.

The remainder of this section discusses related work.


NetPrism is an SNMP network management tool written in Java by Fujitisu Software Corporation. The Network Manager Server, upon startup, discovers SNMP manageable devices and reports its findings to any Network Manager clients who have two options for managing these devices: they may either use the built-in MIB browser, or vendor supplied Element Managers, which have interactive bitmap images of the devices being managed and logic for rule-based, automatic fault-management. Vendors use the separately distributed Software Development Kit to generate Element Managers for their devices. Using the SNMP protocol, users can log and graph the results of polling a device, and set values in a device's MIB.

Progress: A Toolkit for Interactive Application Steering

Progress is a toolkit for online remote monitoring and steering of parallel applications. The parallel application creates "objects" encapsulating data to be monitored and steered, and registers them with the progress server, which runs in the same address space as the application but in a different thread of control. Prompted by a user at a potentially remote graphical client, the server can perform asynchronous "probes" to read and write the state of the application objects, and, similarly, the application may synchronously "sense" the state of objects stored in the server registry, or "actuate" a synchronization between an object's state in the registry and its own state. These two synchronous operations execute from function calls in the application instrumented by the developer, through which the application and progress server exchange information in shared memory buffers. Through the client user interface, the user may also issue a "synch" command, pausing the execution of the application, or execute specialized function objects written by the application developer. Synchronous changes in the application state through "sense" and "actuate" functions only occur on objects of interest to the client, the other calls on irrelevant objects are disabled.

ParaGraph a tool for visualizing performance of parallel programs

From tracefiles generated from executions of message-passing parallel programs, ParaGraph constructs detailed and dynamic graphical animations of their behavior, and graphical summaries of their performance. ParaGraph reenacts a program's execution using algorithm animation, providing twenty-five different views to represent the underlying execution trace data, which a program generates through minor instrumentation with the Portable Instrumented Communication Library (PICL). PICL takes pains to minimize perturbation in the program being monitored, and to provide consistent and meaningful timestamps on tracefile entries. ParaGraph categorizes the displays as Utilization Displays -- depicting processor utilization, Communication Displays -- depicting interprocess communication, Task Displays -- depicting the portion of the user's parallel program that is executing at any given time, and Other -- such as clock readings and processor status.

JIDM (Joint Inter-Domain Management)

Network Management Info

Dove Status

Back to Douglas C. Schmidt's home page.