Probe Architecture & Functionality
Paul Pazandak, Object Services & Consulting, Inc.
While probes are not the focus of the DASADA contract, they are the
unseen enablers. And while we need not glorify them, we need to respect
them, to worship them, and to understand the role they play -- without
them gauges are just news reporters without news. While there are
no really interesting research issues to solve here -- the probes require
yet another intermediary infrastructure -- the important goal becomes interoperability.
To begin with, then, we need a shared understanding of what a probe can
be, its functionality, and its operating environment. The purpose of this
exercise is simply to elaborate on the variables so that those interested
can think about the functional and architectural design choices, as well
as to seed a discussion so we don't have to deal with massive code changes
(or at least reduce the changes necessary) at integration time.
While not mandated, it is assumed because of the significant benefits
(and some mention of it), that a probe management infrastructure will be
used. While this may dictate at least a few of the design decisions (e.g.
such as the notion/use of probe stubs), several decisions remain
-- such as the division of responsibility between the management infrastructure
and the probes. Other decisions are more probe-centric, relating to control
of output generation, probe placement, and invocation.
[Note that at a given level in the tree if alternative choices are listed
they appear with bullets, if the level lists subcategories then no bullets
Probe Type - Two probe related types:
probe stubs and probes.
Self-contained Probe - The probe is
inserted directly, and multiple probes at one insertion point requires
each to be inserted independently of each other (one after another).
Insertion - When is the probe installed
Execution - Execution order is determined by relative placement
of probes in the flow of control
Static (e.g. compile time / load time)
Dynamic - If tools permit. It is possible to support dynamic
probe insertion and removal, though the degree to which this is possible
is constrained & dependent upon the programming language. In Java,
if the class being modified has no current instances or has not been loaded
yet, then runtime modification is straightforward. If class instances exist
then more complex memory-based tweaking techniques will be required (e.g.
as used by interactive debuggers like Visual Cafe). Dynamic insertion and
control are simplified greatly by the use of probe stubs.
Probe Stub - One or more self-contained
probes plug in to a probe stub. This facilitates runtime probe insertion
and removal. Only the probe stubs need to be inserted into the application
code. At runtime, one or more probes can be associated with a given stub
using a registration API. When the stub is invoked, it in turn invokes
each of the registered probes. This approach also enables a potential flow
of data between a set of registered probes. Issues regarding data flow
between probes and data flow between gauges is addressed in the Other
Issues section. How the stub determines what data (e.g. parameters,
local/global state) to pass to each probe, and how it passes the data must
also be addressed.
Management - some process needs to manage the list of 0+ active
(and inactive) probes associated with a stub
Execution (if 2+ probes) - When more than one probe is registered
with any given stub, execution order and data passing must be addressed
( different execution orders may produce different results ).
Local Management - Stub is aware of and manages the list of probes
that are registered with it (the stub has a management API which supports
probe registration). When invoked, it locally manages the execution of
the registered probes.
Management Facility - The stub calls out to another facility when
invoked and that facility in turn controls the execution of probes registered
with that stub
Stub Insertion - When is the probe stub installed
Independent / Parallel - the registered stubs are executed in parallel/independently
(this would appear to be acceptable as long as the probes do not modify
Dependent / Series - the registered stubs are executed in some defined
order (esp. necessary if the probes modify application/environmental data)
Probe Insertion - The stub facilities runtime insertion and removal.
Static (e.g. compile time / load time)
Dynamic - if tools permit
Lookup - How do probe data consumers
locate the probes they are interested in?
Advertisements - It is possible that
probes advertise themselves, e.g. in a lookup service. This assumes that
one can describe in an accurate way the probe, what it is monitoring, and
it's capabilities. It also requires a facility for ads.
Static Binding - Gauges and other consumers simply assume
that the probes they are interested in exist and are running
Dynamic Binding - Consumers need to lookup and potentially cause
the activation of the probes. Runtime binding is required.
Offline - Advertise for use & insertion
Runtime - Advertise that they are running and available
Probe Security Issues - Can anything
register to get data from a probe? What if the data is classified or needs
to be protected?
Probe Behavior - Probes may be designed
for several different types of tasks.
Data Examiners - The range of data
that the probe monitors. The events it generates may change based upon
the data content.
None - The probe simply executes & does not inspect any data
(e.g. used to report that a method has been called)
Parameters - The probe inspects parameters passed into the local
State - The probe inspects the global state of the application
Environment / External - The probe inspects environmental or other
application external data
Data Passers - The probe may pass data
available to it out to its consumers. The format of the data passed is
a separate, but related, issue.
Runtime configurable - What the probe inspects may be altered at
runtime (controlled either directly via the probe or via a management facility)
Data Manipulators - The probe or possibly
its consumers which it has sent the data to alter some subset of the data
(the types listed above). The probe needs to ensure that changes are propagated
Parameter - The probe passes out some subset of the parameters passed
in to the local method in which it is installed
State - The probe passes out some subset of the (global) state available
Environment / External - The probe passes out some subset of the
Runtime configurable - What is passed out by the probe is runtime
Runtime configurable - What is modified is runtime configurable
Probe Management - Overall control
of the probe, e.g. controlling whether it is active or inactive.
Self-managing - Regulating the probe
requires direct interaction with it for all management features (via a
probe management API)
Centrally-managed - Regulating a probe
requires interaction with a management facility.
Pull (polling) - The probe polls the facility for control information
Push - the facility updates the probe via the probe's management
Divided - Management is divided between
the probe and a management facility (non-overlapping)
Probe Execution / Placement
Control Flow - Probe is inserted into
program code & naturally executed based upon
the flow of control of the application. The probe will have access to local
state, method and class state, and any global state.
On Demand - Probe is not in any flow of control,
and is executed only on demand (when invoked). Exact placement will determine
the application state that these probes have access to (e.g. class and
Event Driven - Probe, like a gauge, registers
for events and is invoked when those events arise. Exact
placement will determine the application state that these probes have access
to (e.g. class and global state).
Placement (Specification) - How is
probe (stub) placement specified?
Descriptive Language - Some means to accurately describe this information
should be used (e.g. such as a probe placement specification language,
or extended ADL).
Manually - An alternative is to simply manually place them, but
this is a more limiting solution since they will need to be manually placed
in each successive version of the instrumented application.
Probe State - A probe may have a persistent
state it wants to maintain
Stored/Managed Locally (by Probe) -
The probe manages this state
Managed Externally - Another facility
maintains the state for the probe
Data - The probe generates data
/ events reporting information it has been programmed to generate. Options
include who the information is sent to, who sends it, how
it is sent, when it is sent is, and in what format.
APIs - Given the functionality mentioned
above it is certain that both the probes/probe stubs and the management
infrastructure will have APIs for configuration/control. Both programmatic
and GUI-based interfaces could exist, enabling code-based and direct user-based
control of these objects.
Listeners / Registrants - The list of recipients for broadcasts
from a probe
Timing - Controlling when the probes
output the data they have generated
Delivery - Who delivers the data to the consumers
Management Facility - A management facility manages the list of
Probe-managed - The probes manages the list
Transmission - If probes send events synchronously to their consumers
it can affect performance, and even stall an application if the consumers
are not available. Of course, this may not always be possible -- e.g..if
it is a probe stub sending data to a probe which modifies the data, then
it must be sent synchronously so the data can be updated before application
Management Facility - The probe sends the output to a management
facility which then sends it to all registered consumers
Probe-managed - The probe manages which consumers receive data (and
possibly their scopes of interest)
Format - The format of the data output
by the probe
Autonomous (every time they are invoked)
Controlled (e.g. off/on) - We can control data output by activating
or inactivating the probe
On/Off State Stored locally - The probe locally stores its activation
Calls out to management facility - Before any execution the probe
checks another facility for its activation state
On state-change only - The probe only reports differences (requires
that it has access to historical data, whether locally or remotely maintained)
Constraint-based - Output is determined based upon constraints,
either internally or externally dictated.
External - e.g. a management facility
Runtime Configurable - the constraints can be altered at runtime
by consumers, the probe itself or some other object
Pollable (pull) - The output is retrieved via polling of the probe
(suitable when the probe is not otherwise executed by natural flow of control)
Static - Preset
Adjustable (e.g. based upon specific event or consumer)
Externally formatted - output to another consumer which then formats
the data as required for its intended recipients (essentially this is the
same as static)
Probe Event/Data Correlation - How does one relate events generated
by different probes as belonging to the same unit of work / user / etc?
This is more complex when the system is multi-user and/or multi-threaded.
Homeless Probes - Not all probes may have an instrumented
home -- a foreign application into which they are embedded. For example,
environmental probes which provide information which is needed before an
application is started (e.g. "Is the car on a drivable surface? Does
the car have safe tires installed? Is there a bomb attached to the car?").
In such situations the probes may exist in specialized applications built
just for them.
Namespace / Probe placement specification language - To register
presupposes that gauges know how to describe the probes whose events they
are interested in, and how to request that specific probes be installed
Probes vs. Gauges - What is the difference between a probe (if stubs
are used) and a gauge? Gauges register for and consume XML-ized events
from probes. Do probes and probe stubs communicate with other probes using
XML-ized events, or higher level Java object representations? Some different
If probes never modify data, we could potentially view probe stubs as probes,
and then view probes as gauges.
Efficiency - Of course, if probes have to parse XML it will be slower
than passing java objects, especially if all probes/stubs are in the same
Pass by reference - If a probe needs to modify data, then pass by
value (e.g. XML events) complicates things a bit.
The views and conclusions contained in this document are those of the
authors and should not be interpreted as representing the official policies,
either expressed or implied, of the Defense Advanced Research Projects
Agency or the U.S. Government
© Copyright 2000 Object Services and Consulting, Inc. All Rights