Ru-Brd

Chapter 1. Management Concepts

The term management is grossly overused in the computer industry. It is often the responsibility of a management system to take care of installation and configuration of a resource into a computer system. After a resource is installed, the management system should be able to start it, monitor it to be sure it is performing well, change its behavior through reconfiguration or operations, and stop it. The first thing this book is going to do is define management and the terms to describe management, and then identify the aspects of management that are addressed by Java Management Extensions (JMX)[1].

This chapter gives a short history of management systems and an overview of management architectures and technologies. Building on this basis, we will discuss the management lifecycle, resulting management disciplines, management data and operations, and then how all of these things are combined into management applications and systems.

Most of this chapter is not specific to JMX, and if you have a background in management and management technologies, you may choose to move on to Chapter 2 (Introduction to JMX). If you are new to management, having a basic understanding of management technology will help you understand the terminology used in this book, in the JMX specification, and by management system vendors. It will also give you the background you may need to develop or integrate with a management system.

Resources use JMX to make themselves manageable by a management system. JMX is an isolation and mediation layer between manageable resources and management systems. Why do we need this decoupling of the manager and the managed? A quick look at the history of management systems and technologies will make clear how we came to need JMX for the Java platform.
    Ru-Brd


1.1 Progress of Management

1.1.1 Why Invest in Management?

The basic motivation for corporations to invest in enterprise management systems is growth. This growth creates pain points that can be eased by network and systems management. Some of the more c/span>scenarios that cause pain:

  • When the IT resources become too numerous for computer operations staff to track with internally developed tools.

  • When the IT resources become too distributed to control from a single systems console.

  • When the IT resources are of diverse types causing console proliferation in the operations center, which cannot be staffed.

  • When the IT resources need to ensure that they are highly available.

All of these>scenarios result in workloads that ultimately overwhelm operations staff, like the poor fellow in Figure 1.1, causing stress and decreasing their ability to do their job of keeping the IT infrastructure available.

Figure 1.1. Harried Operators Can't Possibly Keep Up

As an example, these pain points are all felt by the leading-edge corporations building business-to-customer and business-to-business applications, also known as e-business, over the Internet. These applications are distributed not only geographically, but also across corporations. Each partner may be running his side on different platforms, servers, and networks. Each partner can manage only part of the application. Each partner may be using several consoles to manage the network, server, middleware, and application. And finally, these applications must be available 24 hours a day, 7 days a week, or else both partners may lose revenue by the minute.

1.1.2 The Natural Evolution of Management

The first businesses invested in computer systems to make themselves more c/spetitive. These first systems were expensive, to say the least. In order to maximize the return on their investment, corporations had to make sure that all of the mainframe's resources were in use around the clock. This meant that these systems had to be highly available. At first, because a corporation had only a few such systems, a computer operations and administration staff were able to monitor and operate them with sufficient efficiency.

Then, as the number of mainframes in use by a single corporation increased, the systems also became more c/splex. It became difficult for the staff to efficiently distribute the work and monitor the systems. The mainframes needed management systems in order to be highly available and efficiently used. The requirements of highly available systems resulted in management systems that were tightly coupled with the target operating systems.

These management systems were responsible for providing interfaces and status on every detail of the system's lifecycle. The systems monitored themselves and notified operators when they required intervention. They provided operators ways to configure the system before and during execution, to operate the systems during execution, to monitor the status of the system, and to recover from failures. The operations staff was responsible for starting the system, managing the system's workload and throughput, backing up the system, stopping the system, and maintaining the system. Because the number of mainframes deployed within a company was still fairly small, having one management system per mainframe and an operations staff to monitor it was a reasonable way to provide a highly available, efficiently used system.

Two forces upset this short-lived balance. Large enterprises began deploying large numbers of mainframes that were dispersed across the company's locations. At the same time, applications began to emerge that could be used by many employees simultaneously. Inexpensive 3270[2] terminals were deployed to "bring the computer to the user." Networks were created to connect mainframes to each other and their far-flung users. Operations staffs were now responsible for monitoring and managing the network along with the systems.

The volume and distribution of the systems to be managed stressed operations staff. Many companies split the operations staff's responsibilities and organization between network operations and system operations. The resulting network control centers (NCCs) and operations control centers (OCCs) became distinct organizationally and geographically. Nonetheless, in the mid-1980s it became obvious that although all of the management consoles necessary to manage the c/splexes might fit within a large computer operations center, the number of human operators required to interact with these consoles could not fit into that same room. Likewise, the sheer volume of systems, networks, and applications to be monitored constantly by the operators guaranteed that problems would be missed and availability would be compromised. The split into NCC and OCC often made finding the root cause of a service outage an exercise in finger-pointing (see Figure 1.2), which merely exacerbated the frequency and length of the outages.

Figure 1.2. Problem Analysis Triggers Finger-Pointing

