Java in the management sphere, Part 2

Java enters the management arena with JMX and Java DMK

In the first part of this series, I introduced the first layer of contextual groundwork for the union between Java and management -- defining the management space, acknowledging its history and legacy, and setting the stage for Java's entrance into it. This month, I'll proffer the next layer with a look at Java's history, and then explain how Sun pioneered its Java management efforts with two technologies -- JMAPI and Java DMK -- and ultimately developed Java Management Extensions. If you're a regular JavaWorld reader, you probably know enough about Java's history, so I will merely provide a brief account as a preface. (For an in-depth historical account, see "Java Technology: An Early History" by Jon Byous in Resources.)

The history of Java

Java, originally called Oak, was developed by James Gosling, Patrick Naughton, and Mike Sheridan as part of Sun's Green Project, which began in December 1990. Chartered to explore the next wave of computing, the group quickly came to the conclusion that the convergence of digitally controlled consumer devices and computers would be one wave for Sun to catch.

Using Oak, the processor-independent language developed by Gosling, the group designed and built a SPARC-based, handheld wireless PDA, known as the *7 ("star seven"), with a five-inch color LCD and touch-screen input. The *7 was finished and demoed in September 1992 (see Figure 1). However, while the *7 was considered interesting technology, Oak became the thing of most interest. The language was able to control a wide range of entertainment platforms and appliances while displaying animation. This was the beginning of what has grown into the Java platform.

Figure 1. The original

Over the next few years, the nascent Java language grew within Sun as the Java development team grew to about 30 engineers. On May 23, 1995 John Gage, director of Sun's science office, and Marc Andreesen, cofounder and then executive vice president at Netscape, announced to a SunWorld audience that Java technology was real, official, and going to be incorporated into Netscape Navigator. At the time, the entire Java technology team numbered less than 30 people. Needless to say, in order to grow the platform to the point where it could be a viable candidate for enterprise-level application development, an enormous amount of work still needed to be done.

Pioneering Java management efforts: JMAPI

In many ways, Sun's JMAPI (Java Management API) efforts can be considered as pioneering as SNM was in its day (see Java in the Management Sphere, Part 1). The approach, to create a management framework that behaved much like traditional management infrastructures (like, for instance, those from Tivoli or Computer Associates), but entirely written in Java, was as viable as it was compelling -- at the time.

