Covering the Java Management Extensions specification, this guide teaches programmers how JMX can provide robust management and monitoring capabilities for Java and non-Java resources including hardware. Going beyond covering the API, real-life examples and useful code are demonstrated in detail. In addition to describing the JMX specification, it provides techniques for using and extending the functionality provided by a JMX system. More specifically, included are all types of Mbeans, resources for working with JMX agents, in-depth chapters covering the JMX agent services, and ways to combine JMX with other Java technologies. Also included are chapters on using JMX with Enterprise Java Beans (EJB) and the Java Message Service (JMS) and examples of JMX adapters that can be used in applications such as TCP adapters and JINI adapters. In addition, the book contains several utility classes that will make JMX application development easier and techniques for extending certain JMX services to provide additional functionality.

The increasing demand for faster development cycles combined with the desire for more functionality has left less time for building adequate application configuration and management into Java applications. Without allowing for reconfiguration, management, and monitoring, applications fail to deliver to customers their full potential of usefulness and flexibility.

A Java programmer can provide a certain amount of configuration for an application by using property files. Developers typically use property files to configure a Java program with an initial set of parameters at startup. Imagine an application that commits certain data to a log file at a given interval. Both the path to the file and the interval could be configured in a property file. However, unless the program continues to refresh these properties, it is left with that single configuration.

Realistically, property files cannot provide complete and thorough application configuration management. With more and more configurable attributes, you will quickly find yourself stuck in a mire of property files. You could develop a management console for the application, but do you really want to have to maintain two applications and possibly construct a new console for each new application? In addition, what are you to do with your non-Java and hardware resources? These resources may have their own management consoles, but now you are looking at an array of different consoles and management tools.