IN THIS CHAPTER
The JMX specification divides the architecture of a JMX-based management system into three separate levels. Each level has a distinctive role in the architecture and addresses separate aspects of the architecture of a management system.
In this chapter, you will look at each level of the JMX architectural model, identifying the role of each level and how it should be used as part of the management system. Two of the levels—the agent level and the instrumentation level—are defined in the current 1.0 version of the JMX specification (see Figure 2.1). The third level—the distributed services level—is mostly unspecified at the time of this writing. However, you will still look at how the distributed services level fits into the JMX architecture model and later, in the second part of the book, go into detail on some possible implementations of the distributed services of the JMX architecture.
The instrumentation level defines how to implement the MBeans to make the resources manageable by JMX-compliant management tools. The instrumentation level defines the MBean and four different types of MBeans—Standard MBean, Dynamic MBean, Model MBean, and Open MBean.
You will learn about the first three MBean types in detail in Chapters 3, “Standard MBeans, 4, “Dynamic MBeans, and 5, “Model MBeans.” The Open MBean specification was still not finished in the 1.0 release of the JMX, so it is not a mandatory part of the JMX implementation and is subject to change. Consequently, none of the current JMX implementations can claim compliance with the Open MBean specification. A quick overview of Open MBeans is given in Appendix B, “Open MBeans.”
In the agent level, the JMX specification defines the role of an MBean server. The MBean server is a key component in the management architecture and is responsible for delegating all the invocations between the management applications and the managed resources—acting as a communication bus between them. This isolates the managed resource from the management client, which creates flexibility in managing systems requiring high availability.
MBeans can be updated, redeployed, and moved between MBean servers without having to necessarily detach the client communication from the server. The management applications never directly reference the resource they manage. Instead, the agent level introduces a concept of object names that the client software uses as an indirect reference to the resource. You will see in later chapters that this is one of the key architectural designs in the JMX-based management solutions.
Finally, the distributed services level defines how the communication between the management applications and a remote agent or agent-to-agent communication should be implemented. This level is not yet specified by the current 1.0 version of the JMX specification, leaving most of the details open for interpretation. This is unfortunate because all remote communication between the clients and the MBean server becomes dependent on a specific JMX implementation. The distributed services level will be defined in the second phase of the JMX specification. At the time of this writing, there are some plans to get this second phase started. You will spend a good portion of the second part of this book in looking at implementation options for the distributed services of JMX.
The problem of managing applications partly stems from the wide variety of different types of software in existence today. There are applications ranging from simple helper tools, such as the infamous Notepad, to applications that handle critical business transactions. However, not all types of applications need a full-blown management system behind them. Notepad is quite an unlikely candidate to need a management system, whereas middleware servers handling the flow of business processes are very likely candidates for requiring a management infrastructure. The complexity, size, and criticality of the application are often the deciding factors.
Today, you increasingly see software that has become more and more distributed in nature. More software is being transformed from the traditional client/server two-tier architectures to three-tier or n-tier architectures. Many envision a future where software is run on a set of distributed servers on the network. Applications are built from components that support advanced, and somewhat complex features including transactions, clustering, fail-over, location transparency, and so on. New service-based platforms, such as the J2EE, are being designed and built, adding new services and component types to applications. The new development is focused on techniques to maximize the potential for scalability. By breaking functions into smaller components, the application can be spread across many servers, in many different ways. This will result in increased reliability.
However, all this adds to the complexity of managing an application. The application has become more dynamic. It changes during its lifetime, new software components and plug-ins are added, old ones are removed and the existing ones replaced and patched. The application can exist in various, highly different environments, from the client desktop to the server machine, from a cell phone to an air traffic control system. The architecture, the size and the runtime environment among different types of software in use today varies enormously.
Often, you find that many of the different types of applications have one thing in common—they somehow need to be managed. You need to enable the administrator to make adjustments to the application's configuration, fine-tune it, update it, and monitor its performance. You also want to provide the tools for administrators to do this easily. And more than likely, you do want to build the management system that allows all this just once, instead of implementing it individually per application.
Some standards have emerged during the years, some were designed by committees, some were picked up out of necessity. For example, the Simple Network Management Protocol (SNMP) is currently the de facto standard for network and device management. The Distributed Management Task Force (DMTF) has defined a Common Information Model (CIM) and a Web-based Enterprise Management (WBEM) using XML schemas. Big industry names, such as IBM and Computer Associates among others, offer their own proprietary technology and solutions to manage the IT infrastructure.
JMX offers uniformity to implementing management systems in Java programming language. The MBeans are generic enough to be able to represent many different types of manageable resources: applications, services, software components, and even devices. The JMX management architecture is independent of any specific network protocol, supporting several different connector implementations. Tools can be built to interoperate with existing management applications that support different management models, such as the Management Information Base (MIB) used with SNMP based management or CIM/WBEM models. Most notably, you can easily enable the management of your existing applications to JMX compliant management tools by exposing the management properties of your application via the JMX MBeans.
The management architecture proposed by the JMX specification aims to provide the management capability to Java applications with as little development effort as possible. The core of the architecture is the agent that is a fairly lightweight invocation bus between the management applications and the managed resources. The agent can be configured, as necessary, with a set of connectors to provide the remote access and a set of different agent service MBeans. The component-based approach to building the management agent allows greater scalability between different operating environments. The core component of the agent, the MBean server, is simple enough to be implemented for different runtime environments, ranging from J2ME to J2EE platforms. In addition to the core agent services defined in the specification, other additional services can be developed by JMX implementers. These agent services, like all MBeans, can be dynamically loaded, updated, and unloaded in the JMX management architecture.
Also, the JMX specification defines the instrumentation of resources in a generic fashion that allows any Java object to be managed. There are no specific management models for known component types but one generic way to enable all management of Java resources—servlets, EJBs, users, and so on. New component types, as well as the existing ones, can use the same methods to expose a management interface.
The instrumentation level defines how you can create JMX manageable resources. JMX manageable resources can be managed by using any JMX-compliant management application. A managed resource can be a Java object representing an application, a software component, service, a device, and so on.
The manageable resources are created through MBeans. The instrumentation level defines two basic MBean types—Standard MBeans and Dynamic MBeans. In addition, two extensions of the Dynamic MBeans are defined—Model MBeans and Open MBeans. The Standard, Dynamic, and Model MBeans are a mandatory part of the specification and are implemented by all compliant JMX implementations. The Open MBeans are not mandatory or fully-defined in the 1.0 version of the JMX specification.
MBeans can represent not only the application resources (such as a servlet, a user, or a modem) that you want to manage, but also a number of services and JMX infrastructure components that can also be managed. The agent level can add connectors, protocol adaptors, or agent services and register them as MBeans, making parts of the agent level itself manageable through the instrumentation level. MBeans can discover and invoke other MBeans registered to the server and use the services offered by other MBeans to help in management of the resource.
In addition to the MBeans, the instrumentation level defines a notification mechanism. The notifications can be used between MBeans, MBean servers, and management applications to broadcast information to interested listeners. Notice that the distribution of the notifications to remote systems is not specified in version 1.0 of JMX.
All MBeans expose a management interface via the JMX agent. The management interface consists of management attributes, operations, notification, and constructors. The management interface is described by a set of metadata classes. The management applications can discover the management interface of an MBean by querying the MBean server at the agent level.
Standard MBeans are built by declaring a Java interface that the MBean implements. The Standard MBean interface uses a set of naming conventions that allows the agent to discover and build the metadata of the management interface. Standard MBeans are often the simplest type of MBean to design and implement. However, they do lack in their ability to extend the management interface with behavioral properties (see Chapter 5, “Model MBeans”) and cannot be used to create the management interface dynamically at runtime.
Dynamic MBeans are created by implementing a generic DynamicMBean interface. This interface allows the agent to retrieve the management interface metadata from the MBean at registration. The DynamicMBean interface also declares the methods for invoking management operations and manipulating the management attributes. Dynamic MBeans do not have the compile-time restriction on declaring their management interface that Standard MBeans do. This allows for greater flexibility in creating the management interface at runtime, for example, by retrieving the relevant information from a database.
Model MBeans extend the Dynamic MBeans by the introduction of descriptor objects. The descriptors allow the developer to extend the management interface metadata by defining behavioral properties that can be attached to each individual element of the metadata. Model MBeans provide a generic management template that can be used to create and configure management of existing classes.
The agent level consists of the MBean server and a set of agent services that build on the instrumentation level. The agent level itself does not address the distribution or remote access but uses the distributed services described in “Distributed Services Level” section later in this chapter.
The JMX agent acts as a communication channel between the management applications and MBeans representing the managed resources. One of the responsibilities of the agent level is to decouple the management applications from the resource implementation. The management applications never reference the resources they manage directly; they always invoke all management operations through the JMX agent using object name references.
The central component in the agent level is the MBean server. The MBean server acts as a registry for MBeans and allows management applications to discover the management interface of the registered MBeans. The MBeanServer interface also declares the required methods for creating and querying MBeans and the methods for invoking and manipulating MBean operations and attributes.
The agent level also consists of a set of agent services. Four such services are defined by the JMX specification—M-Let service, Timer service, Monitoring service, and Relation service. All of these standard agent services are implemented as MBeans themselves. This allows parts of the agent level to become manageable as well.
The M-Let service allows MBeans to be loaded from the network and included to the agent dynamically at runtime. The Timer service can be used as a scheduler that sends notifications to MBeans or management applications at a given date and time or at intervals. The Monitoring service includes MBeans that can act as observers of other MBeans' management attributes and send notifications on attribute changes. The Relation service allows associations to be created between MBeans and maintains the consistency of created relations. All of the four aforementioned standard services are mandatory, so you can expect to find them in all compliant JMX agent implementations (see Figure 2.2).
Figure 2.2. Agent services are specified as MBeans, which allows them to be managed from outside the agent's JVM.
In addition to the potential agent service MBeans, the agent, in most cases, is accompanied by at least one JMX connector or protocol adaptor. The connectors and protocol adaptors are part of the distributed service level discussed in the “Distributed Services Level” section later in this chapter. In practice, all JMX implementations provide at least one connector or protocol adaptor that can be registered to the agent as an MBean, thus adding the remote access possibilities to the agent.
The MBean server and standard agent services are discussed in Chapter 6, “MBean Server,” and Chapter 7, “Standard Agent Services.”
The management applications are decoupled from the managed resources by introducing object names references that represent registered MBeans in the agent. The management applications reference the MBeans by passing an object name reference to the agent with each operation. The MBean server that contains the registry of the MBeans will then look up the corresponding MBean Java reference from its internal repository and invoke the corresponding operation or attribute on the MBean, as shown in Figure 2.3.
Because the invocation is generic and not typed to a specific Java interface, there is no need to redistribute new Java classes when the management interface evolves. In the case of a large graph of components with dependencies to the services provided by other components, the changes occurring due to maintenance will have a much less widespread effect on the system. Notice, however, that this requires you to give up the type checking provided by the Java compiler. You should carefully consider when and where to apply the JMX invocation semantics. JMX allows a lot of flexibility from decoupling the managed resource and introducing the detyped invocation, but in doing so, you nullify some of the assets of the compile time type checking.
The 1.0 version of the JMX specification does not address the distribution of the JMX architecture. However, a brief overview of the distributed services level is given and is described in this section.
As was mentioned previously in the “Agent Level” section, the MBean server in the agent level does not implement remote access methods. The remoteness in the agent is achieved by configuring the JMX agent with one or more JMX connector or protocol adaptor MBeans. The connectors and protocol adaptors allow the management applications to access a remote JMX agent via specific protocols. This allows the management applications from different JVMs to invoke management operations on the MBean server, get or set management attributes, instantiate and register new MBeans, and register and receive notifications from the managed resources.
JMX connectors are split into two different components. On the server side, the agent registers a connector server that is able to receive remote method invocations from the management client. On the client side, the connector provides an object that implements a remote view to the MBean server that the client can use to transparently invoke an operation on a remote MBean server. Both the connector client and server are specific to a certain protocol. However, the management client can switch between different connector implementations because the different implementations should ideally implement the same remote interface to the MBean server. What the remote MBean server interface will be like exactly is determined by the second phase of the JMX specification.
Protocol adaptors adapt the operations of the MBean server into a representation of a given protocol or possibly into a different information model altogether, such as the SNMP Management Information Base (MIB) or DMTF Common Information Model (CIM) models. The management applications that connect to protocol adaptors are typically legacy management solutions or non-Java management tools interoperating with the JMX-based management systems.
Connectors and protocol adaptors are discussed in more detail in Chapter 9, “Connectors and Protocol Adaptors,” and Chapter 10, “JMX Distribution Layer with J2EE Services.”
The JMX architecture divides the management system implementation into three separate levels. The instrumentation level defines the mechanisms for creating manageable resources with as little impact to the development effort as possible. The instrumentation level is also generic enough to enable the management of applications, software components, services, and devices.
The agent level decouples the management applications from the resources. The MBean server is the core component of the agent level—a lightweight invocation bus between the management clients and the resource. The agent level can be configured dynamically to meet the needs of the management system by registering agent services to the MBean server. These services benefit from the instrumentation level, adding manageability to the agent level as well.
The distributed services level defines how management clients can connect to the agent and how agent-to-agent communication is implemented. The MBean server itself is not accessible through any remote invocation mechanism; it needs at least one connector or protocol adaptor registered to it for remote manageability. Remember that the distributed services level is not fully defined in the first phase of the JMX specification.