test

Java Dynamic Management Kit 5.1 Getting Started Guide

Chapter 3 Development Process

This chapter outlines the main tasks in developing management solutions using the Java Dynamic Management Kit (Java DMK).

This chapter is concerned mostly with design issues in the development process. For an explanation of how to write the code of management applications, see the programming examples in the Java Dynamic Management Kit 5.1 Tutorial.

The tasks are described in the following sections:

Figure 3–1 summarizes these tasks, from crafting MBeans in your factory to deploying them through the web.

Figure 3–1 Development Process

Development process

3.1 Instrumenting Resources

MBeans conform to the JMX specification, which standardizes the representation of the MBean's management interface. Therefore, the first task in the development process is to define the management interface of your resources.

If you are creating new resources, you must determine the granularity of the information about that resource. How many attributes need to be exposed for management? What operations will be useful when the resource is deployed? When should the resource send notifications? The answers to these questions determine the granularity of your MBean's management interface.

Consider an MBean that represents a printer. If your MBean is exposed to end users, it might need only to expose a state attribute, ready or offline, and perhaps an operation such as switch paper trays. However, if your MBean is intended for remote servicing, it must contain much more information. Operators need to know such information as the total print count, the toner level, and the location of a paper jam, and they might want to run self-diagnostics.

Sometimes resources are already manageable through another system. In this case you need only to translate their existing management interfaces into an MBean. Because the JMX architecture is rich, you can usually improve the existing management interface in the translation. Some operations might not be needed because they can be replaced by an agent service. New attributes might be added now that they can be computed dynamically.

As more vendors adopt the JMX specification, resources will be supplied with their instrumentation. Your task will then be to understand the management interface that is provided and to integrate the MBean classes into your application. In this case you will be integrating MBeans from various sources and ensuring that they interact as expected.

3.2 Designing an Agent Application

Given the set of resources you want to manage, you need only to register their corresponding MBeans in an agent, and they become manageable. However, designing an effective agent is more complex.

When designing your agents, you must keep in mind the nature of the management application that will access them. You must strike a balance between services that unburden your clients and making of your agent application too complex.

The simplest agent is one that contains an MBean server and a connector or protocol adaptor. The class for this agent can be written in 10 lines of code, yet this agent is fully manageable. Through the one communication component, a manager can instantiate agent services and dynamically load new resources. The minimalist agent can grow to contain as many MBeans as its memory can hold.

At the other extreme, your entire management solution could be located in the agent. All the policies and all resources you need could be managed locally. This application can become overburdened with its management tasks and does not take advantage of distributed management logic. You need to decide between how much management logic can be performed locally and how much is distributed across your whole management solution.

The functionality of your agents is most often determined by their environment. Some agents might be limited by their host machine. When memory or processing power is limited, an agent can be expected only to expose its MBeans and perhaps run a monitoring service.

An agent in a more powerful machine has the liberty to run more services and handle more MBeans. For example, the agent at the top of a cascading hierarchy might establish relations between MBeans in all the subagents. Desktop machines and workstations can easily handle agents with thousands of MBeans.

The hierarchical model is very appropriate, because management logic and power are concentrated toward the top of the hierarchy. The information from many small devices becomes concentrated on a few large servers where the management consoles are located. In between are medium-sized agents that perform some management tasks, such as filtering errors and computing averages across their subagents.

3.3 Designing a Management Application

This section focuses on developing a management application in the Java programming language. Java applications access agents through connectors which preserve the JMX technology-based architecture. All management requests are available through the connectors, making the communication layer transparent.

Beyond the specifics of establishing connections, accessing MBeans, and using proxies, there are more general programming issues to consider when implementing a management application.

Without going into the details, a list of features that managers might need to implement is given here. A full treatment of these topics would fill several books and several of these issues will probably remain research topics for years to come:

Do not let this list of complex issues scare you away. Not all of these features are needed by all managers. Only the largest management applications would implement full solutions to any one of these issues.

The modularity of the JMX architecture lets you start with a basic manager that is only concerned with accessing resources in an agent. As your needs evolve you can explore solutions to the issues listed above.

In parallel to the programming issues, there two major design issues to consider when developing a management application: the flow of information, and the specificity of the solution.

3.3.1 Defining Input and Output

A management application serves three purposes: to access resources in order to give or receive information, to perform some operation on this information, and to expose the result to others. The operation that a manager performs on its information might be some form of computation, a concentration of the data, or simply a translation from one representation to another.

For example, a manager for a network might collect bandwidth data from routers and calculate averages that are available through some API. The manager also monitors all data for abnormal values and triggers a notification when they occur. These could arguably be the tasks of a smart agent, but let us suppose it is an intermediate manger for very simple agents in the routers.

Now consider a second example: a graphical user interface for managing a pool of printers. Agents in the printers signal whenever there is an error, the manager reads other parameters to determine whether the problem is serious and displays a color-coded icon of the printer: red if the printer needs servicing, orange if it is only a paper problem, and green if the printer is now back online.

In both cases, the applications can have much more functionality, but each function can be broken down into its three facets. By identifying what data needs to be collected, how it needs to be processed and how it needs to be exposed, you can determine the agents that need to be accessed, the algorithms that need to be implemented, and the format of the output.

3.3.2 Specific Versus Generic

Another design choice is whether you need a specific manager or a generic management solution. The two examples above are applications designed for a specific task. Their inputs are known, their agents are listed in address tables, and they are programmed to provide a specific output for given inputs.

A generic management solution is much more complex. It takes advantage of all dynamic features in the JMX architecture. Agents and their resources are not known ahead of time, data formats are unknowable and the output is at best a set of guidelines. Generic managers do not implement a task, they implement a system for integrating new tasks.

Let us extend our printer management system to perform some generic management. First, we set a guideline of only managing printers whose agents contain discovery responders. That way, we can detect when printers are plugged in, we can connect to their agents, and we can add them to the management console automatically. Then we make a space in our user interface for a custom printer interface. If the printer's agent has a resource called HTMLserver, we will load the data from this server into the screen frame reserved for this printer.

Users of this management system can now install a server-enabled printer, and it will be managed automatically when it is plugged into the network. Of course, this system is only viable if you advertise the ways in which it is generic, so that printer manufacturers are encouraged to add Java dynamic management agents to their products.

Generic management systems are complex and perhaps difficult to design, but they are definitely in the range of possibilities offered through the JMX architecture and the Java Dynamic Management Kit.