Home > Articles > Programming > Java

  • Print
  • + Share This
This chapter is from the book

2.4 History

This section presents a historical perspective on JMX, covering the precursor specifications and products, Sun's JMAPI and JDMK, the JMX JSR and current specifications, compliance levels, and a review of some of the current implementations.

2.4.1 JMAPI

Java Management API (JMAPI) was an effort led by Sun. It was intended to arrest the proliferation of management platforms by developing a standard Java management platform infrastructure. There were two parts to JMAPI:16 the Admin View Module and the Admin Runtime Module. The Admin View Module was an infrastructure to be used to build management consoles. The Admin Runtime Module was an API and infrastructure to be used to build management systems and applications. Most of the management system vendors were involved, including Tivoli and Computer Associates. An early implementation of this specification was developed and used by a few vendors. In late 1998 this work stalled. An "arms race" developed among the vendors to get their management agents on the most systems. JMAPI was not focused on helping developers make their resources manageable. But that is precisely where JMX is focused.

2.4.2 JDMK

Java Dynamic Management Kit (JDMK) 2.017 was a Sun product that was the precursor to JMX and provided the starting point for the JMX specification. Today it is Sun's product version of JMX. The JMX Reference Implementation is independently licensed and contains quite a bit of additional functionality that is not in the specification. It contains a remote JMX manager, tools to support the creation of MBeans from SNMP MIBs, and Java SNMP manager APIs.

2.4.3 JMX

Sun opened JSR 318 in December 1998 using its then brand-new Java Community Process.19 JMX's initial name was Java Management API (JMAPI) 2.0, although it had no relationship to the first JMAPI's goals, APIs, or implementation (see Section 2.4.1). The first action of the JMX Expert Group was to change the name to Java Management Extensions to eliminate confusion between JMX and JMAPI.

The expert group consisted of Sun, IBM/Tivoli, Computer Associates, Groupe Bull (Evidian),20 TIBCO,21 and Powerware.22 Eventually Borland,23 Motorola,24 BEA,25 IONA,26 Lutris,27 and JBoss28 also joined, as it became obvious that this new technology could be very relevant to J2EE application servers. The interesting thing about this expert group was its cross-industry mix. Not only were enterprise management system vendors represented, but so were telecommunications device and system vendors, as well as application server vendors. This diversity created a very important balance in interests and a willingness to focus on the needs of the Java resource developer rather than the management system.

The initial specification contribution from Sun was based on its Java Dynamic Management Kit (JDMK) 3.029 product, which was gaining some following in the telecommunications industry. Sun intended the next release of JDMK (4.0)30 to be the first JMX-compliant product.

The JMX mailing list is jmx-forum@java.sun.com, and the Web site is http://java.sun.com/products/JavaManagement. The JMX Reference Implementation and Technology Compatibility Kit (TCK) are available from Sun Microsystems through this same site.