In answer to the need for more reliable management with fewer operators, new enterprise systems management products were developed by companies like IBM,[3] Candle,[4] and Computer Associates.[5] These products were written to manage a particular operating system or network, but they were not as tightly coupled as the original management systems. At the same time, as the networks grew larger and spanned greater distances, the demand for network management products rose sharply.

Up to this point, enterprise computing systems were fairly homogeneous. A single vendor's hardware, operating system, and networking hardware would be deployed and managed by a single management system. The introduction of UNIX[6]-based systems from Sun Microsystems[7] and Hewlett-Packard[8] allowed affordable alternatives to IBM's expensive mainframes. IBM introduced its own line of UNIX systems to c/spete. Smaller businesses could now afford to use computing to make business more efficient. Likewise, smaller branches and independent departments of large enterprises could afford to own and operate their own computers.

This adoption of computing by "grassroots" businesses that did not have dedicated, professional IT staff caused management applications to focus on ease of use. The results were new, non-management-oriented, improvements:

  • User interfaces. Graphical, more intuitive user interfaces that were easier to use for the non-IT professional, who had another real job to do

  • Automation. Automated recovery by the management system of a failed or badly performing resource

  • Recommendation. Problem determination and correction recommendations that were made available to users within the management system

  • Administration. Ease of installation, administration, and maintenance of the management system itself

The isolated departmental computer systems didn't stay isolated for very long. Within enterprises it became necessary to connect these systems to each other and the mainframes that were the backbone of the enterprise. This connection made networks a critical aspect of the IT infrastructure to be managed. Not only were there more systems to be managed, but these were simple systems and not always designed and built to be manageable. Now the enterprise IT staffs were facing the challenge of managing large volumes of systems using many different hardware platforms, operating systems, and network technologies. This variety exponentially increased the c/splexity of keeping the systems available, highly utilized, connected, and with reasonable response time.

The advent of TCP/IP[9] networking made connecting large numbers of these disparate systems and their clients much easier. This new ease of connection triggered the development and deployment of distributed computing environments. Businesses began deploying applications in these distributed computing environments. Applications were no longer focused on one system, but across many systems. They were also no longer dependent on one well-managed system, but a whole slew of reasonably managed systems and the network between them. Applications in this environment, as well as the distributed-computing environments across which they executed, became much more c/splex. It was absolutely critical that this new type of extremely c/splex environment be managed to ensure high availability and utilization.

Operations staffs now had to learn to manage many different types of systems. This diversity meant that there was a desperate need for external management systems that could manage many different systems from many different vendors. These managers not only needed to do what their predecessors did—start, stop, monitor, and control the systems and network—but they had the added requirement of normalizing all of these disparate systems so that operations staff were protected from the incessant learning curve. Tivoli Systems,[10] Computer Associates, and BMC Software[11] are a few of the companies that have stepped up to supply management products for these challenges.


1.2 Management Architectures

Let's look now at the architectures of the management systems that were successful during this history.

The initial management systems were tightly coupled with the operating systems and resources to be managed. Typically, the resource to manage was running on the same host as the management system. In such cases the resources to be managed interacted directly with the management system. Later, management systems were developed by vendors that had not developed the operating system. These vendors had to support the management of a variety of resources that were not on the same host as the management system.

Management architectures consist of four parts:

  1. Organizational model. The organizational model defines the entities and roles involved in the architecture and their composition. In this section we will discuss the manager-agent model, which contains the roles of managed resource, agent, subagent, midlevel manager, and management system.

  2. Information model. The information model defines the structure of the management information so that the different entities can understand the management interfaces exposed by instrumentation to enable manageability.

  3. Communication model. The communication model defines the operations and protocol for accessing the information model.

  4. Functional model. The functional model defines generic management services that can be used to manage any resource.

Most management systems today use variations of a manager-agent management architecture. Let's look at the details of this particular architecture. We will then look at some management standards and the parts of this architecture that they support. As Figure 1.3 shows, this architecture always contains the managed resource, agent, and management system roles. Subagent and midlevel manager are often seen as well.

Figure 1.3. Manager-Agent Architecture

Sections 1.2.1 through 1.2.5 examine the details of each role in the manager-agent architecture.

1.2.1 Managed Resource

The computer system, network, or application component that needs to be managed is the managed resource. Not all resources in an IT environment need to be managed. Some groups of resources are managed as a functional unit rather than individually. Looking specifically at Java[12] technology, managed resources can be stand-alone applications, client-server applications, and Web applications. The components of these applications can be managed resources as well. Such components may include Java Virtual Machines (JVMs), containers, servlets, and Enterprise JavaBeans (EJBs) on the server, or browsers and containers on the client.

The managed resource is responsible for exposing appropriate management data for use by a management system mapped into the information model supported by that management system. At a minimum, the managed resource should expose a description of itself, its configuration data, and some performance metrics and status indicators that reflect its health.

