Intermetrics' OWatch Debugging Technology for Distributed, Component-Based
Systems*
Jeff Rees, Intermetrics, Inc.
-
"By 2001, at least 60 percent of all new applications development will
be based on assemblies of componentware, increasing both speed to market
and the ability to cope with change." Gartner Group
-
"Sales in this market [component technologies] amounted to $240 million
in 1996 and will grow to $3.3 billion by 2001." Giga Information Group
Improving Reliability and Increasing Productivity of Software Development
Within a few years, most of the software we use will be assembled from
components or objects, with heterogeneity a factor in every dimension.
The vision of the component-based software movement is:
-
smooth integration of components from multiple vendors,
-
effective utilization of distributed component processes running on heterogeneous
hardware platforms and operating systems,
-
inter-operability between component frameworks, and
-
enterprise-wide and mission-critical systems assembled dynamically to meet
operational needs.
In response to this vision, Intermetrics is developing OWatchTM,
a practical analysis and debugging tool for distributed, component-based
software, with a particular emphasis on systems of components in operation.
Component technology is taking off with a rapidly growing market for
tools. Debugging will be necessary, whether the component composition has
been manual or automated or whether the composition is being performed
by a professional system integrator or a less sophisticated user. Interface
incompatibilities between components will occur. OWatch will help detect
and correct interface incompatibilities, even when dealing with dynamically
evolving systems.
The heart of OWatch is an extensible, event-driven framework that accepts
diagnostic input from software probes attached to the operational components.
The probes respond to requests from the debugging framework to gather information
and, where appropriate, control the behavior of the components to which
they are attached. The framework also acts as the conduit through which
information and requests travel between graphical user interface components
and the deployed software probes.
Requirements for Debugging Component-based Systems
To meet the needs of this growing market, a debugging tool which adds real
value to development tools needs the following characteristics:
-
Distributed: accesses diagnostic information equally from local
and remote systems
-
Event-driven: the tool must support asynchronous inputs from multi-threaded
and multi-process applications, as well as from its own graphical user
interface (GUI).
-
Message-based: the debugging challenge for distributing component-based
applications lies more in the interaction between components than in the
integrity of the components themselves. The tool must allow users to view
message traffic, such as method invocations and application events, among
components in a variety of data and time-based ways.
-
Multi-process: modern applications consist of multiple, concurrent
processes – the client, the middleware, the server – running on multiple
machines. A debugger must allow the developer to view these processes concurrently
and at different levels of abstraction; for example, viewing a method invocation
at the message level, then at the message-content level in order to view
parameters and, below that, at the language level to analyze types and
field data.
-
Multi-target: Application components will run on the full gamut
of systems from mainframes to personal computers.
-
Multi-Platform: Even Java applications need to deal with the differences
between virtual machines. And the picture gets more diverse outside the
Java world, with different operating systems and component technologies.
OWatch needs to deal with systems that encompass multiple component technologies
including JavaBeans , COM and CORBA .
-
Intelligent: Developer success cannot depend on the developer’s
intimate knowledge of the connectivity of each component integrated into
the application s/he is developing. A debugger can use a model of the target
environment to understand where it should be monitoring messages.
-
Autonomous: Some of the most important information a debugger can
capture is what happens when components are not communicating well, or
how components behave when the network fails. So, the debugger must persist
through system malfunctions and continue collecting data to download and
review when connections are re-established. In the world of Inter-, inter-,
and extranets, this tool must be able to deploy probes beyond a firewall
and maintain or reestablish secure communication.
Debugging Software Components Today
While there are numerous excellent debugging tools for use in developing
individual components (every computer vendor provides at least one), few
of these address the problems encountered in developing distributed applications.
Hardware and software vendors are focused on promoting their competing
component technologies, with surprisingly little debugging support being
offered. As we researched this market, discussions with major vendors made
it clear that debugging support is not a top priority. These vendors are
focused on winning platform wars. Debugging is on the enhancements list
of every Integrated Development Environment (IDE) and Application Development
Environment vendor. They understand the need for debugging capabilities,
often encountering debugging challenges within their own applications.
But with today’s compressed release cycles they are hard-pressed to add
competitive features while simultaneously coping with evolving standards
such as Java and COM. To devote five to ten person/years to developing
and then maintaining a debugger is difficult to justify when their product
is battling for position in the current dynamic and crowded marketplace
for Internet and component technology tools. The struggle among component
technologies - JavaBeans, COM and CORBA - throws the most powerful software
vendors into competing camps in which it is rare to acknowledge a competing
technology by offering distributed debugging services that address the
technologies promoted by their competitors. The resulting state of debugging
tools today is predominately that of single process tools that debug a
single, polarized vendor environment. Few address distributed applications,
and fewer still have managed to keep current with the dynamic component
marketplace.
Intermetrics Vision
Future systems will be heterogeneous and constantly evolving. Software
environments will remain heterogeneous with multiple network protocols,
hardware types, and operating systems. Applications will include increasing
amounts of component software that will be added to and often will encapsulate
a legacy of working applications. Many applications will involve the use
of more than one of the component technologies, as ever more applications
are built by assembling existing components and subsystems "as is". We
expect that component technologies CORBA, JavaBeans, and COM will all have
significant market share in 2000. It is also likely that new technologies
will emerge which are at least as important. OWatch will be capable of
capturing, recording, displaying, playing back, and modifying the message
traffic between the software components in the distributed application.
It will understand existing and emerging component technologies being used
to build complex, distributed applications. Its readily extensible architecture
provides a sound framework to keep pace with the rapid evolution that is
characteristic of the distributed application domain.
Intermetrics' Goals for OWatch
Our primary mission is to increase the reliability of the component software
that will be used in the distributed enterprise. We want to increase the
productivity of application developers who have to deal with real-life
applications distributed across the heterogeneous environment. We want
them to be focused on component semantics and interactions, not the low-level
details characteristic of source-level debugging. We are focusing on the
dynamic analysis of systems of components in operation, allowing incompatibilities
to be detected and corrected quickly. The component-based software vision
anticipates components being dynamically linked at the time of use, necessitating
tools that deal with dynamic behaviors. The tool must permit the evolution
of components which are used in diverse contexts by thousands - even millions
- of users.
Message-based Debugging of Distributed Component Applications
OWatch will be a highly customizable tool for debugging distributed applications
built using standard component technologies – COM, CORBA, and JavaBeans.
OWatch will allow developers and support personnel to place ‘probes’ at
strategic points in the distributed application that will intercept, interpret,
display, and play back the message traffic between the application components;
its event-driven framework is ideally suited to the requirements of this
message-based debugging.
OWatch will record the data collected by the probes in its own event
history log. Plug-in viewers will analyze this data, and based on a semantic
understanding of the application, will display it in user-meaningful ways.
For example, a strip-chart viewer will display the message traffic between
application components over time. The strip chart will be scrollable forwards
and backwards, with the user being able to drill down into individual message
contents.
Autonomous Probes
The probes themselves will be resilient to communication and other logistic
problems to which the application itself is subject; the ability to survive
a network failure, for example. When the network connection is re-established,
the probe will transmit data collected during the failure. Probes will
be intelligent; when they are dispatched, they will determine the nature
of the target component and dynamically load the appropriate target-specific
code.
Ease of Use
Key to the ease-of-use and effectiveness of OWatch will be the user’s ability
to select and place probes at strategic points in the application. However,
the complexity of the "plumbing" used in integrating the various component
technologies requires the user to possess considerable expertise in order
to position probes correctly. To meet our objective to increase programmer
productivity, OWatch will automatically place probes and automatically
configure itself according to semantic models of the distributed applications.
It will provide the ability for the user to attach debug-time viewers of
choice, either standard GUI widgets or user-supplied application
specific viewers, using a graphical model of the application to specify
the attachment point.
OWatch is a trademark of Intermetrics, Inc.
* Initial exploratory development of component-based
debuggging was funded in part by the Defense Advanced Research Project
Agency under contract F30602-96-0217. Continued research related to OWatch
is being funded jointly by Intermetrics and the National Institute of Standards
and Technology under a NIST Advanced Technology Program Award