JMX, SNMP, Java, etc...

In a previous blog entry, I have already argued that Simple Is Not Easy. While I was thinking about this new article, I found myself admitting that the corollary was also true: making things easy is not always simple.

So what's so special about management? And to quote the original question:

What is inherently "management" that explains why JMX needed to define its own "Bean" abstraction, its own definition of "attribute" and "operation" instead of simply building on the Java bean concept? Why wouldn't one simply use POJOs and some remoting protocol? Interestingly, JMX shines because JMXRemote + Jconsole make it super simple to display some stats but -conceptually- how is "management" different that it warrants such a specification?

There will be several layers to my answer. The first is that precisely the idea behind JMX is to build up on the Java Bean concept - in order to let you expose your POJOs through some remoting protocol. This is the whole point of JMX. And this is where a little historical perspective becomes interesting.

JMX is JSR 3. Its first version dates back to the end of the last millenium, just before the apocalyptic Y2K bug was about to strike (JSR 3 was approved by the JCP on December 23rd 1998, its first release was on December 10th, 1999, and its final release on September 7th, 2000). It's ancestry included the Java DMK which, when JSR 3 was final, later became Sun's first commercial implementation of JMX.

When JSR 3 started, I still hadn't had the opportunity to join Sun, and I was working for a small French company called Netmansys. Netmansys was specialized in providing TMN software tools for Network Management Systems. And in those years, the big thing was what was called Q3 interfaces, based on CMIP/GDMO. If you wanted to sell telecommunications management software or telecommunications hardware, you had to have the TMN and CMIP/GDMO stamp. That was the big buzz. TMN standards and compliance were pushed forward by the TMN Forum (which has now evolved into the TeleManagement Forum). This was the time of big Network Management Platforms, like HP-OpenView and TeMIP. TMN with CMIP/GDMO was the next big standard that was supposed to replace all proprietary management protocols as well as all other pre-existing management protocols, like TL1 and SNMP. You had to have it. And all that buzz was not without reasons.

At that time, the telecommunications market was growing fast. The internet was growing fast. Telecommunications operators were facing an integration nightmare: their networks contained a huge quantity of legacy equipments, each managed with their own vendor dependant models and protocols, each with their own management stack, each with their own management consoles, sometimes needing an operator to go and physically plug his laptop directly into the equipment in order to reconfigure it. It was an integration nightmare. It could not last. SNMP was widely used and deployed, but it would only let you SET and GET simple values - and was not really suited to invoke complex operations, like setting up an SDH Add&Drop Multiplexer ring. So CMIP/GDMO, being Object Oriented, coming with a whole host of TMN standard models describing various equipments in a vendor-neutral way, was the answer.

It looked as if CMIP was going to be the next and only management protocol of the future, and GDMO, with its power of expression, was going to help model the world.

While this big buzz was going on, some smart guys had quite an idea... Because in fact, when you look at it, what is GDMO but an object oriented specification language?
And what is CMIP but a protocol that allows you to GET attributes, SET attributes, send NOTIFICATIONS, and invoke arbitrary ACTIONS on objects defined with GDMO?
And what is Java but an object oriented language?
And what is a Java Bean but a POJO on which you can GET properties, SET properties, and which can have arbitrary operations?
So why not replace GDMO with plain old Java Interfaces, and expose them through some protocol, like CMIP if you wanted to, or any other protocol that would let you GET properties, SET properties, and invoke operations? Sure, you could use a CMIP/GDMO stack to do that stuff, but why would you need to do so? Why wouldn't you simply write your POJO's in Java and simply expose them with some protocol, through some kind of infrastructure that would shield your POJOs from the protocol through which they were exposed? And why wouldn't you use Java dynamic uploading capability to update and evolve your management application? Wouldn't that be a neat trick to solve the complex integration nightmares?
JMX was born.

The goal of JMX was simply that: program & design your managed objects using plain old Java, and register them in a repository where a protocol adaptor - such as a CMIP/GDMO adaptor could pick them up and expose them to the outside world. The idea was that the developer who writes managed objects should not have to be bothered with the complex details of the management protocol that's going to export them. The idea was also that in complex heterogeneous networks, you could simply write an MBean that would extract its data from some piece of legacy equipment, and register it in that repository where it could be picked up and exposed through some other kind of protocol to the higher layers of management. DynamicMBeans would make it easier to implement such mediations.

