Enterprise Java Community: JMX

Network management software.

As computer networks grew and extra components were included in companies network topologies (i.e. routers, switches, hubs, servers, PCs, SANs) etc., managing these components became very complex and expensive. Software products such as Tivoli or CA UniCenter coupled with standards such as MIBs and SNMP have tamed this to an extent. Most network attached devices produced today support SNMP and use a pre-defined MIB. The MIB (a MIB defines a class of device's attributes and administration interface) is a standard defined for each type of network-attached device. These standard MIBs make devices easier to control. It does not matter whether a router is made by Cisco or Juniper, if it supports the same MIB then it is the same from an administrative point of view.

Managing a software deployment is just as complicated as managing a large network. Therefore, software is being integrated into existing network management infrastructure. A lot of new software products come with embedded SNMP agents and MIBs have been defined for them. This allows support staff to leverage the existing hardware support infrastructure for their software. This in turn, lets them remotely control SNMP enabled software running on a machine. This considerably eases the support for large enterprises.

Most large companies already have a network management infrastructure deployed. Unfortunately, Java developers have been excluded from leveraging existing network management infrastructure. Levering existing network management infrastructures required Java developers to write their own SNMP agent and then program the application to interact with the agent. The arrival of JMX should finally allow Java developers to leverage network management infrastructure without using proprietary software.

JMX, a brief overview.

JMX (Java Management eXtenstions) is a new Sun standard that allows Java developers to integrate their applications with exiting network management solutions. JMX defines a standard for writing JMX objects, also called Mbeans. Mbeans live inside a container that is defined by the standard. It is possible for a JMX client to invoke methods and access attributes on an MBean using the container. It's also possible for a client to receive notifications from an MBean by registering with the Mbean.

What does JMX support buy developers?

JMX will allow you to instrument your application and control/monitor it using what-ever management console that your JMX container supports. An example would be a web application that implements a reference data cache. Your application implements a cache that holds a list of customer id/customer name records. This allows you to quickly look up a name from an ID without an expensive database access.

JMX can help us build this a number of ways. We will implement the cache as an MBean. What does this mean? This basically means that we make the class implement an interface whose name ends in MBean. All MBean methods should be declared on the MBean interface. If you want to support publishing events that a JMX client could subscribe to then implement the Notification interfaces also.

We now load the MBean in to our J2EE container and then our servlets will use this MBean for its caching purposes. The MBean is really the cache we had before but implemented using the MBean interfaces and we register the MBean with the MBean container.

A problem we had before was we would occasionally need to refresh the cache because a customer name changed in the database. If we had a refresh method on the MBean interface then we should be able to trigger this event using the JMX console. The JMX console may be a web or fat client that comes with our J2EE server. Our J2EE server may also support SNMP. This means that we may be able to invoke the method from a standard Tivoli or UniCenter console.

We could also monitor the hit rate of the cache. The hit rate determines how frequently the cache contained the requested data. We may decide to limit the cache to holding 1000 customer names. As customer names are requested, we look in the cache. If the name is present then we return it. If not then we look up the name in the database, store it in the cache for next time and then return it. If the cache reaches our maximum size then we select a victim from the cache and remove that item to make room for the new item. We can select the victim using a number of policies FIFO (first in, first out), LIFO (last in, last out, LRU (least recently used) or anything you can dream up.

How often we find an entry in the cache is basically the hit rate. If we do 100 lookups and 92 were present in the cache then we have a 92% hit rate. We can use the cache hit rate to monitor the performance of the cache. We could fix the size of the cache but this would not be recommended as if when we entered production, we discovered the hit rate was 60% then we would need to recompile the application to change the size. A better approach is to allow the size of the cache to be specified at run time. We could also allow the victim selection policy to be selected at runtime. We could build a generic cache MBean that can be used to cache various data. The JMX interface for this MBean would be different from the programmer interface. The JMX interface would probably support an interface like this:

Attribute Cache Size
This attribute allows the size of the cache to be queried/set.
Cache Policy
This attribute allows the victim selection policy to be queried/set.
Cache Hit Rate
This read only attribute allows the cache hit rate to be queried.
Notification support.
This allows a JMX client to receive notification events from the cache object. We could send events representing cache size changed, hit rate changed, we could simply send a hit rate once a second.

Obviously, we don't need JMX to do this. We could just do this with a normal Java Bean. But, making it an MBean gives us a number of advantages. An ISV can develop the cache MBean. You can load this MBean in to your J2EE server. You can then manage this component using the management console supplied with your J2EE server. If you're using a more advanced console such as Tivoli or UniCenter then you could write a script to control your cache component. It could for example, increase the size of the cache until the hit rate reaches 98%. It can do this by either polling the hit rate or subscribing to the notification events for the hit rate. It could change the cache size until the hit rate reaches a specific value.

This reduces the load on the ISV developing the MBean. He simply implements JMX and in doing so enables the above integration. If the data that we are caching is changed by an application then an operator can use the JMX console to invoke a reset/refresh method on the cache causing it to forget all cached values. We thus avoid a stale data condition. If the JMX container is more sophisticated then we can also do this programmatically.

The ISV would need to provide proprietary hooks before to enable this sort of integration and would probably be forced to develop a custom console. JMX removes this task. JMX allows the MBean developer to take advantage of the underlying management infrastructure used by his client.

JMX, remote client support.

The MBean container can also implement one or more remote protocols. These remote protocols will allow a JMX client running in a different process or machine to manipulate MBeans registered in the container. What protocols the container will support is currently not standardized but SNMP is an obvious one for MBean container vendors to support. You may also see HTTP/SOAP support and RMI/IIOP support. JMS support especially for notifications will probably also show up.

These remote protocols should allow command line tools to be written that can be used to control either the standard MBeans that ship with your J2EE server and they can also be used to control any MBeans that you've written. This is very powerful and lets you and your production staff leverage the tooling that arrives with your application server to control your MBeans. This means you can, for example, control the logging properties of log4j, a popular logging utility, using your application servers tooling so long as Apache or you implement and register an MBean that allows log4j to be controlled with JMX.

We should also see HTTP JMX management consoles that allow the same sort of control using a HTTP browser. This is a big plus for controlling deployed systems in DMZ where the necessary ports for SNMP or RMI/IIOP may be closed by firewalls. A HTTP console with password control may be a valid choice for managing such deployments.

SNMP support (a standard network management protocol) will allow third party network management products such as CA UniCenter and IBM's Tivoli to control MBeans hosted by JMX containers that implement SNMP. This is a critical feature for large companies or ASPs that need to lower the costs of supporting software in a large data center. This technology should lower the cost of supporting J2EE software by:

Leveraging the skills of the support staff.
They already know how to use Tivoli or UniCenter and now don't need to learn yet another set of management tools.
Automatic scripts can be developed.
Tivoli or UniCenter come with scripting engines that allow scripts to run when events from MBeans are received. This allows an element of automatic support to be realized which lowers the support costs. Currently, your J2EE server is not integrated in to the existing network management tools and this makes it harder to implement support policies. Once SNMP is supported then your J2EE server and it's embedded MBeans can be integrated fully with the existing scripts and this should make it easier to manage.

The only protocol that is standard right now is SNMP. This means that currently if you get a JMX container that supports RMI/IIOP, HTTP or SOAP then you will only be able to use the tooling or consoles from your J2EE vendor with it. SNMP is right now the only 'standardized' protocol that would allow you a choice from tooling front ends.

Who will provide a JMX MBean container?

Your friendly, neighborhood J2EE vendor. You can expect to see J2EE vendors to start shipping JMX containers with their J2EE servers. J2EE vendors jBoss and BEA are currently the only ones with this support. IBM will probably use the Tivoli JMX container.

How integrated these JMX containers are with the application server is the next question. jBoss have heavily integrated JMX into jBoss. They basically rebuilt their application server to use JMX as their framework for building the server up from MBeans. BEA are saying that they also support JMX. BEA seem to have also heavily integrated JMX in to their server. IBM have still not announced their intentions as regards this.

A problem right now is that while vendors have included JMX support, they have not made it available for developer to use. This basically makes it a marketing exercise. If you can't use it then they might as well use a proprietary management mechanism. When vendors provide fully implemented JMX containers, integrate JMX in their application server AND document it so that developers and third party component developers can make use of it then JMX support will become more than just a buzzword.

What sort of non EJB components could leverage JMX?

The sky is the limit but some obvious ones would be Logging frameworks such as Log4J, Object relational mappers such as TopLink, IBM Persistence Builder, Cocobase etc. JMX enabling these would allow them to be controlled at runtime in a much more sophisticated way than is typically done today. JMS Transports would also be a candidate. For example, take Swift MQ. We could package SwiftMQ as a JMX MBean and then control it using our normal management console and use statistics from it as runtime for performance alerts/tuning in conjunction with our management console.

Non J2EE middleware such as message brokers, workflow engines etc could also be choices.

What about the J2EE server it-self?

JMX should be very useful here also. For example, the J2EE containers could be MBean enabled. This would allow you, the J2EE developer, to subscribe to container events and control the container programmatically. The CMP container cache for example. You could write a JMS listener (packaged as a loadable MBean, of course) that subscribes to database modification messages and then uses JMX to programmatically reset the CMP container cache to remove the stale data. You may want to collect information from the J2EE server by subscribing to JMX notifications and then forward these to a database or JMS topic for example. This is extremely useful if you have an application server that doesn't support the management software you are using. Suppose, for example, you're using IBM WebSphere and it doesn't support CA UniCenter, just Tivoli. If WebSphere was JMX enabled then you could simply subscribe using JMX to these events and forward them to your console. This allows a J2EE server to be more easily integrated with a management infrastructure than at present. The importance of the ability to easily gain access to these sorts of events or alerts in a production environment JMX support also provides a standard way to implement startup classes/services. These must currently be implemented using a proprietary API if one is available. How to interact with these services is also currently tricky. JMX breaks us out of that box and allows the standard console to be used to control our extensions.

It could also be used to stimulate a standard third party container market for J2EE servers. You buy a standard J2EE server. It provides the following:

Security manager.
Transaction manager.
An ORB.
A JDBC DataSource manager.
Default implementations of session bean, message bean or CMP containers.
JMX Container + remote JMX protocol implementations.

But, suppose you need a specialized message bean container for your application. If the container vendor packages the container as an MBean that you should be able to add it to the J2EE server and manage it using the standard console or any other console that can talk to your JMX container.

Problems with J2EE.

This actually highlights some deficiencies in the J2EE specification. The specification is currently targeted as developers using the containers currently. It doesn't address the sorts of objects that a container developer may need. For example, extracting the currently authenticated user for a thread. Obtaining the JTA transaction manager so that the container can start transactions. It's difficult to see how this market can develop until Sun address these problems. Currently, container vendors must gain access to proprietary hooks in the J2EE server to do this.

It would also be good if Sun and the J2EE vendors got together and started to define a standard JMX interface for J2EE containers. This would allow companies like IBM, HP and CA to build in support for J2EE containers to their management products. They are actually starting down this path right now. A JSR is being started to define a MIB for J2EE containers. A MIB is a standard description of the objects, properties and methods for controlling/interacting with a component.

This container market place is a vital part of the J2EE future in my opinion. J2EE vendors seem to be bundling very general containers with their products. These containers are currently sold as everything you need, but developers are quickly discovering that these vanilla containers are not suitable for some applications. For example, the WebLogic Message Bean container may not suitable for implementing the front end of an e-trading system. How-ever, a third party may develop a specialized container for implementing these sort of ultra high availability applications. Currently, they would probably try to sell you a complete J2EE server. If they can sell this container as an add on for WebLogic, WebSphere, EAServer or anyone else's then this will obviously be an improvement and increase the market for such a product and reduce the development costs so that the development effort can be focused on delivering the core benefit of the container.

Conclusion.

So, JMX looks like a very useful addition to the space. It should give developers a way to integrate components with a client application or J2EE server. It should gives J2EE developers a standard way to interact with the J2EE containers shipped with the server. It should give developers a way to better integrate components with their customers management infrastructure.

If Sun can define some standard JMX objects (or MIBs in the traditional SNMP sense) for J2EE containers then it should be easier to plug J2EE servers in to a traditional managed LAN. The sooner we see JMX containers implemented by J2EE vendors and they start really integrating JMX with their server the better. jBoss is a good example of the extreme use of JMX. Not all vendors may go to this extreme use of JMX but we will see varying layers of integration of JMX with most J2EE servers.

PRINTER FRIENDLY VERSION

Java Solutions

Site Map