JMX is a popular new standard extension to the Java platform that enables devices, applications, and services to be managed, controlled, and monitored through modern Network Management Systems (NMS). To gain better insight into how JMX facilitates the management of software applications/services, we will attempt to monitor our ClickMeter application (developed in part 2 of this series) by using a real-life open source NMS, called OpenNMS. I have selected OpenNMS for its wide open availability and simplicity in design. You can also apply the integration techniques described with other NMS products. Before we work with OpenNMS specifics, let's look at the common design elements and operational model that most NMS products share.

Network management systems -- complex by nature

In part 1 of this series, we traced the evolution of an NMS through the history of modern networking. Due to the diversity of the network management user population (and heritage of the solution vendors), modern NMS products tend to be some of the largest and most complex software systems around. For example, a multi-national organization that manages and monitors its telecommunications network equipment through a set of distributed operation centers will have significantly different requirements from a regional business that needs to manage its virtual private network (VPN), PC assets, data communications assets, and application servers across divisions within the same state or province.

A typical NMS must manage thousands, tens of thousands, or even hundreds of thousands of endpoints (nodes). The target customers of an NMS tend to be medium or larger sized organizations. Because each of these customers may do business differently, an NMS must have a highly adaptable configuration mechanism and user interface to satisfy the diverse needs of its customers. Add to this picture the fact that many NMS solutions had earlier incarnations as proprietary blackbox control concentrator consoles -- their vendor's core business competence at some point in the past (IBM, HP, Sun, and so on) -- and you'll get a feel for the complexity of such systems. You might also then be able to justify the high cost of a typical NMS solution.

Back to top

OpenNMS: An open source NMS

OpenNMS is a one-of-a-kind software system in the open source world. It is an attempt to provide the executable and source code to a complex-yet-adaptable NMS solution -- free of charge -- to the development community. See Resources for links to detailed information, including where to download the latest version of OpenNMS. Also see the sidebar "Condensed history of OpenNMS" for a description of the origin of this system.

Because OpenNMS was born without legacy (that is, its originator is not a "blackbox" vendor), it took a rather novel design approach. OpenNMS is a "user centric" NMS, placing the typical network manager (or network management team) as its single point of focus to determine the required functionality. A few members of the initial team are network management consultants, and they put their knowledge to good use -- defining the operational model around the objects, tasks, and workflow that the typical network manager cares about. This stands in contrast to some commercial NMS products, which can often be device-, network-, or software service-centric, due to the heritage of its vendor.

Back to top

Anatomy of an NMS

Many NMS products have similar conceptual level composition, regardless of the specific domain of their application, the code heritage, or the vendor. Figure 1 illustrates this common composition.

The composition is typically three tiered. The front tier interfaces to the network(s) of devices and services being managed, the users using the system, and external systems. The middle tier contains much of the logic that provides the feature set of the NMS. The back-end tier is responsible for persisting and manipulating data.

Due to the large amount of information and the complex interrelationships that need to be tracked on a dynamic yet robust basis, an NMS inevitably deploys a commercial grade relational database management system (RDBMS) in its back-end tier.

In the first tier, the monitoring, administration, and control component typically consists of many concurrent tasks that must execute during NMS operations. It is responsible for active network discovery, polling for device outages and services, and intercepting or processing asynchronous events from devices, services, or higher level distributed agents. This component may also carry out operations driven by the configuration logic, provisioning logic, workflow executor, or other custom logic in the middle tier of the NMS.

Also in the front tier is the user interface component. An NMS may have a "fat client GUI" interface, as well as an easily customizable Web-based user interface. The reporting facility resides in this layer and can interact with the UIs to provide real-time soft-copy reports as well as batched hard-copy reports.

External interfacing components in the first tier can process notifications to users and/or external systems. This may take the form of a pager call, e-mail, phone call, or a specific event to an external management system. API and extension plugin infrastructure allows the NMS to be customized and interfaced or integrated with other systems.

The middle tier is where the logic of the NMS resides. It provides a distinct feature set and personality to the NMS. Some commonly found features include inventory or asset management, data collection and analysis, user or role management, and workflow management/execution.

Inventory (or asset) management is a major function of most NMS products. The items being tracked may vary widely from NMS to NMS, such as equipment, circuits, servers, installed software services and applications, and so on. The user interface and application logic of this component must be flexibly adaptable to the different items that may be managed.

