In Progress

Over the last several years I’ve been doing a lot of work on OpenNMS and I’ve changed a lot of different things. I’ve changed the build system, the poller, the collector, and the way the database is accessed. Through all of this there has been one perpetual thorn in my side and that has been the OpenNMS web user interface.

So what are you so afraid of?

The real issue with me and the webapp has been that it just feels very difficult to change. Whenever I have any non-trivial work to do on the webapp I cower with fear of getting into some pitt of javascript, servlet, or jsp scriptlet hell, not to mention the gobs of java code that I have yet to understand.

But the real reason that I’m afraid of the OpenNMS webapp has been the problem of OpenNMS since I started with it. The original OpenNMS code base had no domain model. Rather than simply asking the peristence layer for some domain objects, making a few changes and then saving them again, jsp and servlet code had been forced to dive into JDBC directly embedding queries left and right, storm thru the file system looking for configuration and data files, and representing this data as ints, and strings or some cobbled together object that only makes sense for that single part of the application.

On top of this, the lack of the model has made the webapp as a whole seem somewhat cobbled together. The viewing pages aren’t horrible but the administrative stuff is very confusing. And the graphing stuff just never seems to be quite right.

Another by product of missing a model is that OpenNMS just has way too much code. How many times do I need to write the code to process a configuration package. How many times do I need to build the same queries and result set processing to get the information I want. How many different times will I pass the same three parameters, nodeId, ipAddr and serviceName and not turn it into an object that represents the actual MonitoredService.

All of this makes the code very fragile. A change in one place leads to bugs in others because everyone seems to depends on the details of everyone else’s work. At the same time my relectance to really make any changes to is like an anchor pulling OpenNMS down. What good is cool data collection when creating interesting graphs is so hard? How can I consider collecting topology related data when there’s no clear way to show it to the user? On Call Schedules, User Pages, ACLs, Business Process Monitoring, Executive Reporting, Improved Maps, Users who can change their own passwords. All of this and more has been hindered by my perpetual dread of mucking around in the web app.

Programming is not for cowards

After working for years on OpenNMS if there’s one thing I know for certain its this. Programming is not for cowards. So why haven’t I undertaken the charge to overcome this menace of Java debauchery? Well the answer is simple. I haven’t had a decent plan. Sure I’ve made a few feeble attempts to test the waters in this area but known would be considered any sort of success. Spring MVC was the biggest effort along with some others like GWT, Wicket, and I’m sure we all remember the Secret Project.

Many of those failed not because they are inherently bad technologies but that they only assisted you in coding rather than in thinking. The failing of the webapp has not been a lack of technology but a lack of a clear design in terms of modeled objects. Instead of a technology that helps as parse form data, convert strings to dates, or write fancy javascript (though we really want these) we need something that will guide us in modeling the concepts behind our interface.

We want the user of the web ui AND the developer to be thinking about the problem in the same way. When this occurs then the important concepts that the users sees will be matched by objects and interfaces in the code making the transition from user to contributer simpler and making the learning curve of OpenNMS development simpler. Not to mention making the code easier for all of us.

Real Ultimate Power

So… all that sounds nice and all, but where will we find a technology or strategy that will do so much? For some time I had wondered the same thing. Until now.

Due to a serendipitous string of events that included Jason Aras, free books, Red Bull, Tarus Balog, Texas, new feature requests that I’m still behind on, David Hustace, car pooling, and yet another importer tweak, I was introduced to a web architecture known as Resource Oriented architecture which is what many people have come to mean when they say a RESTful architecture. (Please see “RESTful Web Services” for more.)

The key principals of this architecture are:

1. A webapp is really made up of a collection of ‘Resources’
2. Each of these resources has an address in the form of a URL.
3. There is a very simple set of operations available on these resources known as the ‘Universal Interface’- GET, POST, PUT, DELETE.
4. Information sent back and forth in a URL is a representation of the state of one of these resources.

You are probably tempted to do like I did and brush off this seemingly simple list as “Yet Another Set of Coding Standards” or something like that. If you do then you’re making a big mistake.

Simple as this list is, if we embrace its wisdom, it will lead to a remarkably simpler OpenNMS. The above principals will lead us to clean modeling of our domain, push us to proper layering of the application, enable simple intergration with other technologies, and best of all, make web ui development a joy.

I will be posting a series of blog entries over the next several days that I hope will convince you that this is going to simplify OpenNMS web development for good. I hope to introduce the technologies and processes that we’ll be using, implement a simple example, and then document the first steps of OpenNMS webapp design.

Please stay tuned

This entry was posted on Thursday, July 17th, 2008 at 1:20 pm and is filed under Development. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.