Java in the management sphere, Part 3

In the first two articles of this series, I defined the management space, acknowledged its legacy, and set the stage for Java’s entrance into it (see “Read the Whole Series!” below). I also penned a brief look at Java’s history and at Sun’s pioneering efforts in two technologies — JMAPI and Java DMK. Those technologies led to the development of Java Management Extensions (JMX), which brings us to present-day Java. In this article, I discuss Jini and Jiro, as well as recap the influence of JMX. But first, here is a speculative look at the future of management applications in general.

You may recall that, over time, management applications become as complex and strategic as the network itself. As each enterprise acquires its own heterogeneous network, management applications have to fill the need exposed by that growth. Moreover, two trends are obvious: everything is getting smarter, and everything is either connected or getting connected to the Web. Thus the typical heterogeneous network is growing dramatically even as its complexity increases.

Not a week seems to go by without a news story about the newly acquired intelligence of some unexpected device. Intelligent devices — your coffeemaker, microwave oven, cell phone, automobile, wristwatch, sneakers — are rapidly becoming the norm. Soon, almost everything we use in our daily lives will be smart by means of ultracheap microprocessors, and they will most likely be connected, and therefore manageable, via the Internet.

It is safe to say that some legacy interfacing will be required for these new devices. What are the other implications of this growth? Beyond the obvious barrage of devices that will require the coding of new managed objects (at the very least), you might one day need a systems administrator to install and configure a third-party MP3 player in the Internet-connected LAN that is your sport utility vehicle. Simply put, by inheriting the benefits of the legacy, we also inherit some of the problems.

Consider this analogy: 50,000 people attend a sporting event in a large stadium. The game is close, and everyone stays until the final moment. All 50,000 people leave the stadium at the same time. From a programming perspective, what model might you employ to most optimally and safely empty the stadium and move each person from seat to exit? Would a central-point-of-control model work best? It would let you analyze the status of each exit, the number of other people in proximity, and the relative cost of queuing. However, this model could not account for the relative physical capability of each person in the stadium, as some people move faster and more efficiently than others. Would a distributed model work better, one in which each “agent” makes its own decision based on its own imperfect, changing information base and rule set?

Emptying the stadium means managing chaos. As an abundance of Net-hungry appliances invades your home, means of transportation, and communications, taking advantage of each device’s capacity by integrating it with an existing network — that is, managing the device — will become just as important as the device itself. But the explosive growth in devices will only exacerbate an already crowded management landscape.

The prudent Java developer should also consider more than today’s management issues. Tomorrow is just as critical: we’ve seen the future, and it’s cluttered and complex. How are we going to keep up?

JMX recap

Last month, I noted that the entrance of Java into the management space was heralded by the introduction of the Java Management API (JMAPI). The strength of the original JMAPI was also its biggest flaw: it was a design based on a management framework written entirely in Java. While it does make good sense to use the advantages of Java in many applications, perhaps even management frameworks, ignoring the enterprise legacy is simply not wise.

In fact, despite two years of effort, Sun was still not able to integrate JMAPI with Sun’s non-Java network management offering Enterprise Manager. Not only did they both offer the same functionality, but they also implemented it in incompatible ways. JMAPI was a “deep” implementation. It therefore directly competed with existing management products — unlike similar Java APIs such as the Java Message Service and Java Transaction Service, which feature a server provider interface to which legacy products can connect.

The lessons learned with JMAPI and the Java Dynamic Management Kit (Java DMK) gave rise to the Java Management Extensions (JMX), which are currently ensconced in the Sun Community Process. Simply speaking, JMX provides a formal extension to Java that allows integration with legacy management frameworks. At the same time it gives you the freedom to explore more intelligent, autonomous-agent approaches to the burgeoning management-space problems.

The magic of Jini

