Although SNMP is ubiquitous as a management protocol, it is far from being a friendly concept for developers to work with. There are plenty of points in SNMP's favour not least its popularity, the extensibility of the Management Information Base (MIB), and the fact that because it's been around so long, anyone wanting to make their kit manageable doesn't have to think too hard about which protocol to use, as there's really only one choice.
SNMP's command set is mercifully small not a great deal more than "Get first instance", "Get next instance", "Set first instance" and "Set next instance". This is great, but makes it tedious to step through a 96-port device figuring out interface settings. Okay, it's the author of the management application that deals with this and not the user, but everyone who writes an SNMP-based application has to muck about with this step-by-step access mechanism.
Anyhow, I found myself wondering whether there was any way one might make life more straightforward for developers wanting to interface to the management interfaces of network devices. Although there are some programmer libraries around for SNMP, it's not actually the protocol (i.e. formatting packets, sending requests/commands and processing responses) that's the awkward bit. The problem is all the mucking about mapping the sequential nature of the command set onto the hierarchical nature of the devices we're talking to.
The obvious answer is to devise some kind of middleware application into which programmers can hook. At the back end it'll do the SNMP rubbish, but at the front end it'll be far more friendly, with the ability to say: "Tell me the link speed and status of all the ports" in a single query and to receive a single response with all the information. The obvious form for the front end, given today's technology fashion, is XML.
I dont believe it
For a while I couldn't believe that Google searches for "+XML +SNMP" yielded nothing along these lines surely it was such an obvious idea that someone else had had it (and someone with time on their hands had had a bash at making one). I'm relieved to say that a couple of researchers are having a bash at just such a beast (you can find links to their work at the end of this article).
The two examples I've found have two different, but related takes on the problem. The simpler approach of the two (ref 1) seems to be to assume that SNMP is unlikely to be usurped as the standard that's built into networking equipment, and so the route to XML is simply to build a gateway between XML on the client side and SNMP at the server. The more complex approach (ref 2) is to imagine a world where both client and server will speak XML natively, but that in the interim there will be the need for a pair of translators one for XML clients communicating with SNMP servers, and one for SNMP clients and XML-based servers. Neither approach is necessarily right, but one can't help thinking that in the short to medium term at least, vendors are unlikely to bin perfectly workable SNMP implementations and thus it's tempting to conclude that the translator approach is more likely to be the successful one.
Of course, interfacing to SNMP devices via an XML interface is far from a trivial matter. Although, as we've said, the actual IP transmit/receipt bit is fairly simple, there's a whacking great MIB to translate into an XML schema although since SNMP is a standard defined by a wad of RFCs, at least the specification is in the public domain. The other main issue is that by introducing a translation layer between the network management application and the managed device, you're adding another layer of operational delay which will slow down response times.
On balance, though, I believe that the advent of XML as an interface to SNMP-compliant devices will encourage developers who would never have considered fighting with SNMP to take the plunge and apply their coding skills to an XML-based network management application.
With any luck, then, the field of network management software (where we haven't really seen a great deal of innovation in the last few years particularly, it must be said, in the Open Source arena) there's every chance that XML will open up competition and encourage innovation. And I hope that the handful of researchers who've taken the plunge and had a bash receive some recognition for starting the ball rolling.