The managed resource is also responsible for interacting with the management system via its agent using the communication model, operations, and protocol that the management system and its agent support. Such interactions include responding to requests from and sending unsolicited events to the management agent. Requests from agents may include getting data, changing configurations, or executing operations. The resource determines which requests it will support and to what degree these requests are supported. The managed resource should also recognize internal errors and log them or notify the management system. The management patterns discussed later in this chapter illustrate c/span types of support that managed resources can provide.

1.2.2 Agent

The management agent is provided by a management system and supports the communication model and information model of the management system. The agent communicates with both the management system and the managed resources. It is usually running on the same host as a daemon[13] or in the same process as the resource it is managing. The agent may support one or more managed resources. Agents embedded in a resource can support only that instance of the resource.

The agent sends data and events from the resource to the management system. It also relays data and command requests from the management system to the resource, gathers the responses, and returns them to the management system. The agent usually provides a programming interface, which may expose or wrap the communication model for the managed resource to use to communicate with it. Some management agents require that the managed resource implement a particular programming interface that the agent invokes to have a request honored.

Standards bodies have specified some standard management architectures that define information models and communication models used for the creating agents in the manager-agent architecture. The three most c/span are the Management Information Bases (MIBs) and SNMP,[14] Managed Object Format (MOF) and CMIP,[15] and Common Information Model (CIM) and Web-Based Enterprise Management (WBEM)[16] specifications. Some enterprise management systems, such as those from Tivoli and Computer Associates, depend on their own, internal proprietary agent infrastructures.

1.2.3 Subagent

Management architectures in which one agent must support many managed resources use subagents. The subagent is tightly coupled with the resource. Sometimes, it may actually be embedded within the resource. The subagent registers its presence and availability to the agent and then communicates between the resource and the agent. The subagent typically provides two programming interfaces—one to interact with the resource, and one to interact with the agent. The subagent may transform the managed resource's data from its native format and interfaces to the information model expected by the agent and management system.

It is usually the responsibility of the resource to register its subagent with the agent. The IETF has Request for Comments (RFC) documents for three subagents for SNMP, SMUX,[17] DPI,[18] and AgentX,[19] although none of these are official standards.

1.2.4 Midlevel Manager

The first manager-agent architectures had problems handling the massive numbers of managed resources that could be reporting to a single management system. This became a pain point for network managers in large enterprises using SNMP. To increase their scalability, they needed to reduce the amount of incoming data and events, as well as the number of systems they had to poll directly for availability. To acc/splish this they introduced intermediate systems called midlevel managers (MLMs) into their architectures.

MLMs interact with management systems and a set, or domain, of agents and the management system. MLMs are responsible for aggregating and filtering the information from the managed resource and forwarding pertinent or summary information to the management system. They also poll the managed resources in their domain for availability and forward exceptions to the management system. MLMs increase the quality of information while reducing the rate and quantity of incoming messages that the management systems must handle.

The domaining aspect of architectures using MLMs allows resources to be managed as logical groups acc/rding to physical characteristics, like location or type, or by business characteristics, like division or business application. Sometimes architectures that use midlevel managers are called hierarchical management architectures or cascaded agent architectures.

1.2.5 Management System

The management system supports the information model and communication model—that is, operations and protocols—of the manager-agent management architecture. The management system may range widely in the amount of functionality it provides. Regardless of the comprehensiveness of that functionality, the management system interacts with the agents to receive and gather information about the managed resources. The management system uses the information to acc/splish some of its purpose. This purpose can include all or some of the management applications described in Section 1.8. Management system–initiated requests to the managed resource go through the agent as well.

The management system can be a sophisticated enterprise manager that manages all the distributed, disparate, critical resources, like those available from Tivoli or Computer Associates. The management system may be a domain-specific management system (tightly or loosely coupled) designed to fully manage a particular resource, such as IBM's WebSphere Administration Console.[20] Another c/span type of management system is the resource-specific management system designed to manage a business system like banking, acc/unting, or customer management.

The management system is responsible for providing the infrastructure and user interfaces to manage the resources. A typical management system receives events from agents, displays them to operators, and takes any defined automated actions. The management system initiates a request to agents to control the resource. It requests data from the agent (which then requests it from the resource) for polling, monitoring, identifying trends, or determining problems. Advanced management systems that use pervasive standard management technologies, like SNMP, may also automatically discover resources in order to reduce management system configuration requirements and produce accurate topology and inventory information.

Management systems generally allow their resource management services to be customized. Examples of customizable features include commands, available statistics, threshold values used to indicate problems, automated actions, and operational policies. With more sophisticated management applications, service-level agreements and business system contexts can be defined as well. Let's take a look at the proprietary and standard management technologies that have developed and how they support the roles in this architecture.


1.10 General References

Farrell, J., and H. Kreger, "Web Services Management Approaches," IBM Systems Journal 41:2 (June 2002), http://www.research.ibm.com/journal/sj/412/farrell.pdf.

