Back in my OpenView days I can remember when the first web-based user interface for Network Node Manager came out. People were pretty excited since you could then access OpenView from your desktop without having to use Hummingbird or ReflectionX. It wasn’t very good and didn’t have all the features but it was good enough for some tasks.
But I’ll make the claim that it never got better than the native X11 client.
Now granted, I haven’t really worked with OpenView for many years, and in that time both that product and web technologies have improved, but sometimes I have to wonder if writing a web-based user interface is worth it.
The OpenNMS webUI has long been a weak point for the OpenNMS product. Part of that has been philosophical – the idea is that people are busy and thus having a robust and powerful notification system is more important than a user interface that you put up on a big screen, but also part of that has been that good webUIs are hard to write.
Recently some people have been reporting errors in the webUI that we can’t reproduce. We finally nailed it down to Internet Explorer 7. Something changed and now some of our code breaks on that browser. It used to work, and it works on all the other major browsers, but something changed to break it. It’s hard to write to such a fluid platform.
Also, there is the question of state. Ultimately people navigate in a browser via URLs. Someone might go to a particular page in our webUI, bookmark it, exit the browser, upgrade, reboot, turn off the system, go on vacation and when they come back want to go to the same URL and get the same exact information. It is difficult, and sometimes impossible, to make that work all the time.
Another reason we’ve been thinking about the webUI recently is due to a project we are doing for a client in Italy. OpenNMS has proven itself able to monitor tens of thousands of interfaces, but now we have a client with tens of thousands of interfaces on a single device. It’s pretty crazy. In order to display that information on a node page we’ve started using Ext JS. Also, a lot of work went into making the code perform well (by tuning the database queries, for example) with all of those interfaces.
We’re trying to use it throughout the webUI, such as on the front page for the resource graph drop down.
But I keep asking myself why we bother. Why not just make a Java client? Using webstart we could download it through a browser, and now with JavaFX it is even more transparent since you can “easily drag-and-drop a JavaFX application from the browser to deploy to the desktop”.
The feature list for OpenNMS 2.0 has always been focused largely on the user interface, and I’m pretty certain that JavaFX will be the way to go. It will allow us to deliver a richer user experience with less complexity on the programming side. In order to get there we have been adding RESTful interfaces to all of daemons (via jersey) which will expose all of the information that OpenNMS has to pretty much any outside source, including the user interface.
We are sometimes criticized for writing OpenNMS in Java, but in our experience nothing else out there can provide the same level of scalability (think hundreds of thousands of managed objects) while minimizing the programming effort.
When I was in college I used to tinker with old Mercedes-Benz automobiles. I’d buy them for around US$1000 and rebuild them. I’d start with the engine, then the brakes, then the electrical system, etc. The last job of any restoration was the paint.
However, being in college, I would usually run out of money before I got to that stage and I’d have to sell the car. Having a poor paint job always made it harder to sell – people were not concerned that they could get in the car and drive it across the country – they saw dull paint and assumed it was worth less.
I think OpenNMS gets the same treatment. The mechanics of OpenNMS are solid and proven, but since the webUI isn’t flashy it gets dismissed.
With Sun’s new open source focus and tools like JavaFX we should be able to put a nice new coat of paint on the OpenNMS user interface.