test

Getting Started with the Java Dynamic Management Kit 4.2

Chapter 3 The Development Process

This chapter outlines the main steps involved in developing management solutions using the Java Dynamic Management Kit.

The steps in the development process are:

The following diagram summarizes these steps, from crafting MBeans in your factory to deploying them through the web.

Graphic

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

Instrumenting Resources

MBeans conform to the JMX specification, which standardizes the representation of the MBean's management interface. Therefore, the first step of 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?" These are all questions whose answers determine the granularity of your MBean's management interface.

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

Sometimes, resources are already manageable through some other system. In this case, you only need to translate their existing management interfaces into an MBean. Because the JMX architecture is so rich, you can usually improve upon the existing management interface in the translation. Some operations may 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 insuring that they interact as expected.

Designing an Agent Application

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

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

The most simple 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! And 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 will hold.

At the other extreme, your entire management solution could be located in the agent. All the policies and all of resources you need could be managed locally. This application will be overburdened with its management tasks and does not take advantage of distributed management logic. You need to strike a balance 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 only be expected 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 may establish relations between MBeans in all of the subagents. Desktop machines and workstations can easily handle agents with thousands of MBeans.

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

Generating Proxy MBeans

Generating proxy objects for your MBeans is an optional step which depends upon the design of your management application. As discussed earlier in this guide, a proxy object that represents an MBean in a remote agent. The manager accesses an MBean by performing operations on the proxy MBean.

Proxy objects simplify the design of your management application because the provide an abstraction of remote resources. Your architecture can assume that resources are local because they appear to be, even if they are not. Of course, proxies have greater response times than local resources, but the difference is usually negligible.

Using proxies also simplifies the code of your application. Through the connector client, the proxy object handles all communication details. Your code invokes a method which returns a value; the complete mechanism of performing the remote management request is hidden. This object oriented design of having a local object represent a remote resource is fully in the spirit of the Java programming language.

Assuming a management application has already established the connection to an agent, the overhead of a proxy object is minimal, both in terms of resource usage and required setup. However, it is common sense to instantiate proxies only for resources that will be accessed often or which are long-lived.

The development cost of a proxy MBean is also minimal. Standard proxies are fully generated from their corresponding MBean by using the proxygen compiler supplied with the Java Dynamic Management Kit. Generic proxies are part of the Java Dynamic Management runtime libraries and just need to be instantiated.

Options of the proxygen tool allow you to modify the characteristics of the proxies you generate from an MBean. For example, the read-only option will generate proxies whose setter methods return exceptions. By generating sets of proxies with different characteristics from the same MBean, you can develop a Java manager whose behavior is modified at runtime, depending on which set is available.

In an advanced management solution where resources are discovered only at runtime, the proxy class could be loaded dynamically in the manager. For example, the resource might expose an attribute called ProxyURL from which a class loader can retrieve the proxy object.

Designing a Management Application

In this section, we will focus on developing a management application in the Java programming language. Java applications access agents through connectors which preserve the JMX 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, we give a list of features that managers may need to implement. A full treatment of these topics would fill several books and several of these issues will probably remain research topics for years to come:

Don't 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 which 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.

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 may 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 which 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 only a paper problem, and green if the printer is now back online.

In both cases, the applications may 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 which need to be accessed, the algorithms that need to be implemented, and the format of the output.

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 may 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 we 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.