If you’re a regular JavaWorld reader, you have probably come to understand the architecture and promise of Jini, at least for device configurations. A simple set of protocols layered on top of the Java Virtual Machine via RMI (Remote Method Invocation), Jini is revolutionary in that it changes the way we look at network resources, services, and even management.

Among other things, Jini has been positioned as a “plug and work” technology. Solving the problem of bootstrapping into a network from a device is a significant accomplishment. But Jini has the potential to do so much more, such as facilitating bold new approaches to system and network management. Consider the Jini protocols and programming interfaces:

• Discover and join: Help an arbitrary device enter the network
• Lookup: Creates a repository of available services
• Object leasing: Facilitates a fundamental “transaction” view of the network
• Distributed events: Extends the Java event model to work in a distributed manner

The protocols give rise to a wide array of Jini devices and services, which makes it easy to configure and integrate a given device into the network, or even initialize the network itself. But the notion of the self-healing network also arises as a result of these simple protocols and programming interfaces. (For a more complete discussion of Jini and impromptu networking, see the Jini links below.) A similar set of issues involved in bootstrapping a device into a network surfaces during routine maintenance of the network. Hence, managing a Jini network — one in which network nodes are either Jini devices or devices managed via Jini proxies — should be considerably less complex for the developer than legacy approaches to system and network management. And it should certainly be more cost effective for Jini network owners, as far fewer problems will require the intervention of a systems administrator.

Rather than the gnarly legacy point-to-point model described in Part 1 of this series, Jini presents a set of distributed Java objects, dynamically and easily bound to network appliances. These appliances, Jini devices, can routinely change state, reconfigure, and participate in a more democratic network, depending on network conditions, demands, and service availability; they’re not unlike the autonomous agents in the sports stadium. This distributed-object view, coupled with the bootstrapping capabilities of Jini objects, makes Jini worth considering as a platform for management applications.

The spin on Jiro

We come now to Jiro. New from the Java Community Process, the Jiro platform provides a Java-based environment for deploying management solutions across the enterprise. It uses Jini and the Common Information Model (CIM) from the Distributed Management Task Force (DMTF), yielding an open platform for management services and devices across heterogeneous networks. (For a description of CIM, see Resources.) Jiro’s focus on storage area networks (SANs) is intentional: it’s perhaps not so much a technical restriction as it is market positioning — dining on an elephant one bite at a time. The Jiro platform supports services and facilities required for more generic management solutions, despite — or maybe because of — its current focus on storage.

The set of basic services in Jiro includes distributed logging, transaction management, event handling, internationalization, and task scheduling. By leveraging these services, developers can be free to focus on functionality that is more germane to their efforts. The Jiro FederatedBeans model defines how components — as collections of objects — are connected and deployed. While the component model can simplify both development and deployment, it is still a new component model in Java that is specific to Jiro. FederatedBeans extends the basic JavaBeans component model with capabilities suited for highly distributed management.

Developers need to be assured there will be sufficient community acceptance of a new model to justify the development investment. At a recent Sun-sponsored forum, 45 companies sent developers to learn about the Jiro platform. This is, perhaps, a good start toward acceptance.

Despite Jiro’s SAN spin, it does demonstrate the strength and flexibility of the Java platform insofar as system and network management solutions are concerned. In this chaotic age of ubiquitous connections and devices, we need approaches like Jiro. The combination of Jini protocols with standard object definitions and Jiro’s base-level management services provides an extensible management framework. This framework can be viewed as a virtual classroom where we teach our increasingly smarter devices how to be well-behaved netizens, as well as how to react independently when necessary. And that, in a nutshell, is how we are going to manage the chaos.

Java’s legacy

For a number of reasons, Java has made good sense as the platform of choice for management applications. On the server side, developers are simply more productive because of 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 will take the Java community to determine whether Java will ultimately succeed in this arena. The emergence of JMX and Jiro from that community has made them notable technologies to that end, validating not only the platform but also the process that enhances it.

Source: www.infoworld.com