Probe Architecture & Functionality

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 are used.]
 

• 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
• 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.
Execution - Execution order is determined by relative placement of probes in the flow of control
• 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
• 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
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 ).
• Independent / Parallel - the registered stubs are executed in parallel/independently (this would appear to be acceptable as long as the probes do not modify application/environmental data)
• Dependent / Series - the registered stubs are executed in some defined order (esp. necessary if the probes modify application/environmental data)
Stub Insertion - When is the probe stub installed
• Static (e.g. compile time / load time)
• Dynamic - if tools permit
Probe Insertion - The stub facilities runtime insertion and removal.
• Probe Existence
Lookup - How do probe data consumers locate the probes they are interested in?
• 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.
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.
• 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 (method)
• State - The probe inspects the global state of the application
• Environment / External - The probe inspects environmental or other application external data
• Runtime configurable - What the probe inspects may be altered at runtime (controlled either directly via the probe or via a management facility)
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.
• 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 to it
• Environment / External - The probe passes out some subset of the environment
• Runtime configurable - What is passed out by the probe is runtime configurable
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 correctly
• 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 API
• Divided - Management is divided between the probe and a management facility (non-overlapping)
• Probe Execution / Placement
Execution -
• 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 global state).
• 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
• Probe Output
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.
Listeners / Registrants - The list of recipients for broadcasts from a probe
• Management Facility - A management facility manages the list of registered listeners
• Probe-managed - The probes manages the list
Delivery - Who delivers the data to the consumers
• 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)
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 execution continues.
• synchronous
• asynchronous
Timing - Controlling when the probes output the data they have generated
• 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 state
• 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.
• Internal
• 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)
Format - The format of the data output by the probe
• 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)
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.

Other issues

• 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 & activated.
• 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 perspectives:
• 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 local process.
• Pass by reference - If a probe needs to modify data, then pass by value (e.g. XML events) complicates things a bit.
If probes never modify data, we could potentially view probe stubs as probes, and then view probes as gauges.
• ...

© Copyright 2000 Object Services and Consulting, Inc. All Rights reserved.