Data collection and analysis features can provide current and historical statistics on the devices and services being managed. It may provide statistical analysis that reveals the performance of networks and subnetworks, device/service availability, and so on. This component can also interact with the workflow execution logic for handling custom workflows.

User and role management components provide different levels of access to the NMS. Most large networks are managed by one or more teams of people. Roles assigned to users can be used in the design and implementation of custom security policies, as well as custom workflow and event escalation flows.

Workflow management and execution provide for the management and automated execution of both short-duration and long-duration management tasks. Custom automated workflows are essential for adapting an NMS to the varying business requirements of different organizations.

While not every NMS will have all of these components -- and some may have other more specialized variations -- the ones mentioned here provide an adequate overview of the pieces that make up an NMS.

Back to top

OpenNMS architecture

Using Figure 1 as a reference, we can draw concrete parallels between the reference composition and OpenNMS's architecture. Figure 2 shows the components that make up OpenNMS.

In the back-end tier, OpenNMS uses PostgreSQL (see Resources) as its RDBMS. On the front tier, it uses JSP and servlet technology courtesy of Apache Jakarta Tomcat (see Resources) to provide its flexibly customizable user interface. A legacy Perl-based user interface is also available. Several administrative utilities are written in UNIX shell script and Perl. OpenNMS uses a suite of concurrent Java tasks corresponding to the monitoring, administration, and control component in Figure 1 to provide this functionality. These concurrent tasks are shown as circles in Figure 2.

OpenNMS daemons: Concurrent management tasks

OpenNMS's monitoring, control, and data collection features are handled by a set of concurrent tasks called daemons (BSD UNIX conventions). Table 1 is a compilation of these concurrent management tasks, which are also depicted in Figure 2.

Table 1. Concurrent management tasks in OpenNMS

Back to top

Extending OpenNMS

At the front tier of OpenNMS, adapting the system for a specific vertical application domain is quite straightforward. Thanks to the flexibility of JSP technology, the user interface to OpenNMS can be easily customized by Java developers. New NMS application logic can also be added readily through a combination of JSP files and/or servlet coding.

OpenNMS comes standard with robust SNMP support for managed devices/services. SNMP is the current industry de facto standard for manageable devices/services. This standard enables OpenNMS to manage a very large variety of existing devices on a TCP/IP network.

Outside of SNMP, OpenNMS can also detect and manage popular software services (FTP, file servers, database servers, and so on). It provides a suite of service-specific plugins (for protocol scanning) and monitors (for polling) to accomplish this. By creating new plugins and monitors, OpenNMS can be extended to provide detection and monitoring for any new devices or services -- including our JMX-enabled ClickMeter application.

Creating a custom capability plugin

The discovery daemon (discovery) of OpenNMS is responsible for the initial and ongoing discovery of the managed network. Once discovery discovers a node (typically through ICMP ping), it will ask the capability daemon (capsd) to determine what services that node supports. The capability daemon checks for support of services by iterating through a specified set of protocol plugins. It is quite straightforward to write a custom protocol plugin to adapt any new service to OpenNMS. The steps are:

1. Create a class that implements the org.opennms.netmgt.capsd.Plugin interface. Specifically, this interface has three methods that the plugin must implement, as listed in Table 2:
   
   Table 2. Methods of the org.opennms.netmgt.capsd.Plugin interface

   Method name and signature	Description
   String getProtocolName();	Returns the name of the protocol this plugin is created for.
   Boolean isProtocolSupported(java.nnet.InetAddress address); boolean isProtocolSupported(java.nnet.InetAddress address, java.util.Map properties);	Determines if the protocol is supported by the specified InetAddress, using the provide properties map for incoming parameters if necessary.

   
   
   
2. Create a protocol-plugin definition in the /etc/capsd-configuration.xml file. This is the file that capsd will read during startup to determine the protocol plugins to use.

We will see in detail how to code and configure an OpenNMS protocol-plugin shortly.

Creating a custom poller monitor

After OpenNMS has determined the services on a managed node, it will use the poller daemon (pollerd) to regularly poll the managed devices/services to ensure that they are operational. pollerd performs individual service polls by iterating through a specified set of poller monitor "plugins." To create a poller monitor for a new protocol, we need to:

