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:

• Optimizing communications by dynamically configuring the connectors

• Deploying new services and upgrading agents dynamically

• Establishing and managing a hierarchy of agents

• Implementing lookup services to allow connector clients to find connector servers

• Cascading management requests through hierarchies of agents

• Handling errors and exceptions

• Recovery from crashes

• Total security

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.