Slashdot Mirror

← Back to Stories (view on slashdot.org)

Goodbye SNMP? Hello, WS-Management

Posted by michael on from the at-least-it-isn't-an-acronym dept.

Laoping writes "News.com has a story about a new Web services management specification designed to simplify network administration across a wide range of devices. A bunch of a big tech companies developed it together (Microsoft, Intel, AMD, Dell and Sun). Microsoft will build support for WS-Management into an update to Windows Server, which is due late next year, and in the version of its Microsoft Operations Manager management software due in 2006. The .PDF release, that makes it clear that it is meant to be a Simple Network Management Protocol killer. Now I am all for a replacement for SNMP, but is this the way go?"

6 of 176 comments (clear)

  1. but... but... by Anonymous Coward · · Score: 5, Interesting

    The real power of snmp is what you can achieve through scripting it - queries and updates etc.

    That becomes nigh-on impossible with this WS-Management craziness.

    Typical Microsoft - always thinking there is some pleb click-clicking away.

    Imagine you have to change some rmon threshold on 400+ devices, or integrate this with the corporate asset database.
    Now you get the picture.

  2. Ever heard of CIM? by ansonyumo · · Score: 4, Interesting

    CIM is a fine, object-oriented replacement for SNMP, is mature and has XML-based communications over HTTP.

    http://www.dmtf.org/standards/cim/

    Microsoft already has a CIMOM implementation in its WMI service, although it uses DCOM to implement RPCs. Sun also has a CIMOM implementation for Solaris.

    I find it very strange that the WS-Management .PDF doesn't even reference CIM.

  3. Bandwidth overhead by embeejay · · Score: 3, Interesting

    Using webservices for something like this seems like an enormous bandwidth waste to me. Whatever happened to optimization?

    1. Re:Bandwidth overhead by Anonymous Coward · · Score: 3, Interesting

      Optimization died a sad, sad death a while ago. The IETF has lost its mind and endorsed huge, complicated, design-by-committee protocols (IPSec, which mandates strong crypto in the kernel; IPv6 has been The Next Big Thing for over a decade and has gone through feature bloat the whole time; XMPP uses half-assed uncompressed XML for its network stack, resulting in overheads greater than 100% in many cases; etc.). The Web (and the W3C) brought with it a dramatic change from "Everything runs over a specially crafted protocol" to "Everything runs over HTTP, usually XML+SOAP". Along with that (though somewhat earlier as well) came "The Network Must Be Human Readable In All Cases", which is frankly stupid (maximum 7/8ths efficiency as the high bit goes out the window; note that TELNET and SMTP, for example, are human readable because they date from an era largely before dedicated clients, as opposed to now).

      For some reason, usually while chanting "Moore's Law", CS has voluntarily shed most of the systems concepts that it ever espoused, and along with it most of the thoughts that, maybe, things should be both elegant and efficient. At CMU (with its widely praised CS department), for example, most CS majors are introduced to assembler in the most painful way imaginable - instead of having the beauty of the processor design and architecture explained, they are forced to carry out buffer overflow attacks on provided code and to wade through reams of assembler to reverse engineer compiled code. Not exactly a beautiful introduction to the topic.

      It has become acceptable to chew up an ever increasing amount of resources to accomplish nothing that could not be done before. Usually it's coupled with talk of "it's easier", though I can't say I find the appeal of XML as a data exchange format (config files are fine; humans need to read those, sometimes). The effort (time and memory usage) to serialize and deserialize XML is orders of magnitude larger than a container designed for the context [contrast TCP/IP & BLOAT - yes, it's an RFC].

      \rant{off}

  4. I'm not sold by KidSock · · Score: 4, Interesting

    I don't mean to pooh pooh this idea just because it's somewhat Windows specific but the only real advantage I see to this over snmp is that the delivery modes are more sophisticated and the data can be organized hierarchally. So why not just add builtin event notification to snmp? Otherwise using XML for something that should be a low-cost service seems wrong to me. System monitoring should be as small and SIMPLE as possible to reduce the possibility for exploits as it will likely be running with a high level of anonymous access on almost every workstation, server, and router in the organization. The whole thing smells of XML pixie dust designed to drive up requirements and thus sell servers and new software to go with. If you have a problem with snmp then fix it. Don't reinvent it with techniques that are expensive in clock cyles and exploits.

  5. Jabber instead by hey · · Score: 3, Interesting

    I wonder if you could use XMPP (Jabber) to monitor devices. Each device connects to the server like a person IMing. It can easily send a message when something bad/good happens. You can have a roster (buddy list) of the devices you want to monitor.