1. Create a class that implements the org.opennms.netmgt.poller.ServiceMonitor interface. Specifically, this interface has five methods that the monitor must implement, as listed in Table 3:
   
   Table 3. Methods of the org.opennms.netmgt.poller.ServiceMonitor interface

   Method Name and Signature	Description
   void initialize(java.util.Map parameters); void initialize(org.opennms.netmgt.poller.NetworkInterface iface);	The first form is called during startup to provide an opportunity for a plugin to disable itself during initialization (by throwing an exception). The second form is called whenever a new node is discovered to support the service, and before the first poll() is called.
   void release(); void release(java.net.NetworkInterface iface);	The first form is called during OpenNMS shutdown. The second form is called whenever a node that is found to support the service is removed from further polling schedules.
   int poll(java.net.NetworkInterface iface, org.opennms.netmgt.utils.EventProxy eproxy, java.util.Map parameters);	This is the method used to determine if the service being monitored is still available. It should return either ServiceMonitor. SERVICE_AVAILABLE to indicate the service is running, or ServiceMonitor. SERVICE_UNAVAILABLE otherwise.

2. Create a service definition and a monitor definition in the /etc/poller-configuration.xml file. This is the file that pollerd will read during startup to determine the polling interval for each service, as well as the monitor "plugins" to use during operation.

We will create a poller monitor for ClickMeter shortly.

Using OpenNMS to monitor JMX-enabled ClickMeter

We now know that creating a capsd plugin, and a pollerd monitor will enable us to integrate OpenNMS with our JMX-enabled ClickMeter. However, one question remains: why doesn't OpenNMS support JMX natively?

Even among popular commercial NMS offerings, you will find the same general trend -- JMX is not yet natively supported. This is partially due to the fact that JMX-enabled devices and services are just becoming available, and that SNMP compatibility has adequately provided for management of most "third party devices and services" (those that do not originate from the NMS vendor).

There is another important reason why integration of JMX is proceeding relatively slowly among NMS vendors: even though JMX instrumentation level and agent level details are adequately defined by the 1.1 specifications, the details of how to access a JMX agent across a network is still up in the air (at this time).

Back to top

The JMX remoting dilemma

The way JMX agents are accessed across a network by a network management application or distributed service is known as JMX Remoting, and it is the main focus of JSR 160 (see Resources). JMX Remoting is also the major new feature in the upcoming JMX 1.2 reference implementation release.

JSR 160 will specify how discovery of JMX agents should be performed over a network and specific means of remotely accessing an agent's capabilities. This will include some specifics on the protocol adapters to be used. Until the JMX Remoting 1.2 specification becomes finalized, likely in 2003, one must seek alternative functional means of communicating between OpenNMS and the JMX agent managing our ClickMeter MBean.

A workable solution to provide JMX remoting

Of course, one main purpose of the JMX agent is to provide remote access to the JMX MBeans that it manages (although some JMX agents may be designed to add value and may not expose all of their managed MBeans). As we discussed in Part 2 of this series, agents use connectors and protocol adapters to communicate with NMS applications or distributed services.

In the case of ClickMeter, we used the simple agent from the JMX reference implementation, which included an HTTP protocol adapter. This simple agent exposes the attributes and operations of all the MBeans it manages through the HTTP protocol adapter.

Using the HTTP adapter to minimize work

We can readily use the simple agent and HTTP protocol adapter in the JMX reference implementation for communications between OpenNMS and our ClickMeter MBean. Figure 3 illustrates the proposed communications approach. During operation, OpenNMS's capsd will scan a detected node to see if the "CLICKMETER" service is supported. The poller daemon, pollerd, will regularly poll detected services to ensure they are operational. To accommodate both of these probes, we can use an operation called incPanelValue, exposed by our ClickMeter MBean. The added advantage of using the operation incPanelValue as the probing mechanism is the fact that we will be able to see the detect or poll action of OpenNMS visually. ClickMeter's value will be incremented on every probe.

The only thing left to do, then, is to determine how to use the HTTP protocol adapter to access the incPanelValue operation on our ClickMeter MBean. You can use a browser to access the JMX agent at the following URL:

http://<host of agent>:8082/

Of course, make sure the agent is running before you do this. (See Part 2 of this series if you need a refresher on how to do this.) Then try and execute the exposed incPanelValue operation by clicking on the button. You should see a page similar to Figure 4.

In Figure 4, note that the URL used to access this operation is:

http://<host of agent>:8082/InvokeAction//MBean:name=ClickMeter/
action=incPanelValue?action=incPanelValue

And also note that if the ClickMeter application is functioning correctly, the resulting page will contain the phrase incPanelValue Successful. We will use this information to access the MBean remotely from OpenNMS.

Back to top

Hands-on OpenNMS integration

