JMX technology provides a tiered architecture which consists managed resources and
management applications can be integrated in the plug-and-play approach as shown
in Figure given below. A given resource is instrumented by one or more Java objects known
as Managed Beans, which are registered in a core managed object
server known as the MBean server. This server acts as a management agent and can
run on most Java-enabled machine.
Fig 1. JMX Tiered Architecture
This tier consist components that enable management
applications to communicate with JMX agents. It provides the interfaces for
implementing JMX managers, and defines the management interfaces and components
that operate on JMX agents. Such components provide an interface for a management
application to interact with an JMX agent and its JMX manageable resources through a
connector, and also expose a management view of a JMX agent and its MBeans by
mapping their semantic meaning into the constructs of a data-rich protocol like HTML.
JMX comprises a separate package for each tier of the management
architecture. The instrumentation tier will be free, and other tiers can be
built from public specifications implementations available under
Sun Community Source License.
This tier contains the JMX agents which is used to expose the MBeans. It
provides a specification for implementing agents, which control the resources
and make them available to remote management applications. JMX Agents are usually
located on the same machine as the resources they manage, but this is not a
requirement. For handling MBeans the JMX agent consists of an MBean server and a set of services.
Managers access an agent's MBeans and use the provided services
through a protocol adaptor or connector. But note that JMX agents do not require
knowledge of the remote management applications that use them.
The MBean Server and
Agent Services are the main components of agent level.
MBean Server: MBean Server are the registry of objects that are exposed
to management operations in an JMX agent. Any object registered with the MBean
server becomes visible to management applications. However, note that the
MBean server only exposes an MBean's management interface and never it interact with
direct object reference. Any resources that you want to manage from outside
the agent's JVM must be registered as an MBean in the server. The server
also provides a standardized interface for accessing MBeans within the same
JVM, giving local objects all the benefits of manipulating manageable
resources. MBeans can be registered and instantiated by another MBean, the
JMX agent itself, or a remote management application through the distributed
services. When you register an MBean, you must assign it a unique object
name, which is used by the management application to identify the object on
which to perform a management operation.
Agent Services: Objects that can perform management
operations on the MBeans are registered in the MBean server. By including
management intelligence in the agent, JMX helps you build more powerful
management solutions. The JMX API defines the following Agent Services
available in J2SE 5.0:
Dynamic Class loader: Through the management
applet (m-let) service, retrieves and instantiates new classes and
native libraries from an arbitrary network location.
Monitors: Observe the numerical or string value
of an attribute of several MBeans and can notify other objects of
several types of changes in the target.
Timers: Provide a scheduling mechanism based on a
one-time alarm-clock notification or on a repeated, periodic
The relation service: Defines associations
between MBeans and enforces the cardinality of the relation based on
predefined relation types.
Instrumental Level contains MBeans and their manageable resources. It
provides a specification for implementing JMX technology-manageable resources,
which can be service, device, an application or user. A resource is manageable
if it is developed in Java and has been
instrumented so that it can be managed by JMX-compliant applications. A resource
is instrumented by one or more MBeans that are either standard or dynamic.
Standard MBeans are Java objects that conform to certain design patterns (e.g.
they must have a constructor etc.). A dynamic
MBean conforms to a specific interface that offers more flexibility at runtime.
The instrumentation of a resource allows it to be manageable at the agent level;
however, note that MBeans do not require knowledge of the JMX agent with which
they operate. In other words, any JMX-manageable resource can use any JMX agent
that offers the services it requires.
The key Components at the instrumentation level are the MBeans,
the notification model, and the MBean metadata classes.
MBeans: An MBean is a Java object that implements a
specific interface. The management interface of an MBean is represented as:
(a) valued attributes that can be accessed; (b) operations that can be
invoked; (c) notifications that can be emitted; and (d) the constructors.
There are four types of MBeans:
Their management interface is described by their method
names and simple to design.
They expose their management interfaces at runtime for
greatest flexibility and implement a specific interface.
Open MBean: Dynamic MBeans that rely on basic
data types for universal manageability; they are self-describing.
Model MBeans: Dynamic MBeans that are fully
configurable and self described at runtime. They provide a generic MBean
class with default behavior for dynamic instrumentation of resources.
Notification Model: Based on the Java event model JMX technology defines a generic
notification model. It lets developers build
proactive management solutions. Using notifications, JMX agents and MBeans
can send critical information to interested parties such as management
applications or other MBeans.
MBean Metadata Classes: These classes contain the structures to
describe all components of an MBean's management interface: its
operations, notification, attributes and constructors. For each of these, the metadata
include a name, a description and its particular characteristics (for
example, an attribute is read- write or both; for an operation, the
signature of its parameter and return types).