When the original Java announcement was made, Sun (specifically, Sun's SunSoft division) had a development site called the Rocky Mountain Technology Center (RMTC) located in Colorado Springs, CO, which would remain operational until 1997. At its peak, roughly 150 engineers and managers worked at the RMTC, which delivered unbundled Solaris products (that is, software products not shipped with the base Solaris operating system) including Sun's Disk Suite, Backup Co-pilot, Solstice Backup, and Admin Suite. In 1995, the RMTC's human factors engineering (HFE) group was asked to study various screen layouts for a management console, as part of a plan to engineer a next-generation system- and network-management product.

During its study, the HFE group used a number of different console prototypes that had been designed by RMTC engineers. In addition to management-specific prototype designs, the group decided to give Netscape Navigator a try. At the time, the browser had already started to take off. Adding it to the testing efforts was simply intended to provide an additional data point; it wasn't meant to emerge as the design of choice.

Much to their surprise, the HFE engineers discovered that design concepts behind the browser made for the most intuitive interface for the specific design problems associated with achieving an optimal management console. Once this was realized and digested, the idea of using Java to extend console features was obvious, since HTTP alone was not a rich enough set of protocols to provide a viable management infrastructure. At the very least, SNMP needed to come into play, since SNMP was and is the most important legacy protocol in the systems and network management application space (see Java in the Management Sphere, Part 1 for an overview of SNMP). And as soon as Java was recognized as an ideal technology for the console, the benefits of using it at every point along the way became very clear.

Bear in mind that Java was still in its early stages at that point. The Swing set had not yet appeared, and early versions of the Abstract Windowing Toolkit (AWT) did not provide all the widgets needed for a management console. In its early stages, JMAPI consisted in large part of a large class library called the Admin View Module (AVM), which extended the AWT. As more evolved versions of the Java Developers Kit (JDK) were released and new widgets introduced via the Swing set, much of the early AVM versions were deprecated.

Also pioneered in earlier versions of JMAPI was the Help subsystem. Providing a Java-based, extensible Help subsystem seemed obvious to the JMAPI team, so such a system was part of the original design. But, much like extensions to the AWT, a Help subsystem in Java was something that would have benefited any number of applications, not just those for system and network management. JavaHelp was then commissioned, thus deprecating yet more of the original JMAPI. JavaHelp software is now a full-featured, platform-independent, extensible help system that enables developers and authors to incorporate online help in applets, components, applications, operating systems, and devices.

Problems with JMAPI

In the fall of 1996, Sun announced that SunSoft's RMTC site would be closed, in light of the larger Sun-wide campus consolidation strategy. This announcement came at a particularly sensitive point in the first JMAPI reference implementation's development. Most of the original JMAPI development team left the company at that point, opting to pursue other opportunities in Colorado Springs rather than move to the SunSoft development offices in Chelmsford, MA. This was the first JMAPI delay. The second came when the project was transferred from the SunSoft division to the growing JavaSoft division, from the East coast to the West coast (and, ultimately, to Grenoble, France), just nine months after being transferred from Colorado Springs. These organizational events delayed the actual release of the first official JMAPI reference implementation to the point of rendering it moot; the original design no longer made sense. In the interim, the Java platform became much more sophisticated, the JavaSoft division became better defined, and the traditional approaches to system and network management became questioned. But early access releases of the JMAPI reference implementation did find their way to the Web, seeding the union between Java and management.

Figure 2. The (never released) JMAPI architecture

The original design of JMAPI reflected the architecture of most traditional management frameworks, in that there was a clear delineation between the management server and the managed appliance -- the manager/agent model found in most management applications. However, the strength of the original JMAPI design was also its biggest flaw: The design envisioned a management framework written in Java. And while it makes good sense to utilize the advantages of Java for many applications, perhaps even including management frameworks, ignoring the enterprise legacy will almost always spell doom for even the best-intentioned engineering efforts. The original JMAPI design sought to replace existing frameworks rather than complement them. The design also envisioned ubiquitous Java-based appliances that would rely on Java's Remote Method Invocation (RMI), rather than SNMP, for communication between Java VMs. This was well before Jini, Jiro, J2ME, or even the 100% Pure Java initiative, and even though SNMP support was added as an afterthought, the odds for wide JMAPI adoption at that time were not good. That, coupled with JMAPI's status as an organizational hot potato within Sun, doomed it as a pioneering extension to the Java platform.

Sons of JMAPI: Java DMK and JMX

A Sun engineering group in Grenoble, France, the ultimate inheritors of JMAPI, developed the Java Dynamic Management Kit (Java DMK), a Java-based product that focused more on the device side of the management equation. The first version of Java DMK, released in early 1998, touted the advantages of the autonomous agent, providing a Java-based framework for the managed object itself that would more easily plug into existing management infrastructures.

Figure 3. Java Dynamic Management Kit -- component architecture for management

Embracing legacy frameworks and protocols, and at the same time acknowledging more device-centric network management, Java DMK was for all that still a Sun product rather than an extension to Java. For Java itself to become a viable platform for system and network management, a formal set of APIs was still needed.

By the time the JMAPI hot potato landed in Grenoble, the thinking around management applications (and therefore, directions for formal Java extensions) had gelled, as had the Java community itself. This set the stage for a number of necessary architectural adjustments to JMAPI to be acknowledged. Any extension to the Java platform had to ensure:

  • Platform independence
  • Protocol independence
  • Information model independence
  • Management application independence

In addition, legacy management frameworks had to be embraced. Any formal management extension attempting to replace existing legacy systems was simply not an option for users who had to consider the value of the investment they had made -- and neither was introducing a new technology beside an existing management system, which would create two separate management entities unable to cooperate or communicate effectively. Any management solution based on Java would need to play nicely with existing frameworks and protocols, plugging in and cooperating rather than ignoring and replacing.

Based on the early JMAPI work as well as research taken from Java DMK development, the Java Management Extensions (JMX) ended public review in July 1999 and is awaiting completion of the reference implementation and compatibility test suite, as per the Java Community Process (JCP). The JCP is the formalization of the open process that SMI has been using since 1995 to develop and revise Java technology specifications in cooperation with the international Java community. The emergence of JMX from the JCP bodes well for its future. Arguably, had there been a formal JCP four years ago, we might still be talking about the future of JMAPI today.

Figure 4. Java Management Extensions (JMX)

Both JMX agents and managers integrate services that give them autonomy and intelligence. The JMX specification currently defines the interface for such basic services as a registry for Mbeans (JavaBeans for management), queries of this registry, operations on resources and the forwarding of events back to managers, dynamic loading of new Mbeans, creation of relationships and dependencies between Mbeans, timer functions, and attribute monitoring. These services enable agents to sometimes manage their own resources and let managers forward information back and forth between agents and management applications. Agents are more autonomous because they can incorporate certain management tasks, such as polling. The intelligence of agents is embodied in simple logic that can keep managers from escalating unimportant events. These two measures, autonomy and intelligence, can reduce network traffic and make management applications more robust.

In the JMX architecture, both services and devices are treated as managed objects. The components, Mbeans, can be added and removed as needs evolve. This gives scalability to both agents and managers, certainly a critical feature for thin clients. In addition, legacy frameworks are still utilized when appropriate, communicating via protocol adapters, which can provide a recognizable object to legacy applications without giving up the benefits of more autonomous agents.

Forming the union

From the beginning, Java has made good sense as the platform of choice for management applications for a number of reasons. On the server side, developers are simply more productive due to the elegance and simplicity of the language. On the agent side, Java has a small footprint and the ability to dynamically, but safely, download new features. But given a legacy of complex, proprietary, expensive management infrastructures, it's taken a Java community to manage the system and network management issues surrounding Java's ultimate success in this space.

Next month

In Part 3 of this article, I will discuss the future of management, the emergence of more intelligent devices and applications, and how all this changes the approach to system and network management applications. I will discuss the futures of JMX, Jini, and Jiro in system and network management and the role of the Java platform in this dynamic space.

Max Goff is a Staff Engineer/Technology Evangelist for Sun Microsystems and a professional member of the World Future Society. Specializing in various Java-related technologies, including Jini, the Java language, and Java and management, he has an MBA from the University of San Francisco, 16 years of experience in software development and management, and is currently pursuing a PhD in Computer Science at the City University of New York (CUNY). Max lives in Manhattan, and, in his copious spare time, is also a professional actor (SAG, AFTRA, and AEA).

Learn more about this topic

Join the discussion
Be the first to comment on this article. Our Commenting Policies
See more