We are now ready to integrate the new "CLICKMETER" service into OpenNMS. To do this, we will create a plugin for the capability daemon (capsd) and a monitor for the poller daemon (pollerd).

ClickMeterPlugin for OpenNMS discovery

The code for the capability daemon plugin is provided in the source distribution, in the org.opennms.netmgt.capsd.ClickMeterPlugin class. We know that this plugin must implement the org.opennms.netmgt.capsd.Plugin interface. Listing 1 shows that the class is derived from AbstractPlugin. This OpenNMS-supplied abstract class provides a couple of parameter extraction methods (getKeyedInteger() and getKeyedString()) that are helpful in our coding.

public final class ClickMeterPlugin extends AbstractPlugin {
    private static final String 	PROTOCOL_NAME = "CLICKMETER";
    private static final int	DEFAULT_PORT	= 8082;
    private final static int	DEFAULT_RETRY	= 0;
    private final static int	DEFAULT_TIMEOUT	= 5000; // in milliseconds

The getProtocolName() method is trivially implemented by the code in Listing 2:

public String getProtocolName() {
     return PROTOCOL_NAME;
     }

Listing 3 shows how the short version of the isProtocolSupported() method is implemented:

public boolean isProtocolSupported(InetAddress address) {
  return isClickMeter(address, DEFAULT_PORT, DEFAULT_RETRY, DEFAULT_TIMEOUT);
  }

In the long version of the isProtocolSupported() method, we process the incoming parameters to use for constructing our URL to access the remote JMX agent. Once the IP and port is obtained from the parameters, isProtocolSupported() calls the isClickMeter() method to determine if ClickMeter is active on this node. Listing 4 shows the code for isClickMeter(). Note that the two constants defined for our URL correspond to the required HTTP protocol adapter access URL for ClickMeter's incPanelValue operation.

private final static String CLICK_METER_BEAN_LOCATOR_URL =
 "/InvokeAction//MBean:name=ClickMeter/action=incPanelValue?
   action=incPanelValue";
      private final static String CLICK_METER_ID = "incPanelValue Successful";

