Object Services & Consulting, Inc.
ProbeMeister has been completely redesigned from the ground up using JDK 1.4 (it was previously JBCI - the Java Bytecode Instrumentor). Simply put, it supports the insertion of code into Java bytecode. Of course, the application may be running at the time. The application may also be running remotely on another computer. And, this can be done either via a GUI or programmatically as a backend to another application.
A high-level summary of several features:
We are not aware of any other commercial, free or research software that has these capabilities. Please let us know if you do! Many applications in this area only support static insertion offline. Some support dynamic insertion, but some of these only support it at start-up. Some support distributed instrumentation, but require libraries to be installed at the remote site first. A goal for ProbeMeister is to make it as unencumbered as possible.
Probes - The Basic Elements
ProbeMeister uses the term probe to refer to any set of Java code. In other words, a probe encapsulates a set of Java statements that one might want to insert into a running application. Probes come in two flavors, simple and stubs.
Simple probes are self-contained, while stubs are not. Stubs call out to objects called plugs. Plugs simplify the definition of a probe to one or a few lines of code. The stub calls the plug, which will then execute the body of the code. This is particularly useful if several probes share the same code, or if new methods and classes need to be defined (in the plugs) -- simple probes are limited to method modification. Plugs are also a good place if the code is complex or more than a few lines.
Simple and stub probes are defined either statically (e.g. built in to ProbeMeister) by easily extending abstract probe classes; or, for added flexibility, they can be defined programmatically on-the-fly using a statement factory.
The User Interface
Both GUI-based interfaces and programmatic interfaces are supported. So, ProbeMeister can be the front-end application, or a backend application.
Simply put, ProbeMeister records every modification as an InstrumentationRecord. Each modification contributes to (modifies) the current configuration. At any point you can view this configuration, or save it. This enables one to build customized modification definition sets, or configuration sets, for use later. At any point a configuration set can be loaded and applied to a selected connected application. An extensible XML-based schema is used for the InstrumentationRecords. This allows off-line modification to tweak the configuration files, if you like to do that sort of thing. [Future feature will include a GUI-based configuration set editor.]
A probe can be just about anything -- e.g. even contain JNI calls to other languages. ProbeMeister can probe any willing running application whether it is distributed or local, no source required.
Current development of ProbeMeister is funded by DARPA (an agency of the U.S. DoD) under the DASADA project. We are using ProbeMeister to monitor the behavior of dynamically assembled distributed applications.
To learn more about ProbeMeister technology, either contact us (below) or download a paper on ProbeMeister.
If you have any interest in ProbeMeister, please contact us. Regarding licensing, we support the "free for non-commercial use" approach. We ARE interested in joint ventures!