In a context where management protocols were growing in numbers and complexity, the goal of JMX was to make the implementation of management interfaces easy: as easy as designing and implementing a plain old Java Object. In that respect, I believe that JMX did not miss its goal.

This also explains why at first, JMX had no remote API, since the remote access to JMX instrumented resources was expected to be implemented by standard protocol adaptors, like CMIP adaptors, or SNMP adaptors. As time passed, and applications/toolkits started implementing their own flavors of JMX remoting (like the Java DMK's legacy "RemoteMBeanServer") - it became obvious that a standard remote API for Java client application was needed. This is how JSR 160 - JMX Remote API was born.

Note that by that time, the big CMIP buzz had started to die... Why so? because CMIP/GDMO was often perceived as too complex, needing a long learning curve and training before you could start coding your management interfaces. Sure, there were tools here to help - but you still needed to understand GDMO, ASN.1, and all those complex standards. If it was quite easy to hire qualified C and C++ developers, it was difficult to find C and C++ developers who understood CMIP, ASN.1 and GDMO. In fact, CMIP and GDMO are still in use today, and very much so for managing equipments in the backbone of telecommunications networks, but CMIP is no longer considered as the big next management protocol of the future. If you ask me, the next-big-thing candidate starts with a W ;-)...

So what's inherently "management"? Here are a few thoughts:

• Modeling Language: to manage something you have to model it - there isn't a management technology that I know of that doesn't come with its own modeling language. SMIv1/v2 for SNMP, GDMO for CMIP, MOF for CIM/WEBM... wait, wait, there is one indeed: JMX. Why is that? Because the native modeling language for JMX is Java - and also consequently, Javadoc.
• Models: Every management protocol comes with its own set of standard models - SNMP has its standard RFCs, CMIP its whole series of telecom standard (g774 etc...), CIM/WEBM has CIM, etc... But what are the model(s) for JMX? JMX per se does not define any model (the only bits of models you will find in the JMX specifications are JMX MonitorMBeans), but JMX will let you define - or import - your own models. For instance, JSR 77 defines a CIM model for the management of the application server, which is implemented by means of JMX MBeans. JSR 174 on the other hand defines a native Java model for the Management & Monitoring of the JVM, by means of native JMX MBean interfaces. Not defining any model was a conscious choice (and I believe a good choice) made by the initial JMX Expert Group, and not an oversight. Indeed it was felt that it was more important to have the ability to import existing models, possibly originally defined in the scope of other protocols/technologies (such as models defined by the TMForum, or by the DMTF) - rather than forcing people to redesign their models in order to fit in a pre-ordained model set.
• Heterogeneity: this is one of the most recurrent characteristics when you deal with management: the need to integrate with higher level management systems, or lower level management infrastructure which may use different protocols, may be developed in different languages, and may run on different architectures. There's always a point were you might need to integrate things which were not designed to be integrated together. By providing a framework that split the model (supported by MBeans) from the protocols (RMI, SNMP, CMIP, WBEM, XML/HTTP, others...) that will be used to act on it - JMX provides a powerful integration and/or instrumentation framework. JMX protocol connectors and adaptors make it possible to open Java application to heterogeneous management environments. For instance JSR 262 - WebServices connector for JMX, provides, among other things, a means for non Java applications (e.g perl script) to get at at the resources instrumented with JMX. The Java DMK SNMP adaptor makes it possible to build an SNMP layer on top of a JMX instrumentation. A CMIP adaptor may be able to expose JMX instrumented resources to CMIP managers, etc...

So why did management extensions warranted a specification on their own? I hope I have managed to shed some light on this interesting question. Will JMX die away to be replaced by something new? Will it find a niche and stay confined in it? Or will it adapt and evolve with the wave of new technologies and protocols? Only the future will tell.

However, seeing how easy it is to write an MBean (or MXBean) and access it from remote, seeing how easy it is to deploy new protocols connectors and adaptors for JMX, and seeing how easy it is to write a remote management application against a set of MBeans, I believe that JMX is here to stay...

Cheers,
--daniel