Sun was the specification lead and is now the maintenance lead. Here are some of the JSRs that pertain to JMX:

  • JMX 1.5.31 JSR 160: "Java Management Extensions (JMX) Remoting 1.2" (http://www.jcp.org/jsr/detail/160.jsp), led by Sun Microsystems. This specification extends the JMX 1.0 specification by adding distributed capabilities to support remote JMX managers, remote MBeans, and JMX agent discovery. At the time of this writing, this expert group is actively working on a new specification that should be available in 2002.

  • JMX and CIM/WBEM.32 JSR 146: "WBEM Services: JMX Provider Protocol Adapter" (http://www.jcp.org/jsr/detail/146.jsp), led by Sun Microsystems. This specification defines how JMX instrumentation can be mapped to CIM and provides the definition of a JMX provider protocol adapter for WBEM Services. This JSR provides a bridge from JMX into WBEM though a JMX adapter. Although an expert group has formed, little progress is being made on this specification and there are currently no reliable availability dates.

  • JMX and TMN.33 JSR 71: "JMX-TMN Specification" (http://www.jcp.org/jsr/detail/071.jsp), led by Evidian. This specification specifies interoperability between the Telecommunication Management Network (TMN) standards and JMX. This JSR defines bidirectional integration between JMX and TMN. In the end, a JMX-manageable application would be manageable by a TMN man ager or agent. Likewise, a JMX manager would be able to manage a TMN environment. This JSR was withdrawn in June 2001.

  • JMX and IIOP.34 JSR 70: "IIOP Protocol Adapter for JMX Specification" (http://www.jcp.org/jsr/detail/070.jsp), led by IONA. This specification will establish an IIOP-based35 adapter for the JMX agent, to allow CORBA36 clients to access JMX agents. This specification will allow non-Java environments, such as CORBA applications, access to JMX information using IIOP. This expert group has been formed; however, when a specification and reference implementation will be available is unknown.

  • JMX and SNMP. A JSR for an adapter from JMX to SNMP agents was discussed frequently within the JMX Expert Group, but the JSR was never opened. There is quite a bit of SNMP support available in the JMX Reference Implementation, and from products such as Sun's JDMK and AdventNet.

Figure 2.2 shows how the adapters being defined by these JSRs are related to the JMX MBeanServer and the original management systems. The Mof2MBean and MIBGen tools take other definitions of management objects (for CIM and SNMP, respectively) and generate JMX MBeans to match them. The data going over the network is in the native management system's format.

Figure 2.2Figure 2.2 JSR Adapters

Other JSRs use or reference JMX as well, including the Java Integrated Networks (JAIN) JSRs and "J2EE Management" (JSR 77).37

2.4.4 The Specification and Compliance

The final Java Management Extensions (JMX) v1.0 Specification is available from http://jcp.org/aboutJava/communityprocess/final/jsr003. This specification was narrowed to define only the agent and instrumentation layers. The JMX 1.1 maintenance release specification and reference implementation are available at http://java.sun.com/products/JavaManagement. This release fixed specification ambiguities and reference implementation problems. Future versions of the specification (hopefully JMX 1.5) will address the distributed management layers.

The agent layer defines the MBeanServer and service MBeans that cooperate to implement the agent role in the manager-agent architecture. The instrumentation layer consists of the MBeans that are used by resources to expose their manageability.

The manager layer in the original JMX specification included Java APIs for communicating with agents and managers that are based on existing management technologies. These APIs do not communicate with JMX MBeanServers directly. In order for these APIs to communicate with an MBeanServer, an adapter to communicate with the native management technology would need to be loaded. For example, if you had an MBean you wanted to access using the Java SNMP manager APIs, you would communicate with an SNMP agent, which would communicate with an SNMP subagent that is also a JMX adapter, which would communicate with the MBean. This chain of communication is illustrated in Figure 2.2. The JMX Expert Group considered three Java APIs for managers, the Java API for interacting with SNMP agents, the Java API for interacting with a CIMOM using WBEM, and the Java API for interacting using TMN managers.

Some of these "manager APIs" in the original specification were spun off into separate JSRs so that they would have their own specification and reference implementation because they had no direct dependency on the JMX agent or MBeanServer. Figure 2.3 shows the relationship of these manager JSRs to the MBeanServer. The JMX Java APIs for WBEM specification and libraries became JSR 146.38 The JMX Java APIs for TMN became JSR 71.39 The JMX Java APIs for SNMP are not associated with a JSR. However, JDMK does ship the SNMP Manager Java APIs.

Figure 2.3Figure 2.3 Manager-Level API JMX JSRs

JMX compatibility is defined to be an implementation of some or all of the JMX 1.0 specification that has not passed Sun's JMX TCK test suite. JMX compliance is defined in levels. These levels are defined in terms of what parts of JMX are supported. We will cover these terms and components in depth throughout this book, so if you are new to JMX, this section will make more sense when you revisit it. Compliance at the Instrumentation Level

Resources and applications that want to be managed through JMX and claim JMX compliance must implement an MBean and provide for its registration with an MBeanServer. The application can provide any of the four types of MBeans: standard MBean, dynamic MBean, open MBean, or model MBean.

The JMX Technology Compatibility Kit (TCK) does not test for accurate compliance of MBeans. But the JMX Reference Implementation does come with an MBean verifier. Compliance at the Agent Level

Implementers of JMX agents can be JMX agent-level compliant if they implement the MBeanServer and the four required services: monitoring, timing, relation, and class loading (MLet). There is a formal compliance test Technology Compatibility Kit from Sun Microsystems that an implementation must pass to be declared compliant. If you implement the entire JMX specification and do not pass the compliance tests, you are JMX compatible. Support at the Agent Level

There is also the concept of providing JMX support at the agent level. This means that the agent supports managing resources through MBeans, but not necessarily as an MBeanServer. There is no formal qualification or test for JMX support. This level of support was specified to allow existing proprietary product agents to detect and support new management objects, MBeans, without exposing their agents as MBeanServers to adapters. Compliance at the Distributed Services Level

This level of JMX has not yet been defined. The recently opened JSR "Java Management Extensions (JMX) Remoting 1.2" (JSR 160) is considering defining this level. The distributed services level would define how JMX agents work cooperatively across a distributed network, as well as how a manager would discover and interact with groups of agents and cascaded agents. Compliance at the Management Level

JMX was intended to be an umbrella JSR and include a set of manager-side management APIs. The previous three levels describe JMX for instrumentation and management. The management APIs define Java APIs for management of other existing management technologies using Java. Currently Java APIs are being defined for SNMP, WBEM, and TMN. These Java APIs will be defined in other JSRs.

2.4.5 The Reference Implementation

Version 1.0 of the JMX Reference Implementation from Sun Microsystems was released in December 2000. The reference implementation source code40 is licensed under the Sun Community Source License (SCSL).41 The binary version of the reference implementation is available for free. The JMX Technology Compatibility Kit (TCK)42 must be purchased from Sun, and the price can be substantial. Vendors who implement the JMX agent specification must purchase and pass the TCK in order to claim JMX compliance.

JMX 1.1, a maintenance release, is available from the same Web site. For more information and access to the source or binary versions of the reference implementation, see http://java.sun.com/products/JavaManagement.

Sun also provides a Web site called the JMXperience at http://java.sun.com/products/JavaManagement/JMXperience.html, where Sun and other vendors can contribute interesting tools, MBeans, and components for JMX. Sun has contributed a remoting component that provides a remote MBeanServer for use by JMX clients (usually JMX managers) and an Mof2MBean tool that generates MBean skeletons from CIM MOF (Managed Object Format) files.

The appendix of this book lists a short summary of some of the JMX agent implementation vendors, including Sun's JDMK, Tivoli's TMX4J, AdventNet's Agent ToolKit, and MX4J. The appendix also lists JMX manager vendors, including those from Tivoli, Dirig Software, AdventNet, and Jamie. In addition, the appendix lists some of the JMX manageable products, including WebSphere, WebLogic, iPortal, JBoss, SonicXQ, hawkEye, and Pramati Server.

  • + Share This
  • 🔖 Save To Your Account