      private boolean isClickMeter(InetAddress host, int port, 
        int retries, int timeout) {
          Category log = ThreadCategory.getInstance(getClass());
          boolean foundClickMeter = false;
          for (int attempts=0; attempts <= retries && !foundClickMeter; 
            attempts++)
          {	                 
                  URL jmxLink = null;
                  InputStream iStream = null;
               try
               {
                      String hostIP = host.getHostAddress();
                      jmxLink = new URL("http", hostIP, port, 
                        CLICK_METER_BEAN_LOCATOR_URL);
                      if (scanURL(jmxLink, CLICK_METER_ID, log)) {
                            foundClickMeter = true;
                            break;   // get out of the for loop
                           }
                     }
          catch(IOException e) {
                    log.info("ClickMeterPlugin: Error communicating 
                       with host " + host.getHostAddress(), e);
                    foundClickMeter = false;
              }
          }
          return foundClickMeter;
	}

The scanURL() method shown in Listing 5 is a helper method that takes a URL and a string as arguments. It then accesses the URL and searches for the specified string in the resulting page. If the string is found, it returns true. Otherwise, it returns false. In our case, we are looking for the incPanelValue Successful string after accessing the URL for ClickMeter's incPanelValue operation.

private boolean scanURL(URL inURL, String toSearch, Category log)    {
                  InputStream iStream = null;
           try {                       
                     iStream = inURL.openStream();
                     BufferedReader urlReader = 
                       new BufferedReader(new InputStreamReader(iStream));
     
                     String curLine = urlReader.readLine();
                        do	{
                                if (curLine.indexOf(toSearch) != -1) {
                                       return true;
                                      }
                           curLine = urlReader.readLine();
                         } while (curLine != null);
					
              }
                 catch  (IOException e) {
                              e.fillInStackTrace();
                      log.debug("ClickMeterMonitor.poll: 
                        Error reading from URL:" 
                        + inURL, e);
		
                  }
               finally  {
                   try	{
                       if(iStream != null)
                             iStream.close();
                    }
                    catch(IOException e) {
                        e.fillInStackTrace();
                        log.debug("ClickMeterMonitor.poll: 
                          Error closing stream to URL.", e);
                    }
               }
      return false;
   }
}

The second step required to integrate the plugin is to edit the <OpenNMS installation directory>/etc/capsd-configuration.xml file and add the protocol-plugin definition shown in Listing 6:

	<protocol-plugin 
	  protocol="CLICKMETER"  
	  class-name="org.opennms.netmgt.capsd.ClickMeterPlugin" 
	  scan="on" >
		<property key="port" value="8082"/>
		<property key="timeout" value="2000"/>
		<property key="retry" value="1"/>
	</protocol-plugin>

You may also want to edit the discovery-configuration.xml file to limit the range of IPs that OpenNMS will scan to managed nodes. In Listing 7, we restrict it to two IPs so our ClickMeter application can be located quickly:

	<include-range retries="2" timeout="3000">
		<begin>192.168.23.75</begin>
		<end>192.168.23.76</end>
	</include-range>

ClickMeterMonitor for OpenNMS

Next, we create the poller daemon (pollerd) monitor plugin: the org.opennms.netmgt.poller.ClickMeterMonitor class. This class must implement the org.opennms.netmgt.poller.ServiceMonitor interface. OpenNMS provides a base class (org.opennms.netmgt.poller.IPv4Monitor) that has the default implementation for all of the methods in this interface. Because we do not need any special initialization or release, we only need to override the poll() method, as shown in Listing 8:

public int poll(NetworkInterface iface, Map parameters) {
       if(iface.getType() != NetworkInterface.TYPE_IPV4)
              throw new NetworkInterfaceNotSupportedException("Unsupported 
                    interface type, only TYPE_IPV4 currently supported");

		Category log = ThreadCategory.getInstance(getClass());
		int retry   = 
		  getKeyedInteger(parameters, "retry", DEFAULT_RETRY);
		int port    = 
		  getKeyedInteger(parameters, "port", DEFAULT_PORT);
		int timeout = 
		  getKeyedInteger(parameters, "timeout", DEFAULT_TIMEOUT);

		InetAddress ipv4Addr = (InetAddress)iface.getAddress();
            String hostIP = ipv4Addr.getHostAddress();
		if (log.isDebugEnabled())
               log.debug("ClickMeterMonitor.poll: Polling interface: " 
                     + hostIP + " timeout: " + timeout + " retry: " + retry);
		
		int serviceStatus = ServiceMonitor.SERVICE_UNAVAILABLE;
		for (int attempts=0; attempts <= retry && serviceStatus != 
              ServiceMonitor.SERVICE_AVAILABLE; attempts++)	{
                  URL jmxLink = null;
                  InputStream iStream = null;
   			try {  
                        jmxLink = new URL("http", hostIP, port, 
                                    CLICK_METER_BEAN_LOCATOR_URL);
                        if (scanURL(jmxLink, CLICK_METER_ID, log)) {
                            serviceStatus = ServiceMonitor.SERVICE_AVAILABLE;
                            break;                             }
                     }		
			catch(IOException e) {
				e.fillInStackTrace();
				log.debug("ClickMeterMonitor.poll: 
				       IOException while polling address: " 
				       + ipv4Addr, e);
			}
  	}  // of for
       return serviceStatus;
	}

Note the use of the scanURL() helper method in Listing 8 to access the ClickMeter MBean.

In the <OpenNMS installation directory>/etc/poller-configuration.xml file, we must add a service definition entry. In Listing 9, we'll specify that the polling interval should be 10,000 milliseconds (or ten seconds):

  <service name="CLICKMETER" interval="10000" 
    user-defined="false" status="on">
      <parameter key="timeout" value="3000"/>
      <parameter key="port" value="8082"/>
  </service>

We should also insert a monitor definition in the same poller-configuration.xml file, as shown in Listing 10:

<monitor service="CLICKMETER"  
  class-name="org.opennms.netmgt.poller.ClickMeterMonitor" />

Back to top

Testing OpenNMS with ClickMeter service

To build the two plugins from the source, use the supplied compile.bat file. You will need to copy a few OpenNMS library files into the <article code distribution>/lib directory (see the README.txt file for details). The compile.bat file will create dwClickMeterJMX.jar. Place this resulting JAR file into the <OpenNMS installation directory>/lib directory, and OpenNMS will load the new plugins automatically at startup.

To test OpenNMS with our ClickMeter MBean, first start one of the ClickMeter implementations from part 2 of this article (standard, dynamic, or model MBean) on the node being managed. Next, restart OpenNMS. This is typically done by rebooting the system or using the <OpenNMS installation directory>/bin/opennms.sh script.

Ensure that the system has started up by accessing the Web-based GUI of OpenNMS. The typical URL is:

http://<host of OpenNMS>:8080/opennms/

When prompted, use admin for the userid and admin for the password. Figure 5 shows the GUI upon successful startup:

During OpenNMS startup, you should see the ClickMeter count incrementing rapidly twice (once by the capsd scan, and another by the initial pollerd poll). ClickMeter will then be incremented at regular 10-second intervals as pollerd does its work.

Once capsd detects the ClickMeter application, it will add it to the RDBMS as a managed service. In production, assets management features of OpenNMS can be used to further categorize and label this service. For our experimentation, we can use the OpenNMS GUI to dive into the ClickMeter service and see the detailed events involved, as shown in Figure 6:

Back to top

The road ahead for JMX

In this series, we have traced the evolution of network management from its modest roots as a "blackbox" device control terminal emulator to its present-day role as a quintessential cornerstone element of the modern day IT support fabric. The modern NMS is a multi-tiered, enterprise-level management system that controls, manages, provisions, and monitors mega-networks of devices, computer equipment, communications circuits, and software services.

We have observed how JMX is a coming-of-age technology that enables application programmers and device designers to add instrumentation to any software application or service quickly. The resulting instrumentation is management protocol- and NMS-neutral. Once the instrumentation is in place, a JMX device can then be managed and monitored by almost any NMS through the use of protocol adapters and connectors.

The JMX specification is a work in progress. Once JMX remoting and the distributed services level of the JMX architecture become better defined, JMX can potentially become the distributed management substrate of choice -- especially for future NMS products that can leverage the Java platform's support for GUI and Web application development, robust RDBMS support, and "write-once run anywhere," which will eliminate the need to maintain multiple implementations of these complex systems.

Back to top

Download

Information about download methods

Resources

• To download the latest version of OpenNMS, or to find out more information about OpenNMS, go to the official OpenNMS Web site.
  
  
  
  
• More information on the RDBMS used by OpenNMS, PostgreSQL, can be found by downloading from one of the mirrored sites.
  
  
  
  
• OpenNMS uses Apache Jakarta Tomcat to provide its customizable JSP-based user interface. You can obtain more information on this server at the official Tomcat site.
  
  
  
  
• The latest JMX specification, reference implementation, and compatibility test suite can be downloaded from Java Management Extensions (JMX).
  
  
  
  
• For a completely open source implementation of JMX 1.1 and the current JMX used by Jakarta Tomcat, check out the MX4J project. This implementation includes an RMI-based connector for JMX remoting that you can try.
  
  
  
  
• If you're interested in CIM/WBEM, take a look through the Distributed Management Task Force Web site for detailed information and the latest developments.
  
  
  
  
• You can download the latest version of Tomcat 4.1.x server, instrumented using JMX 1.1, from the Apache Jakarta Project. Source code distribution is also available.
  
  
  
  
• For ongoing work on the specification of JMX distributed services, protocol adapters, and connectors, see JSR 160 JMX Remoting 1.2, JSR 146 WBEM Services, and JSR 70 IIOP Protocol Adapter for JMX.
  
  
  
  
• JMX features an agent connector/adapter architecture similar to the J2EE Connector architecture.
  
  
  
  
• J2EE 1.4 will feature completely JMX-instrumented containers. Download the latest version of the emerging J2EE 1.4 specification.
  
  
  
  
• Tivoli software from IBM features secure enterprise management solutions that support a wide variety of existing and emerging network management standards, including TMX4J, a JMX-compatible implementation, available from alphaWorks.
  
  
  
  
• Be sure to visit the newest IBM product domain Tivoli Developer Domain for technical information about Tivoli software and security products.
  
  
  
  
• A JMX-compatible implementation, TMX4J, is available from alphaWorks.
  
  
  
  
• Find hundreds of Java technology-related resources on the developerWorks Java technology zone.
  
  

About the author

Sing Li is the author of Early Adopter JXTA and Professional Jini, as well as numerous other books with Wrox Press. He is a regular contributor to technical magazines, and is an active evangelist of the P2P evolution. Sing is a consultant and freelance writer, and can be reached at westmakaha@yahoo.com.

Rate this article

Comments

Back to top

Table of contents

• Complex by nature
• OpenNMS
• Anatomy of an NMS
• OpenNMS architecture
• Extending OpenNMS
• The JMX remoting dilemma
• OpenNMS integration
• Testing OpenNMS with ClickMeter service
• The road ahead for JMX
• Download
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

Dig deeper into Java on developerWorks

Discover knowledge paths

Skill-building guides for Java, Linux, open source, cloud, business analytics, and more.

Special offers