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.