Contents:
- DOVE Objectives
- The DOVE Software Architecture
- A DOVE Example
- Remora: A Prototype Implementation of DOVE
- DOVE Deliverables
- DOVE Technologies
- Related Work
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:
- Create Web-based telecom management application tools using Java
component technology (such as
JavaBeans) that can automatically generate visualizations of
system- and application-level information in a network
environment.
- Develop a real-time Agent framework based on TAO (The ACE ORB) to
monitor and control applications and network elements in large-scale,
hierarchical networks with minimal effort by developers and
administrators.
- Develop a platform-independent, persistent, and hierarchical
Management Information Base (MIB) that allows end-user applications
and management applications to store and retrieve name-value bindings
efficiently in a distributed environment. Using components from ACE, applications
can store attributes in the DOVE MIB, which makes them automatically
eligible for visualization.
The DOVE architecture is shown in Figure 1:
Figure 1: The DOVE software architecture.
DOVE consists of five components:
- The DOVE application
- The MIB
- The DOVE Browser
- The Visualization Component
- The DOVE agent
The role of each component in DOVE is described below:
- The DOVE application
publishes state variables it wants monitored or configured by the Visualization Component. Using pre-defined
and/or automatically generated APIs, the application stores and
retrieves values in the DOVE MIB. The high
degree of dynamism supported by DOVE is particularly suitable for
applications that (1) cannot provide a user interface, (2) must be
restarted or recompiled to change their configuration, or (3) for
which logging is too costly.
- The MIB is the logical
repository of information in DOVE. MIBs are separate entities from
DOVE agents, which allows the MIB to be persistent and the application
to write to the MIB, even when an agent is not currently
running. Although the MIB is a logical repository, load or store
operations on the MIB will cost no more than a read or write to shared
memory since the application and MIB typically share the same
endsystem.
Figure 2: Attaching the Visualization Component to Graphical
Monitors
- The DOVE browser is Java
applet or stand-alone application that discovers, through Agents, the
applications on a network offering DOVE services. The browser is also
a visualization builder, allowing end-users to bind graphical or data
gathering components to data published by the DOVE application. The
browser can then package the resulting tool in its own applet or
application. Likewise, the browser can simply save it to a file for
later use. This "build once, use frequently" approach is provided by
JavaBeans.
In complex system management environments, such as a central office
network operations center, there may be multiple DOVE browsers that
interact with multiple Agents. It is the responsibility of the DOVE
framework to provide a transparent and scalable infrastructure for
large-scale systems management.
- The Visualization
Component is the conduit through which information from a
DOVE application reaches the user and configuration information from
the user reaches the application. Each Visualization Component is a
Java Bean, which is registered for updates from the Agent or
Application Proxy. The Visualization Component makes new information
public as it arrives and fires events related to those changes.
Through the DOVE browser, the user can connect components to these
properties and events to monitor and change the state of the
application, a concept illustrated in Figure 2. For example, suppose
an Image Server publishes the outgoing number of megabytes and updates
the value every time a client finishes downloading an image. A
network management application may want to use the Visualization
Component to chart the average outgoing throughput. To achieve this
functionality, the Visualization Component would have a property
called "outgoing Megabytes," the point data, timestamps indicating the
start and finish time of the connection, and an event called "outgoing
Megabytes updated." The user would simply connect an averaging graph
to the "outgoing throughput" property, which would cause the graph to
invisibly attach itself to the timestamp properties and update event,
and when the update event occurred, the graph would update the current
average throughput (in Megabytes/sec) using the new point datum and
time elapsed, and plot the next point on the graph.
The standard bridge from JavaBeans to ActiveX makes it possible to
exchange information between JavaBeans and COM objects. Thus, it is
possible to integrate DOVE with Excel applications running in the
Microsoft Office suite. In addition, efforts are underway to
integrate JavaBeans with CORBA.
- The DOVE agent runs as a
Singleton process on an endsystem containing a DOVE MIB. The agent
performs the following tasks:
- Service advertisement -- The Agent consults a list in the
DOVE MIB to inform DOVE browsers of the DOVE-enabled applications and
services currently available on the local endsystem.
- Change notifications -- The Agent is responsible for
notifying the DOVE browsers when applications they have registered to
monitor change state. Since the DOVE Agent is design to run on a
real-time ORB,
it will be possible to monitor real-time applications and network
elements.
- Data reduction and correlation of events -- In a
large-scale networks, it may be necessary to support a hierarchy of
intercommunicating Agents that exchange events asynchronously
(e.g., to transmit trap notifications and other forms of
alarms). To achieve scalability, DOVE Agents will employ flexible,
high-performance event filtering and
event correlation mechanisms.
Administrators and management applications can strategically install
filters within agents to route events of interest to remote nodes
(such as DOVE browsers or other Agents). Thus, multiple agents and
filters can be composed and/or arranged hierarchically to reduce
unnecessary network traffic and enhance the scalability of event
notification in a large-scale network. In addition, Agents will
support correlation mechanisms that can be used to perform root-cause
analysis based on a series of events from other Agents.
- Visualization configuration -- The Agent configures the
Visualization Component to receive type information about an
application. A DOVE agent can configure a Visualization Component
with an application two ways:
- In the interpreted approach, one of the two sides of the
connection -- either the Visualization Component or the
Agent/Application Proxy side -- knows what kind of information the
application publishes, while the other side doesn't. Therefore, one
side must explain to the other the information it has or wants.
- In the compiled approach, both sides know exactly the
information they want or have, and can communicate explicitly in terms
of those types. The tradeoff is between having a generic framework in
which the application developer writes little or no DOVE code, or
allowing the application developer to add application specific
functionality.
For simple data types the interpreted approach works relatively well.
The agent can examine the MIB, specify to the Visualization Component
what types of information it finds, and proceed to deliver it.
However, the agent must know about all possible kinds of data types
stored in the MIB and be able to convert from MIB format to the
format expected by the Visualization Component.
If the application wants to store something beyond simple primitive
types or arrays of primitives (e.g., an array of structures),
the generic framework breaks since the agent and Visualization
Component only communicate simple types. There are several solutions:
- One solution is to have the Visualization Component describe the
type of information it wants from the agent (for example, using a COM
VARIANT type or a CORBA any type), and know
how to convert the result into something useful.
- Another solution is to have an Application Proxy (which
knows exactly how and what the application stores) deliver information
to the Visualization Component. The generic Visualization Component
would then have to discover at run-time the information offered by the
Application Proxy (for example, through COM Automation or the CORBA
DII). In this case, the Agent would negotiate the connection between
the Visualization Component and the Application Proxy, and the
conversion from MIB types to displayable types occurs on the
application side of the connection.
In these last two scenarios, either the Visualization Component or the
Application Proxy must know application-specific information. The
design challenge is to minimize the amount of code the application
developer must write to configure these pieces. In one approach, a
compiler automatically generates this code from a specification of the
data that the application would write to and read from the MIB.
In the compiled version both sides know exactly how to communicate
with each other. Therefore, some type of automatic code generation is
necessary to prevent the application developer from writing too much
DOVE related code. The compiled version greatly reduces the run-time
responsibilities of the Visualization Component and Application Proxy.
- The optional Application Proxy extends the agent
with application-specific functionality. An application proxy is
necessary when the application developer wants the agent and
Visualization Component to interact in ways that the generic DOVE
framework cannot provide. For example, the application developer may
want to send special messages to the Visualization Component when the
application sets a flag in the MIB.
The best way to understand the power of DOVE is through an example.
In this example, an Image Server publishes the following attributes:
- The twenty most frequently accessed images;
- The number of threads currently running;
- A monitor and log of client accesses from which the administrator determin
es
times of maximum usage;
- The average incoming and outgoing throughput.
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:
- The policies by which the Component obtains each quantity -- the
agent may periodically update the Component, update when the quantity
changes, or update only on user request (polling);
- The policies by which the Agent obtains changed data -- the agent
may periodically pull values from the component, or the Visualization
Component may push data to the Agent when values change.
- The combination of statistics -- it may make sense to compute the
average of a statistic over time, or the average difference of two
statistics over time;
- Help files -- the application, in its specification, may
include explanation of the values it stores in the MIB, a description
of the application itself, or tips on how to best make sense of the
data;
- Images -- to ensure all visualizations created from their
application look especially spiffy, developers may want to stash a
default background image or company logo within the information
downloaded into the Visualization Component.
- A MIB browser -- a hierarchical browser of the information
stored by that application in its local MIB.
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 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.
DOVE is a hybrid of three types of applications:
- 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);
- Application steering -- online monitoring and control of
performance-critical applications;
- 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 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.
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.
Back to Douglas
C. Schmidt's home page.