Kreger, H., "Java Management Extensions for Application Management," IBM Systems Journal 40:1 (March 2001), http://www.research.ibm.com/journal/sj/401/kreger.pdf.


Notes

  1. Source: "Java Management Extensions (JMX) Specification," JSR 3, http://www.jcp.org/jsr/detail/3.jsp, which was led by Sun Microsystems to create a management API for Java resources.

  2. 3270 is the model of a line of user terminals made by IBM Corporation, Armonk, NY (http://www.ibm.com).

  3. IBM Corporation, Armonk, NY (http://www.ibm.com).

  4. Candle Corporation, 201 N. Douglas St., El Segundo, CA 90245 (http://www.candle.com).

  5. Computer Associates International, Inc., One Computer Associates Plaza, Islandia, NY 11749 (http://www.cai.com).

  6. For information about UNIX, see The Open Group's site at http://www.opengroup.org.

  7. Solaris is Sun Microsystems' UNIX-based operating system. More information is available at http://www.sun.com/solaris.

  8. Hewlett-Packard's UNIX-based operating system is called HP-UX. More information is available at http://www.hp.com/products1/unix/operating.

  9. TCP/IP (Transmission Control Protocol/Internet Protocol) is an Internet protocol that has been defined as a standard by the Internet Engineering Task Force. Additional information is available at http://www.ietf.org.

  10. Tivoli Systems Inc., 9442 Capital of Texas Highway North, Arboretum Plaza One, Austin, TX 78759 (http://www.tivoli.com). Tivoli is a trademark of Tivoli Systems in the United States, other countries, or both.

  11. BMC Software, Inc., 2101 City West Blvd., Houston, TX 77042-2827 (http://www.bmc.com).

  12. Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc., in the United States and other countries.

  13. A daemon on a system is a long-running system process that is executing a program.

  14. SNMP stands for Simple Network Management Protocol, which is an IETF standard. More information on SNMP is available at http://www.ietf.org.

  15. CMIP stands for Common Management Information Protocol and is usually referred to in conjunction with CMIS (Common Management Information Services). This management standard was defined by OSI (Open Systems Interconnection) as an ISO (International Standards Organization) standard: ISO 9595/2 and 9596/2 (http://www.iso.ch). More information on CMIP/CMIS can be found at http://www.iso.ch.

  16. CIM/WBEM stands for Common Information Model/Web-Based Enterprise Management. It is defined by the Distributed Management Task Force (DMTF). More information is available at http://www.dmtf.org.

  17. SMUX stands for SNMP Multiplexing Protocol (IETF RFC 1227, http://www.ietf.org/rfc/rfc1227.txt?number=1227) and is used to allow an application to communicate with an SNMP agent for the purposes of satisfying a portion of the MIB. SMUX tends to predominate in UNIX systems.

  18. The Distributed Program Interface (DPI) is designed for extending SNMP agents. It is predominant in IBM systems. Source: G. Carpenter and B. Wijnen, "SNMP-DPI: Simple Network Management Protocol Distributed Program Interface," RFC 1228 (May 1991), http://www.ietf.org/rfc/rfc1228.txt?number=1228.

  19. AgentX is a standard SNMP agent-to-subagent protocol, "Extensible SNMP Agent" specification from the IETF. Source: M. Daniele, B. Wijnen, M. Ellison, and D. Franciso (Eds.), "Agent Extensibility (AgentX) Protocol Version 1," RFC 2741 (January 2000), http://www.ietf.org/rfc/rfc2741.txt?number2741.

  20. Information on IBM's WebSphere Administration Console is available at http://www.ibm.com/software/webservers/appserv. WebSphere is a trademark of IBM in the United States.

  21. Information on IBM's System/390 series is available at http://www.s390.ibm.com. System/390 is a registered trademark of IBM in the United States.

  22. Systems Management Server (SMS) is Microsoft's workstation management application. More information is available at http://www.microsoft.com/smsmgmt/default.asp?RLD=263. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

  23. See note 14.

  24. More information is available at http://www.ietf.org.

  25. Source: M. Rose and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-Based Internets," RFC 1065 (August 1988), http://www.ietf.org/rfc/rfc1065.txt?number=1065.

  26. Source: M. Rose and K. McCloghrie, "Management Information Base for Network Management of TCP/IP-Based Internets," RFC 1066 (August 1988), http://www.ietf.org/rfc/rfc1066.txt?number=1066.

  27. More information about Hewlett-Packard's OpenView is available at http://www.openview.hp.com?qt=OpenView, or from Hewlett-Packard, 3000 Hanover St., Palo Alto, CA 94304-1185.

  28. Information about Tivoli NetView is available at http://www.tivoli.com/products/index/netview.

  29. See note 15.

  30. The URL for the International Standards Organization (ISO) is http://www.iso.ch.

  31. OSI/TMN stands for Open System Interconnection/Telecommunication Management Network. OSI was defined as an ISO (International Standards Organization) standard: ISO ISO/IEC DIS 10165-1,2,3,4, 9595/2 and 9596/2 (http://www.iso.org).

  32. Groupe Bull was the original company name for the representative. This company is now referred to as "Evidian, A Groupe Bull Company" (http://www.evidian.com).

  33. The Distributed Management Task Force (DMTF) is a standards body that is responsible for DMI, CIM, and WBEM management standards. More information is available at http://www.dmtf.org.

  34. See note 16.

  35. See note 22.

  36. WBEMsource, at http://www.wbemsource.org, is a group of open-source WBEM implementations sponsored by The Open Group. Implementations are available in Java and C++.

  37. Pegasus is The Open Group's C++ implementation of the DMTF's WBEM and CIM operations specifications, and a CIMOM, for accessing CIM data through HTTP (http://www.opengroup.org/management, http://www.openpegasus.org).

  38. JSR 48, "WBEM Services Specification," is Sun's Java implementation of the DMTF's WBEM and CIM operations specifications for accessing CIM data through HTTP. See http://www.jcp.org/jsr/detail/48.jsp.

  39. JDMK stands for Java Dynamic Management Kit. JDMK 4.0 is available from Sun Microsystems, Inc., 901 San Antonio Rd., Palo Alto, CA 94303, http://java.sun.com/products/jdmk.

  40. TMX4J is an implementation of the JMX specifiation from Tivoli Systems and is available for free on IBM's alphaWorks Web site: http://alphaworks.ibm.com.

  41. Information about AIC is available at http://www.opengroup.org/management/aic.htm.

  42. The Application Response Measurement (ARM) standard was developed by The Open Group, http://www.opengroup.org/management/arm.htm.

  43. You can find more information about IBM WebSphere 4.0 at http://www.ibm.com/websphere. WebSphere is a trademark of IBM in the United States.

  44. Tivoli's Application Management Specification is used to define the characteristics of a managed application.

  45. MOF file stands for Managed Object Format file. This format is used to describe CIM information and is defined by the DMTF in the CIM specification. More information is available at http://www.dmtf.org/standards/cim_schema_v23.php.

  46. Source: J. Farrell and H. Kreger, "Web Services Management Approaches," IBM Systems Journal 41: 2 (March 2002).

  47. Marimba, Inc., 440 Clyde Ave., Mountain View, CA 94043. Additional information is available at http://www.marimba.com. Marimba is a trademark of Marimba, Inc., in the United States and other countries.

  48. TCP stands for Transmission Control Protocol, UDP for User Datagram Protocol, and ICMP for Internet Control Message Protocol.

  49. S. Waldbusser and P. Grillo. "Host Resources MIB," RFC 2790 ( March 2000), http://www.ietf.org/rfc/rfc2790.txt?number=2790.


JMX in Products

JMX has been implemented with value-added function and sold as a separate product. JMX has also been embedded in numerous products to provide manageability infrastructure. This appendix gives an overview of the known products supporting JMX at the time of this writing. The appendix is divided into three sections: JMX Agent Implementations, JMX Managers, and JMX-Enabled Products. There is no doubt that there are products that we have missed; this is not intended to be an exhaustive listing.

One note on terminology: Vendors who implement the JMX agent specification must purchase and pass the Technology Compatibility Kit (TCK)[1] in order to claim JMX compliance. The TCK must be purchased from Sun, and the price can be substantial. JMX implementations that have not passed the TCK are called JMX compatible. We have noted which implementations are compliant. If nothing explicit is stated, you can assume that the products are compatible.


A.1 JMX Agent Implementations

A.1.1 JMX 1.0 Reference Implementation from Sun Microsystems

Version 1.0 of the JMX reference implementation was released in December 2000. The reference implementation source[2] is licensed under the Sun Community Source License (SCSL). According to the Free Software Foundation (http://www.gnu.org/philosophy/license-list.html#SunCommunitySourceLicense) and numerous editorials at the time of the SCSL release, this license is not well thought of in the free-software and open-source communities. The reference implementation binary is available for free.

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 files.

A.1.2 JDMK 4.2 from Sun Microsystems

JDMK 4.2[3] was released in 2001. It is the only JMX-compliant implementation (having passed the TCK that Sun developed). You must purchase this product from Sun. It contains adapters for HTTP, RMI, and SNMP. The SNMP adapter works only for MBeans generated from SNMP MIBs by JDMK's MIBGen tool. The adapter does not support the "random" MBean. The SNMP adapter supports SNMP versions 1 and 2. JDMK provides a remote-manager component that includes a proxy for the MBeanServer, and proxies for the MBeans, to make the development of JMX managers easier. It also provides a JMX manager and tools to help define and manage the MBeans. For more information, see http://www.sun.com/software/java-dynamic.

A.1.3 TMX4J 1.0 from Tivoli Systems

TMX4J 1.0[4] was released in February 2001. It is a cleanroom implementation of the JMX specification, and it is JMX compatible, not compliant. It is available from IBM's alphaWorks Web site at http://alphaworks.ibm.comtech/TMX4J. The licensing on this software is the standard alphaWorks trial license. However, alphaWorks is now making technologies available for release by products on a per-technology basis. More information is available at http://www.alphaworks.ibm.com/license. TMX4J contains an HTTP and RMI adapter, and support for a logging facility with JLog.[5] It also comes with a very nice tutorial. IBM's products that support JMX use TMX4J, including WebSphere 5.0,[6] WebSphere Voice Server,[7] WebSphere Edge Server,[8] WebSphere Business Integrator,[9] WebSphere Business Components Composer,[10] and Tivoli Web Component Manager.[11]

A.1.4 AdventNet Agent Toolkit Java/JMX Edition[12]

AdventNet[13] was the first vendor to ship a product with JMX support. Its management agent toolkit supported the JMX 0.8 version before the JMX specification was final. The most recent version has passed the JMX TCK and is now fully JMX compliant. You must purchase this product from AdventNet. This toolkit includes a rapid prototyping and development tool for building JMX agents, and it includes adapters for SNMP, HTML, RMI, HTTP, CORBA, and TL1 (Transaction Language 1). It also supports distributed JMX agents in a gateway or cascading configuration, as well as the building of stand-alone SNMP and TL1 agents in Java. You can get more information at http://www.adventnet.com/products/manageengine/index.html. Other AdventNet products that use JMX are ManageEngine and Web NMS.

A.1.5 AdventNet ManageEngine

AdventNet ManageEngine is a graphical development environment that helps developers expose business- or application-specific management information even after an application is developed and deployed. JMS (Java Message Service) and Web service JMX adapters are also being supported to integrate the management infrastructure with the existing middleware infrastructure. For more information, see http://www.adventnet.com/products/manageengine/index.html.

A.1.6 MX4J

MX4J[14] is an open-source implementation release of the JMX 1.0 specification that is JMX compatible because it has not passed the JMX TCK. This is understandable, given the current licensing arrangements for the TCK. MX4J uses the Apache[15] licensing model. It provides an HTTP, RMI-over-JRMP,[16] and RMI-over-IIOP adapter. It also includes a tool that allows you to generate your MBean interface via XDoclet. Another interesting extension of MX4J is dynamic proxy support for MBeans so that the calls to the MBeans in your programs are more intuitive. The MX4J implementation has a logging facility that makes it fairly easy to redirect the data to another logging facility, such as log4j.[17] MX4J provides some additional service MBeans: a naming MBean that wraps the RMI registry, a mailer MBean that sends e-mail, and a JythonRunner MBean that runs Jython scripts. You can find more information at http://mx4j.sourceforge.net.


A.2 JMX Managers

A.2.1 Tivoli Web Component Manager

Tivoli Web Component Manager provides performance and availability monitoring of Web applications, including Web servers, Web application servers, and JMX-enabled applications. It also provides a framework to define and execute automated responses to problems. When paired with Tivoli Web Services Manager[18] and Tivoli Web Services Analyzer,[19] which measure and report on the performance and availability of e-business infrastructure from the end user's perspective, it can help you manage performance and availability from the end user through the back-end application server. More information is available from http://www.tivoli.com/products/index/web_component_mgr.

A.2.2 Dirig Software

The Dirig agent with Fenway Management Extensions (FMX) provides management support capabilities for any third-party or custom Java application that exposes its management information via JMX. FMX gives enterprises and service providers the ability to report on, create thresholds for, and take corrective actions on any exposed attribute to maintain performance and availability of JMX-enabled applications across multiplatform Web server environments. You can find more information at http://www.dirig.com.

A.2.3 AdventNet Middleware Manager

AdventNet Middleware Manager manages JMX-enabled applications deployed on J2EE servers like BEA WebLogic Server. It adds JMX instrumentation for application-level information, in addition to using the JMX instrumentation available for the server infrastructure. It provides a unified view of a network of servers, and it monitors the server and application components. It reports on each segment of an end-to-end Web transaction so that performance and availability issues are quickly isolated. You can find more information at http://www.adventnet.com/products/middleware.

A.2.4 AdventNet Web NMS

AdventNet Web NMS provides an open, scalable, carrier-grade management infrastructure platform, with a suite of J2EE- and JMS-based cross-platform development framework, tools, modules, and APIs, as well as prepackaged applications. Web NMS uses Java, CORBA, and other standards to deliver a management solution that communicates with managed systems (network elements, systems, and applications). It supports SNMP, TL1, XML, CORBA, and Telnet/CLI[20] protocols. To integrate with OSS and other decision support systems, Web NMS supports interfaces like CORBA, RMI, JMX, SNMP, TL1, and HTTP. You can find more information at http://www.adventnet.com/products/webnms.

A.2.5 Vigor Soft hawkEye[21]

Vigor Soft's hawkEye enterprise product is a JMX-based management tool. For more information, see http://www.vigorsoft.com.


A.3 JMX-Enabled Products

The J2EE application vendors have been adopting and implementing versions of their products with JMX support for over a year now. The following products currently use JMX for their own management and/or may be managed by JMX-based managers.

A.3.1 IBM WebSphere 5.0

WebSphere 5.0 supports both JMX and JSR 77, which defines the J2EE management model. Through JMX you have access to WebSphere's configuration and performance metrics. You can find more information at http://www.ibm.com/websphere. WebSphere is a trademark of IBM in the United States.

A.3.2 IBM Web Services Tool Kit 3.1

The IBM Web Services Tool Kit is a leading-edge implementation and showcase for Web service technology. It is available from http://www.alphaworks.ibm.com/tech/webservicestoolkit.

A.3.3 IBM WebSphere Voice Server

IBM WebSphere Voice Server allows delivery of voice-enabled Internet applications to wireline and wireless devices using existing Web infrastructures. You can find more information at http://www-3.ibm.com/software/speech/enterprise/ep_1.html. WebSphere is a trademark of IBM in the United States.

A.3.4 IBM WebSphere Business Components Composer

IBM WebSphere Business Components Composer consists of easy-to-use software implementation packages. You can find more information at http://www-3.ibm.com/software/webservers/components. WebSphere is a trademark of IBM in the United States.

A.3.5 BEA Systems WebLogic Server 7.0[22]

BEA WebLogic Server 7.0 provides JMX-based management and manageability. BEA's JMX support is JMX compliant. More information is available at http://www.bea.com/products/weblogic/server/index.shtml.

A.3.6 IONA iPortal[23]

IPortal by IONA is IONA's J2EE application server, which supports JMX. More information is available at http://www.iona.com.

A.3.7 IONA Technologies PLC: Orbix E2A XMLBus Edition 5.3

IONA's XMLBus Edition (part of the Orbix E2A Web Services Integration Platform family) is an integration platform for the integration of heterogeneous applications built with .NET, Java, J2EE, J2ME, and CORBA. This platform provides rapid development tools, deployment infrastructure, and management for deployed Web services using JMX for instrumentation and management. More information is available at http://www.iona.com/products/webserv-xmlbus.htm.

A.3.8 Hewlett-Packard OpenView

OpenView is a network management system, storage management system, and application management system (including Web services) that now supports JMX plug-ins. For more information, see http://www.hp.com.

A.3.9 Hewlett-Packard Core Services Framework

HP Core Services Framework (CSF) is a framework (specification) and the underlying infrastructure that provides a core set of services such as naming and directory services, management services, logging services, and security services. As a Java standards–based framework, HP CSF supports all the resource managers and services that could be required by Java developers, including JMX. For more information, see http://www.hp.com.

A.3.10 JBoss

JBoss is an open-source J2EE application server that is built on a JMX microkernel. It supports HTTP Server, EJB, Java Connector Architecture, JMX, and CMP (Container Managed Persistence). It is free and distributed under the LGPL. For more information, see http://www.jboss.org.

A.3.11 Sonic Software SonicXQ[24]

Sonic Software's JMX-compliant SonicXQ by Sonic Software is an Enterprise Service Bus (ESB) that delivers integration through Web services and JCA. SonicXQ also delivers performance, scalability, and manageability. For more information, see http://www.sonicsoftware.com/products/sonicxq.htm.

A.3.12 Pramati Server from Pramati Technologies[25]

Pramati Server 3.0 is a J2EE application server that comes with a management console that supports management of J2EE servers and applications. It provides an MBean viewer and the ability to invoke MBean operations. More information is available at http://www.pramati.com.

A.3.13 Sybase EAServer 4.0

EAServer is an application server that supports all component models, including J2EE, COM, CORBA, C/C++, and PowerBuilder. For more information, see http://www.sybase.com/products/applicationservers/easerver.

A.3.14 Sun Microsystems: Sun ONE Application Server

The Sun ONE application server (formerly iPlanet application server) provides the foundation for delivering application services (J2EE 1.3) and Web services. It integrates an application development environment. It forms the foundation for the Sun ONE services delivery platform. More information is available at http://www.sun.com.

A.3.15 Sun Microsystems: Sun ONE Portal Server

The Sun ONE Portal Server is an identity-enabled portal solution for managing and administering users, policy, and provisioning services, including single sign-on, delegated administration, and Web services. More information is available at http://www.sun.com.

A.3.16 Compiere Open Source ERP & CRM

Compiere Open Source ERP & CRM is the open-source ERP and CRM business solution for the Small-Medium Enterprise (SME) in distribution and service. Compiere provides support for managing inventory, point of sale (POS), and accounting needs. The Compiere server is JMX compliant. All server services for the accounting server, request server, and utility server are implemented as dynamic MBeans. You can manage the MBeans locally and remotely, or integrate with SNMP or CIM/WBEM managers. The Compiere server is based on the JMX reference implementation. For more information, see http://www.compiere.com.

The following products are also JMX enabled:

  • Macromedia: Flash MX, http://www.macromedia.com

  • Macromedia: JRun 4, http://www.macromedia.com

  • Cogency: Cogency Connectors, http://www.manage.com/products/connectors.html

  • Resonate Inc: Resonate Commander, http://www.resonate.com

  • SpiritSoft: SpiritWave 5.1 , http://www.spiritsoft.com

  • Wily Technology: Introscope, http://www.wilytech.com

  • XadrA: VelocityAdaptorServer, http://www.xadra.com


Ru-Brd Previous Section

Notes

  1. JMX TCK from Sun: Java Management Extensions Technology Compatibility Kit 1.0 (April 2000), Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303; available at http://java.sun.com/products/JavaManagement.

  2. Java Management Extensions Instrumentation and Agent Specification v1.0 (Final Release, April 2000), Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303; available at http://java.sun.com/products/JavaManagement.

  3. Java Dynamic Management Kit 4.2, Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303; available at http://www.sun.com/software/java-dynamic.

  4. TMX4J is Tivoli's freely available JMX-compatible JMX implementation. It is available from http://www.alphaworks.ibm.com/tech/TMX4J.

  5. log4J is the Java API for logging available from Apache. For more information see http://jakarta.apache.org/log4j/docs/index.html.

  6. WebSphere 5.0 supports both JMX and JSR 77, which defines the J2EE management model. Through JMX you have access to WebSphere's configuration and performance metrics. You can find more information at http://www.ibm.com/websphere. WebSphere is a trademark of IBM in the United States.

  7. WebSphere Voice Server allows delivery of voice-enabled Internet applications to wireline and wireless devices using existing Web infrastructures. You can find more information at http://www-3.ibm.com/software/speech/enterprise/ep_1.html. WebSphere is a trademark of IBM in the United States.

  8. WebSphere Edge Server V2.0 for Multiplatforms (Edge Server) distributes application processing to the edge of the network under centralized administrative and application control. You can find more information at http://www-3.ibm.com/software/webservers/edgeserver. WebSphere is a trademark of IBM in the United States.

  9. WebSphere Business Integrator provides a complete and consistent model for both Enterprise Application Integration (EAI) and business-to-business (B2B) integration. You can find more information at http://www-3.ibm.com/software/webservers/btobintegrator. WebSphere is a trademark of IBM in the United States.

  10. WebSphere Business Components Composer consists of easy-to-use software implementation packages. You can find more information at http://www-3.ibm.com/software/webservers/components. WebSphere is a trademark of IBM in the United States.

  11. Tivoli Web Component Manager (TWCM) is Tivoli's management application that measures the performance of the components of your e-business: operating systems, Web servers, and Web applications. You can find more information at http://www.tivoli.com/products/index/web_component_mgr/index.html.

  12. Information about AdventNet Agent Tookit Java/JMX Edition is available at http://www.adventnet.com/products/javaagent.

  13. AdventNet markets agent toolkits that support both SNMP and JMX technologies. More information is available at http://www.adventnet.com.

  14. MX4J is an open-source community for JMX specification implementations using the Apache licensing model. More information is available at http://mx4j.sourceforge.net.

  15. Apache public license information is available at http://www.apache.org.

  16. JRMP stands for Java Remote Method Protocol.

  17. IBM JLog is a Java logging API that is available at http://www.alphaworks.ibm.com/tech/loggingtoolkit4j.

  18. Tivoli Web Services Manager is Tivoli's management application that checks Web site availability and response time from the user's point of view. You can find more information at http://www.tivoli.com/products/index/web_services_mgr/index.html.

  19. Tivoli Web Services Analyzer is Tivoli's management application that helps you baseline and improve the true quality of experience Web visitors receive when accessing your site.

  20. CLI stands for Command Line Interface.

  21. Vigor Soft's hawkEye enterprise product is a JMX-based management tool. For more information, see http://www.vigorsoft.com.

  22. BEA WebLogic Server 5.0, 6.0, and now 7.0 have all provided JMX-based management and manageability. More information is available at http://www.bea.com.

  23. IPortal by IONA is IONA's J2EE Application server, which supports JMX. According to IONA, the iPortal Application Server has been incorporated into the Orbix E2A Application Server Platform as the Orbix E2A J2EE Technology Edition. More information is available at http://www.iona.com.

  24. Sonic Software's SonicXQ by Sonic Software. For more information see http://www.sonicsoftware.com/products/sonicxq.htm.

  25. Pramati Server 3.0, by Pramati Technologies, is a J2EE application server that comes with a management console that supports management of J2EE servers and applications. It provides an MBean viewer and the ability to invoke MBean operations. More information is available at http://www.pramati.com.
    Ru-Brd Previous Section