Summary
The JMX API was long in coming, and to date, it is still a long way from 'here'...

When I left Lucent in 1997, I started work on a remove status and monitoring application that needed lots of things that JDK1.0.3 was not offering. I adopted the use of Voyager to get RPC. I found JGL to provide sorting and collections. I needed user level authentication services to let people open the application on their desktop and only have access to the services they were supposed to see.

JMAPI Jalopy?

In 1999 I believe, there was a project called JMAPI that was being discussed on a similarly named mailing list. There was no API, and no publicly usable version. Sun had taken a dedicated SNMP management environment, grown in house, and were trying to make it work as an industry Management platform.

The problems were many. JMAPI grew up (well, perhaps sideways) to become JMX. JMX is, to date, missing two key facilities (even JSR 160 falls short in bringing these things to a close). It has no specified client to server interfaces, and it has no way to let remote entities participate in with a remote JMX server.

In this day and age, and even 4 years ago when things were still getting started, remote management was very visible in dedicated web services on medium size devices. I think that what happened was this. Initially, since JMAPI seems to have only supported SNMP, all remote management was done via modules inside of the application that used sockets to talk remotely to the SNMP managed entity. So, that was the standard interface. SNMP clients could connect to the JMAPI/JMX server, and use SNMP to evaluate MIBs and see what was what.

Was SNMP Ever a Solution to Invest in?

As the whole industry has slowly rejected SNMP for all of its shortcomings in security and flexibility in non-network device applications (and environments where polling 10,000 mibs just doesn't scale), it has become clearer that a different standard is needed. But, in fact, not one standard for server to server communications stands out.

There are so many different things that have been developed because of the lack of acceptable standards that it is mind boggling. So, here we are with this effort to standardize management (JMX is going into J2SE 1.5 it seems), and even this new standard is falling short.

Where's Your Bottle of Solutions?

One of the primary new technologies for distributed computing in the Java environment is Jini. Jini provides some very simple, but extremely effective mechanisms, tools and APIs that facilitate distributed computing environments. The JSR-160 team has chosen to make their remoting interfaces pluggable, because they want to avoid picking a standard that may make the platform less useful for a particular use.

This means that the platform will likely never standardize in a way that would allow multiple different implementations to be usable together. We'll have vendor lock in all over again.

Would you buy into JMX? Is it a good investment?

Talk Back!

Have an opinion? Be the first to post a comment about this weblog entry.

RSS Feed

If you'd like to be notified whenever Gregg Wonderly adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Gregg Wonderly graduated from Oklahoma State University in 1988 with an MS in COMSCI. His areas of concentration include Operating Systems and Languages. His first job was at the AT&T Bell Labs facilities in Naperville IL working on software retrofit for the 5ESS switch. He designed a procedure control language in the era of the development of Java with similar motivations that the Oak and then Java language development was driven by. Language design is still at the top of his list, but his focus tends to be on application languges layered on top of programming languages such as Java. Some just consider this API design, but there really is more to it! Gregg now works for Cyte Technologies Inc., where he does software engineering and design related to distributed systems in highly available environments.