Developer

JMX keeps your Java apps connected

Java Management Extensions (JMX) connect your Java applications to existing systems, such as mainframes. See how the JMX specification can help you keep Java apps working with other systems without having to master proprietary APIs.


Over the past few years, Java has played an extraordinary part in the evolution of distributed applications and systems. We have witnessed a monumental leap forward in the ability to connect Java-enabled applications to existing systems, resources, mainframes, and devices. With this acceleration of connectivity, the need for a standard that defines a universal approach in which to manage all of these entities has become apparent. As a result, the Java Management Extensions (JMX) specification has emerged.

The environment of distributed applications and systems today is dynamic and unpredictable, and attempts to manage these applications and systems with traditional static solutions are proving inadequate. JMX has been introduced to the Java programming realm to allow any Java component to become inherently and dynamically manageable.

The Java Community Process (JCP), along with industry leaders, has defined the JMX specification as the standard for managing systems, applications, and resources using the Java programming language. JMX prompts developers to consider management a fundamental issue instead of an afterthought.

JMX defines a standard method for dynamically augmenting Java objects with management attributes and operations. This method, known as instrumentation, allows developers to focus on their area of expertise without concerning themselves with conforming to a proprietary management API.

Management at three levels
JMX is designed around a three-level architecture. This design promotes an optimized development framework by enabling different segments of the developer community to focus on the level that best fits their strengths. The three levels of JMX are defined as:
  • Distributed services—This level targets the management application community by defining a mechanism for locating and accessing agents and MBeans regardless of their physical location. This level concerns itself with lookup services, connection protocols, message exchanges, etc.
  • Agent—This level targets the management application community by defining a mechanism for building management agents. Management agents store, control, and expose MBeans to management clients through a registry, known as an MBean server.
  • Instrumentation—This level targets the Java developer community by defining a mechanism for instrumenting resources, known as Managed Beans, or MBeans. A resource can be an application, a service, a device, etc.

Figure A illustrates the three levels of the JMX architecture.

Figure A


Managed resources and MBeans
A managed resource is any entity such as an application, a service, a component, or a device that can be exposed using the Java programming language. A Managed Bean (MBean) is a Java object that represents a manageable resource. JMX defines four types of MBeans:
  • Standard MBeans expose their manageable attributes and operations by implementing a Java interface containing methods that adhere to standard JavaBeans naming patterns for getters and setters.
  • Dynamic MBeans dynamically expose manageable attributes and operations using discovery methods at runtime.
  • Model MBeans extend dynamic MBeans to act as a proxy for the actual objects that are to be managed. The managed objects are wrapped by Model MBeans at runtime, which then delegate all attribute and operation calls to the managed objects.
  • Open MBeans extend dynamic MBeans to advertise their attributes and operations using metadata consisting of a predefined set of standard Java types.

MBean servers and agents
An agent is a software component that brokers requests and responses between MBeans and MBean clients. It consists of specific business logic, an MBean server, a group of agent services, and at least one protocol adaptor or connector.

MBean clients interact with MBeans through an agent and can get or set attribute values on the MBeans or invoke operation calls on the MBeans. MBean clients can also interact with an agent to register to receive notifications that are transmitted by an MBean.

An MBean server is a software component that acts as a registry for MBeans and provides services to MBean clients so they can manipulate MBeans. All interaction with an MBean must be performed through interfaces on the MBean server. Figure B illustrates the interactions that take place between MBean clients and MBeans.

Figure B


Agent services
A JMX agent must expose certain mandatory services to clients, as defined by the JMX specification. These agent services include:
  • Dynamic class loading—This service uses a management applet, or M-Let, to retrieve and instantiate classes from URL-specified locations.
  • Monitors—This service checks the attribute values of an MBean at specified intervals and notifies other objects if conditions, called gauges, have been met.
  • Timers—This service provides a scheduling mechanism that transmits event notifications at certain dates and times or at predefined intervals.
  • Relation service—This service facilitates user-defined associations between multiple MBeans using roles. The consistency of a relation is maintained by an agent monitoring the MBean’s state and removes the MBean from the relation when the MBean’s state causes the relation to become invalid.

Distributed services
An agent can be located and accessed by remote managers or other MBean clients over any communication protocol using objects known as protocol adaptors and connectors. Once an agent is located, a client operating remotely can communicate with the agent to interact with the MBeans registered with the MBean server in the agent. The prominent components of the distributed services level include:
  • Connectors—These components provide transparent interaction between an agent and management applications. Connectors rely on a client and server component that is specific to a given protocol but expose the same interface to a client, allowing transparent access to an agent by management tools regardless of the underlying protocol.
  • Protocol adaptors—These components define interfaces to agents using semantics of a given protocol, such as HTTP. Each protocol adaptor provides a unique management view of the agent.

JMX meets the challenges of dynamic enterprise systems
Modern enterprise systems and applications are dynamic and unpredictable, presenting unique resource management challenges. JMX seeks to meet these challenges by providing a framework and programming interface that defines a powerful array of management technologies that can be used to instrument resources and build dynamic management tools using the Java programming language.

We have just scratched the surface of JMX in this article. In future articles, we will explore the technologies of JMX in depth and demonstrate how they can solve management problems and serve as common integration models for development and integration platforms.

Editor's Picks