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

Other issues



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 reserved.