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.
Ideally, you would like to configure your Java applications once during initialization and as often as needed during runtime. The same is true for non-Java and hardware resources. The ability to change the configuration at runtime relieves you of possibly having to shut down or restart an application or resource. You could provide runtime configuration management yourself programmatically, but maintaining a proprietary configuration system can be overwhelming when included with the normal range of requirements for developing useful software?especially if you consider that you might want to do this for each product being developed. Given time-to-market considerations, most development projects do not have the resources for this type of work.
However, this was the situation before the creation of Java Management Extensions (JMX). Using JMX, you can expose your application components, attributes, and configuration to management tools in a process called instrumentation. JMX uses Java classes called managed beans (MBeans for short) to expose predefined portions of your application. Management tools access these MBeans by interacting with JMX agents that make the MBeans available to any number of protocols and technologies such as SNMP, Java RMI, and HTTP.
In addition to software, MBeans can wrap native libraries that interface to hardware such as printers. JMX is independent of purpose: it can expose software components or hardware interfaces. Management applications will see all managed resources (MBeans) using the same interfaces and metadata through a JMX agent. By creating a JMX-compliant application, you expose it to remote, in-house, or third-party application management tools using a variety of protocols. Consequently, you have given your program a longer period of usefulness by creating a framework for componentization. Because JMX is written in Java, all Java applications and technologies can use it.
JMX exists because of the need for cross-platform, consistent application and resource management. This book covers all aspects of JMX today, including MBean development, protocol adapters and connectors, and all agent services. In addition, the book discusses using JMX with J2EE technologies such as Enterprise JavaBeans and the Java Message Service.