1.9 Summary

In this chapter we have introduced and defined the historical basis for today's application, network, and systems management solutions. We can see how the progression from centralized to distributed computing created the dominant management architecture ”agent-manager. This progression created the problems to be solved by the management disciplines ”distribute, install, configure, monitor, and control ”that are implemented, supported, and deployed in today's management applications: distribution, inventory, topology, configuration, operations, event and automation, and monitoring and performance.

The management lifecycle for managed resources that we have defined is fairly pervasive across the IT industry: distribute, install, start, execute, monitor, configure, operate , stop, maintain, and uninstall. Some resources have only a subset of these phases, perhaps not requiring an explicit start or stop phase.

Managed resources can participate in their management in a variety of management patterns distinguished by the amount of participation the managed resource has. We named these patterns Event Generator, Noninterruptible, Queryable, and Operational. In order for managed resources to be well managed, they must provide internal and external instrumentation for exposing and supporting their management data, operations, and events.

Having considered the management problem in the large, let's establish the management disciplines and management applications in which JMX can be used. JMX provides a common set of metadata and APIs that can be used to implement internal instrumentation, generate external instrumentation, and access the management information. This consistent foundation helps automate and minimize the amount of system- or technology-specific definition that would have to be done to integrate the resource's management needs with an arbitrary management system.

Let's relate JMX to the topics we just discussed: management architectures, management lifecycle, management disciplines, management data, and management applications.

JMX can fulfill the requirements of the agent and subagent roles in management architectures. The MBeanServer is the agent, and MBeanServers can be cascaded into agent and subagent roles.

JMX is not best suited to help with the deploy, install, or maintain management lifecycle stages because it is a local management agent. It does not provide explicit support for system-to-system communication, moving files between systems, or version control.

JMX is best used to manage the management lifecycle from start to stop ”start, execute, monitor, configure, operate, and stop ”because it has explicit support for operations. It also has a presence in the runtime of your application and provides connectivity to control your application for system managers.

The same presence and connectivity also make JMX a natural to support the management disciplines of configure, operate, monitor, and control. JMX provides explicit support for access to management and configuration information through attributes on MBeans. JMX also provides support for local monitoring of MBean attributes via the monitoring service and by monitor MBeans.

JMX can be used to develop and support inventory, topology, configuration, monitoring and performance, or event and automation management applications. JMX's MBeanServer provides interfaces to list all MBeans that represent managed resources. The JMX relation service defines associations between MBeans that can be used to support topology applications. The notification support enables applications to send events to JMX, and JMX forwards them to event management and automation applications. Configuration, monitoring, and control applications are supported by JMX just like their respective disciplines: through MBean attributes and monitor MBeans.

The following chapters will explain the JMX technology and how it should be used to support and implement the management applications.