Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
The Internet Software IT

Goodbye SNMP? Hello, WS-Management 176

Posted by michael 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?"
This discussion has been archived. No new comments can be posted.

Goodbye SNMP? Hello, WS-Management More

Goodbye SNMP? Hello, WS-Management

Comments Filter:

  • wonder (Score:5, Funny)

    by COMON$ ( 806135 ) on Friday October 08, 2004 @04:53PM (#10474855) Journal
    hmmm, I wonder if this will catch on as quickly as IPv6 has.....

    • Re:wonder (Score:4, Insightful)

      by NicolaiBSD ( 460297 ) <spam@@@vandersmagt...nl> on Friday October 08, 2004 @05:04PM (#10474954) Homepage
      There's no real incentive to move to IPv6, at least not in the western world, as there's plenty of IPv4 address space left. Apart from that there's also the perceived complexity of IPv6 (long hex numbers, so it must be more complicated than shorter decimal numbers).

      If you've worked with SNMP, you know that it is a technically solid solution - low on resources, fast. However, SNMP _is_ complex. Finding OIDs in large MIBs, secure configuration, interpreting data are mostly difficult.

      I give a technically sound, industry standard and less complex alternative for SNMP a good chance for quick adoptation.

      • Re:wonder (Score:3, Insightful)

        by dirvish ( 574948 )
        Complex, and inherently insecure.
      • >However, SNMP _is_ complex. Finding OIDs in large MIBs, secure
        >configuration, interpreting data are mostly difficult.
        These are valid points, however I'd not blame all that on SNMP itself.
        It's mostly the tools. SNMP tools could be made much much better/easier.
      • You forgot to mention SNMP is a security nightmare with holes. I am not taking about it on all platforms and not only on Windows.

        We need a replacement and anyone who has studied Microsoft's MCSE materials know that MS has been wanting to ditch SNMP for years.

        Not a bad idea.

    • Yup, IPV6 has something in common with ISDN. It will become obsolete before anyone will use it...

  • Why is it that every there's something new.... (Score:5, Insightful)

    by Anonymous Coward on Friday October 08, 2004 @04:55PM (#10474871)
    The moron submitting the summary says "goodbye [long established and well entrenched technology]". SNMP has been around for a very, very long time. No matter how much better this is, it will not replace SNMP any time soon.

    Read the article about the 32-bit MCUs a few stories down for yet another example.

  • this page but without going blind (Score:3, Informative)

    by Anonymous Coward on Friday October 08, 2004 @04:57PM (#10474895)
    click [slashdot.org]

  • sounds like the next virus propagation method to (Score:1, Interesting)

    by Anonymous Coward
    me... i will concider it when there is an OS version available.

  • connect the dots (Score:5, Informative)

    by Doc Ruby ( 173196 ) on Friday October 08, 2004 @05:00PM (#10474926) Homepage Journal
    Maybe it will be OK, if it uses persistent HTTP connections, which allow several requests and replies before terminating the transaction. Otherwise the ancient HTTP/1.0 message model is too limited to map all the messaging topology to the spectrum of object management requirements.

    • Re:connect the dots (Score:4, Informative)

      by abigor ( 540274 ) on Friday October 08, 2004 @05:15PM (#10475049)
      Did I miss something? I didn't see any mention of HTTP 1.0, which is obsolete. 1.1 is what's far and away in the most common usage, and it allows pipelined requests.

      That said, SOAP isn't necessarily confined to HTTP transport, though of course in all practical reality it is, for now. But there's no tight binding there.

      Anyway, what does the transport have to do with the "spectrum of object management requirements"? Or am I just not understanding your statement?
      • I'm warning that "Web Services" isn't the answer, if they're puny versions of the Web protocols. The "transport" we're talking about is the protocol, HTTP, for framing the data interrogations and assignments of the management. Which constrains the features to meet the requirements. Fundamental considerations beyond buzzword compliance.

        • Re:connect the dots (Score:3, Informative)

          by abigor ( 540274 )
          Yeah, that's what I thought. And HTTP 1.0 is obsolete. 1.1 has pipelined requests, which takes care of your concern, I believe, although I'm not at all sure it's an issue. What transaction are you talking about? Application transactions would be controlled at a higher level than the transport layer. Or do you mean the HTTP session?

          In web services land, HTTP is just one type of transport. SOAP is decoupled from the transport, so I think your concern is unfounded. Can you give me an example of how HTTP will

          • Re:connect the dots (Score:3, Informative)

            by Black-Man ( 198831 )
            I agree with the original poster. HTTP/Web Services seems a bad idea as a replacement for SNMP. SNMP is solely the domain of servers... but routers, switches and other network devices. And your laying this additional layer of abstraction onto something that is an extremely critical piece of network management. In other words... just something else that will fail.

            I use Web Services too, within the context of Web Logic. There are so many unknowns and reliability issues under the hood. For simple http request
          • Microsoft capitalizes "Web Services" and seems to use it as if it refers to some set of protocols or something. To someone who doesn't bother to keep up on the latest Microsoft buzzwords (the FLOSS world lets you avoid much of that), the idea of "Web Services" being equivalent to "web services" seems unlikely.

            Is "Web Services" just the latest way to say "implemented using SOAP"?
            • Hi, sorry for the late reply.

              To answer your question: yes, more or less. ;) In its most basic form, it is RPC calls made over the Internet. Rather than some binary format (like DCOM or whatever), the RPCs are just text - XML. The template is SOAP (or XMLRPC, if your needs are simple).

              Of course, there are other considerations - security, authentication, and so forth. But those are just extras layered on top. Check out the XMLRPC spec to get a very basic idea of how it works. SOAP is like XMLRPC, but way mo
      • Actually, there are many implemenations of non-HTTP soap implementations. Microsoft Web Services Extensions is one such example, with support for a tcp transport channel.

  • Goodbye SNMP? Hardly. (Score:5, Insightful)

    by cablepHreaK ( 528354 ) on Friday October 08, 2004 @05:01PM (#10474927)
    SNMP is not going anywhere anytime soon, until the major network players adopt WS-Management (that's if they adopt it at all). Looking at the PDF there are some major players missing, Cisco, Juniper, 3Com, HP, to name a few.

    • Re:Goodbye SNMP? Hardly. (Score:5, Insightful)

      by Alan Cox ( 27532 ) on Friday October 08, 2004 @05:05PM (#10474960) Homepage
      Also on the folks churning out billions of tiny little devices. If you've only got 16K of RAM TCP is hard work let along management services while UDP is doable properly on a microcontroller.
      • I'm sure we'll see more UDP bound SOAP standards being implemented. UPnP started it a long time ago, in a propriertary sort of way, meant for small devices. WS-* doesnt descriminate over transport: thats good.

        You got one thing dead right though: RAM is the fundamental limit to tcp/ip. It is really the only excuse for not being able to do tcp/ip. Interesting that microcontrollers havent advanced ram more quickly. I'm still hacking on a 136 byte controller, for example.

        Still seems like if you're going
      • I agree completely - however, I do wish to point out that ASN.1 and BER are a pain to code & maintain. XML is definitely an improvement, but I would argue its flexibility is what is going to fracture it. This is not putting down XML or its use, but on the so-called 'partners' who are involved in this 'deal' have an established pattern of adding their own 'extensions' which defeat interoperability and serve to enforce market share and not true integration.

        If I were doing this, I would take the strenghts
    • SNMP? what is SNMP ? Well SNMP is a "big thing" in the networking environment where all the big players develop their applications based on it for example Network Management Systems.

      SNMP has evolved from time to improving from one version to another from data retrival to security.
      Well its a well establised phenomenom and no one can change it in a day as most of the big fish in this business rely on it to satisfy their appetite.

      Lots and lots of work is undergoin specially in SNMPs 3rd version as most of t
    • yes, HP, IBM, Fujitsu and the other big players are all at work on WS-ResourceFramework [oasis-open.org]

      Which is very suspiciously similar to WS-Management, 'cept for the shorter name and the completely different set of signatories. Both try and provide a distributed "resources" view of SOAP endpoints, because if they were called "Distributed Objects" we'd all realise that the "Distributed Objects bad, Service Oriented Architecture" was so much bollocks.

      Now, the fact that they are fairly similar means there is scope fo

  • War! (Score:5, Funny)

    by nuclear305 ( 674185 ) * on Friday October 08, 2004 @05:01PM (#10474932)
    "Microsoft will build support for WS-Management into an update to Windows Server"

    Clearly this is war! SNMP and M$-Management will battle it out for the top market share...oh wait...
    • And here I was hoping for a decent SNMP server for windows.

    • Re:War! (Score:3, Insightful)

      by ADRA ( 37398 )
      Well, its leagues better than the Windows Management framework with relied on the rarely used (outside windows) DCE-RPC.

      At least there is a 'hope' of interoperability.

  • but the important question is ... (Score:4, Insightful)

    by Triumph The Insult C ( 586706 ) on Friday October 08, 2004 @05:01PM (#10474934) Homepage Journal
    will it be encumbered by patents? looking at the contributors, my guess is yes

    snmp v3 works perfectly fine as it is. let's leave well enough alone

    but, this will probably work out well for intel ... i mean, you'll probably need (by the time it comes out) at least a 3.8Ghz P4 and 2G of RAM
    • Intel doesn't make RAM so the better statement would be:

      you'll need a 3.8GHz P4 and a chipset with a mail co-processor built in.
      -nB

    • Re:but the important question is ... (Score:5, Insightful)

      by justins ( 80659 ) on Friday October 08, 2004 @06:43PM (#10475735) Homepage Journal
      snmp v3 works perfectly fine as it is.

      Are you fucking kidding?

      but, this will probably work out well for intel ... i mean, you'll probably need (by the time it comes out) at least a 3.8Ghz P4 and 2G of RAM

      What an amazingly "Score: 5, Insightful" observation. It's almost enough to make a person believe that Intel doesn't sell more chips for networking and embedded applications than they do desktop CPUs. Which they do.

    • snmp v3... (Score:5, Insightful)

      by bani ( 467531 ) on Friday October 08, 2004 @07:50PM (#10476219)
      snmp v3 works perfectly fine as it is. let's leave well enough alone

      considering most vendors are still using v1 or v2, that should be 'lets leave snmp v3 alone' :)

      to be perfectly honest, SNMP is anything but simple. the only thing simple about it is the protocol itself. it then got buried under avalanches of proprietary MIBs, all partially overlapping yet all mutually incompatible. some only partially documented (or not documented at all). not only that, the insistence of vendors using funky proprietary data types (or worse, strings) when existing datatypes would work perfectly fine.

      what was needed imo was a MIB guideline and 'retarded implementation' verification. to ensure vendors didn't create obfuscated and spaghettified MIBs.
    • "will it be encumbered by patents? looking at the contributors, my guess is yes "

      Insightful? To me insightful would require actually having read the specification.
      If you look at the spec, you'll see the answer to this question.

      "Microsoft, Intel, AMD, Dell, and Sun (collectively, the "Co-Developers") each agree upon request to grant you a license, provided you agree to be bound by such license, under royalty-free and otherwise reasonable, non-discriminatory terms and conditions to their respective patent

  • Cisco? Nortel? (Score:5, Insightful)

    by Linegod ( 9952 ) <pasnakNO@SPAMwarpedsystems.sk.ca> on Friday October 08, 2004 @05:02PM (#10474939) Homepage Journal
    If I don't see Cisco and/or Nortel on the list, it's not going to replace SNMP anytime soon. Correction: _ever_.

    .

  • What about WBEM? (Score:4, Insightful)

    by bnavarro ( 172692 ) on Friday October 08, 2004 @05:03PM (#10474944)
    I thought that the open replacement for SNMP was WBEM [openwbem.org]. Microsoft, in fact, has already implimented this, basically, as WMI [microsoft.com], or Windows Management Instrumentation.

    Anyone know why this is suddenly being pushed, and not WBEM?

  • Interesting to see... (Score:2, Interesting)

    by IGTeRR0r ( 805236 )
    It's interesting to see such diverse companies developing a standard such as this: I can see Microsoft, Intel, and AMD working on something like this, possibly Dell, but why Sun Microsystems?
    • Sun? IBM politics. IBM, HP, Oracle, Cisco are all on the OASIS working group that has been doing an alternative (very similar one BTW) for a year: WS-RF. This is the MS counterpoint, Intel, AMD and dell brought in because they are the rest of the PC industry and do what MS says.

      Sun are probably playing against IBM, even though they still hate MS and Dell. That or supporting MS on random WS specs was part of the sun/MS deal.
  • So... is this anything like WBEM?

    Microsoft has had a "implementation" (term used loosely) of WBEM in windows since as far back as at least Windows 2000 -- except it defined its own little corner of the MIB tree and didnt store anything in the actualy useful standard MIBs.

    Of course, WBEM didnt have any marketing to go with it, so it died.

    then again, at least its another shot to put SNMP in the grave where it belongs. especially before version 3, SNMP is a brutal and unreliable hack. im sure somebody wi

    • but i can promise you that person never used SNMP for any major network management

      I use it all the time with MRTG. Admitedly, I'm only scratching the surface of what SNMP can do, but it works great for what it does. The only big problem I see is a lack of error detection/correction, but considering how widespread SNMP is, I can't see it getting pushed out anytime soon.

      • Re:WBEM? (Score:3, Interesting)

        by SpootFinallyRegister ( 787720 )
        maybe i should clarify -- SNMP for a wide range of devices over a less-than-perfect network can be a nightmare. a lot of heavy iron (routers, PIXs, etc) support SNMP, but a lot only support v2 and v1 -- UDP.

        when a piece of metal needs to be monitored from something that further than a piece or two of cat5 away, being forced into UDP can make SNMP borderline useless. did the packet drop, or is the network down? hmm.. ill use SNMP to see if its the network. hmmm, negative. did the packet drop, or is ... rin

        • you don't understand snmp, it seems.

          it IS a balanced protocol. the reason it uses UDP is BECAUSE of the possibility of the network dropping packets. snmp uses udp and 'manages' it by doing its own serial # and retry mechanism. snmp+udp gives as much reliability as mumble+tcp.

          snmp over tcp has some advantages, but not the ones you are thinking of. I already said that snmp+udp gives sufficient reliability, flow control (etc). so adding extra stuff to an already sufficient solution just adds - well - ex
        • basically, the more ive worked with SNMP, the more ive realized that the "S" is the key letter. it is fantastic for some quick chores ona local reliable network, but just plain doesn't scale. there is a vast array of management and monitoring problems that just arent simple enough for SNMP to handle well.

          Okay, I'm curious. SNMP allows for polling and for requesting feedback on events (traps). It provides exposed data structures that can present scalar values, trees, and multidimensional arrays. I can't
      • it is remarkably difficult to use SNMP through NAT.

        encryption support for SNMP is also very poor. that is, few vendors implement it and it's very cumbersome to use even if it is implemented.

        the huge proprietary convoluted MIBs vendors use also doesnt help much, especially when the documentation on them is poor to nonexistent. it's also very annoying when they use a proprietary MIB when an existing standard one would have fit just as well (or better).
        • >encryption support for SNMP is also very poor. that is, few vendors implement it and it's very cumbersome to use even if it is implemented.

          Most vendors are now supporting DES, and there are implementations that support 3DES and AES.

          cisco has been using snmpv3 for what 6 years in their routers?

  • but... but... (Score:5, Interesting)

    by Anonymous Coward on Friday October 08, 2004 @05:07PM (#10474978)
    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.
    • That's where a group-policy framework tied to the mangement framework like this would be handy. I still don't like Microfts politics, but I'll give it to them that their management tools are easier than *nix and the like.
    • 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.

      You can call a method on a webservice with one line [cpan.org] of perl. Nuff said.

  • Ever heard of CIM? (Score:5, Interesting)

    by ansonyumo ( 210802 ) on Friday October 08, 2004 @05:09PM (#10474996)
    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.

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

      So what?

      I mean, what that moronic thing of replacing everything with this xml-over-http nonsense?

      Everyone is crazy doing the same thing, except it is now all on tcp port 80. It is even impossible to apply any kind of policy without lots of application level analysis because every moron in the world is using HTTP to do everything.

      SNMP is fine, and if the only thing that those people are trying t

      • My point of mentioning that CIM has a XML-based RPC protocol was only to show how WS-Management doesn't offer anything new. The common approach is to use a more efficient protocol like Java's RMI, but the XML option is there in case you need to support communications between CIMOMs that don't share a common, binary RPC protocol.

        Regarding SNMP v/s CIM, that is a lot like arguing C v/s C++ (or religion, for that matter). Don't want to go there.
    • Everyone I know who has worked with CIM hates it. Maybe you have had a better experience. too many objects, too dictatorial a model. They even have a model for help desks and support calls. That is way over the top.
      • The CIM schema does boggle the mind. It is huge and models things that seem downright silly. Finding the correct place in the tree for parenting your subclass can be, at least, time consuming.

        However, you aren't forced to use the schema. From what I have seen, most of the software that exposes management through CIM declares a new namespace and forgoes use of the CIM schema altogether.

  • Bandwidth overhead (Score:3, Interesting)

    by embeejay ( 446541 ) on Friday October 08, 2004 @05:09PM (#10474998)
    Using webservices for something like this seems like an enormous bandwidth waste to me. Whatever happened to optimization?
    • Whatever happened to optimalization? It was replaced by better, more sturdy protocols that are more dynamic and - sometimes - easier to understand.

      You do have a point however, but not about the bandwidth. More importantly the network appliance now has to do HTTP and XML processing, something that takes a lot of memory (especially if implemented incorrectly).

      I expect that most appliances won't have a problem with this, but it is something to think about. Especially for small, cheap devices. These can keep

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

      Well... It's obsolete...

      Let me put it this way: back in about 1990, my computer had whopping 1MB memory and whopping 40MB hard drive. Today, my *video card* has 256MB memory, the computer itself has a gig, with 180GB hard drive.

      Sure, SNMP will still have its place in embedded devices. However, even embedded devices today are much more powerful than they used to be. As for works

    • Re:Bandwidth overhead (Score:3, Interesting)

      by Anonymous Coward
      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

  • The 'gotcha' (Score:5, Funny)

    by Tenebrious1 ( 530949 ) on Friday October 08, 2004 @05:13PM (#10475037) Homepage
    To ensure interoperability of devices and to enable any one console to manage any device, there will now be the standard default login "BILL" and password of "MOMONEY" for all devices. Users are not advised to change any passwords otherwise universal control will not be achieved.

  • I'm not sold (Score:5, Interesting)

    by KidSock ( 150684 ) on Friday October 08, 2004 @05:22PM (#10475094)
    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.
    • If you look at the companys, its geared toward software companys, with AMD and Intel thrown in since The (Intel anyways) always wants a say in standards like this. Maybe their affraid of other chip vendors from putting this embedded on chips giving them the advantage..

      I can't say positive of negative on the news. Its a standard, and no matter what standard, it needs adoption and tools support. A new-technology for the sake of itself doesn't make the market jump, and I doubt that anyone 'using' the systems

    • Comment removed (Score:5, Informative)

      by account_deleted ( 4530225 ) on Friday October 08, 2004 @05:40PM (#10475240)
      Comment removed based on user account deletion
      • The SNMP MIB tree is hierarchical.

        That wasn't my point. What does:

        ucdavis

        give you? The database may be hierarchical but the data in messages is not. If the response is XML with one round trip you can retrieve an entire tree of information.

        But you're right about traps. I didn't think they were that sophisticated.

    • If you have a problem with snmp then fix it.

      I think anyone who has used SNMP in applications enough to acquire a nice, healthy hatred for it would agree: it's not fixable. I'm not saying this is the solution, but SNMP really does belong in the garbage.

      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.

      Too bad SNMP and its

      • I am just literate enough in the subject matter to know what SNMP is basically. I have not implemented anything, nor dealt with it in any meaningfull way.

        My question is: what is broken about it particularly? I am a programmer, so dont make the answer too "dumbed down".

        Genuinely curious.
        Thanks,
        David
        • My question is: what is broken about it particularly? I am a programmer, so dont make the answer too "dumbed down".

          Oh, easy answer then. Go download net-snmp (it's free!) and try to do something useful with it, talk to one of your snmp-enabled devices or something. While doing so remember that it's all supposed to be quite "simple" and robust.

          I don't recall seing any great primers on SNMP.
          • Go download net-snmp (it's free!) and try to do something useful with it, ...

            When I said "simple" I meant the protocol should be simple to conserve resources and reduce the potential for exploits. If you're having problems with a particular implementation I don't think that qualifies as an argument against the protocol. Using an XML/HTTP based implementation isn't necessarily going to be easier.

            • When I said "simple" I meant the protocol should be simple to conserve resources and reduce the potential for exploits. If you're having problems with a particular implementation I don't think that qualifies as an argument against the protocol.

              That would be a fair point except that all the implementations suck. It's not like there are just a few places where you can point the finger.

              Using an XML/HTTP based implementation isn't necessarily going to be easier.

              Now that, I certainly agree with.

  • Wow. (Score:3, Interesting)

    by ARRRLovin ( 807926 ) on Friday October 08, 2004 @05:27PM (#10475142)
    I can totally see this standard easily integrating with the 1000+ network element monitoring and statistics gathering software package that I use right now. /sarcasm

    It was a PITA enough just to get all of the devices reporting to the same polling engines. I can't even imagine going through and changing it all to some halfassed XML implementation. If they really want it to be an "SNMP replacement", they should just improve on what's already available. Make it compatible with SNMP but more powerful.

  • They still have work to do... (Score:4, Funny)

    by LodCrappo ( 705968 ) on Friday October 08, 2004 @05:28PM (#10475150)
    This new protocol simply cannot be adopted until it's fully acronymic... I mean come on, SNMP and WBEM and even CIM have been fully acronymous for some time now, and this WS-Management thing still has an entire word spelled out in the name? That won't fly in my shop, no sir.

  • Not everything from MS is evil (Score:3, Interesting)

    by Fnkmaster ( 89084 ) on Friday October 08, 2004 @05:39PM (#10475229)
    This looks like it's supported by a number of industry players, and the specification is under a real patent-right-granting, royalty-free license, not like the junk that MS occasionally tries to "innovate" the market with. I'm not saying it will sweep the world or replace all the SNMP devices out there, but I'll give them an A for effort to play nicely on this one.


    People are more likely to adopt standards that they can implement without getting sued or shelling out large quantities of money to be allowed to adhere to. Despite the comments about the protocol being heavier than SNMP (TCP based, SOAP envelopes, etc.) I think there are cases where a richer, more extensible XML-based syntax would be nice for this kind of application. Or maybe SNMP is "good enough" that adoption will be limited (hard to say without reading the whole spec and comparing), but I don't think crapping on it just because it's Microsoft is fair, at least during those rare moments when they are playing well with others.

  • This has probably been covered elsewhere, but I found that Tim Bray's short essay on WS-Overload summed it up better than I could have:

    "I'm going to stay out of the way and watch the WS-visionaries and WS-dreamers and WS-evangelists go ahead and WS-build their WS-future. Because I've been wrong before, and maybe they'll come up with something that WS-works and people want to WS-use. And if they do that, I'll stand up and say 'I was WS-wrong.'

    Worth a look: http://tbray.org/ongoing/When/200x/2004/09/18/WS- [tbray.org]

    • The problem with tbray's rant is that no one expects us to deal with the "insane WS stack". That's what frameworks are for. I expect that if I'm using Java, .NET, Python or Perl that I'll have some sort of structural wrapper around the stuff. I'll leave the nitty-gritty to Don Box and friends, who actually get paid to come up with these things.

      Besides, the nice thing about standards is that there is so many of them to choose from.

  • rm -rf WS-*

  • Jabber instead (Score:4, Interesting)

    by hey ( 83763 ) on Friday October 08, 2004 @05:48PM (#10475293) Journal
    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.
    • 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.

      Almost certainly. Did you know that you can use DNS as a VOIP protocol?

      Real question is whether it is any good in that mode and whether people are prepared to support that specification.

      There are a couple of reasons why WS-Management is useful, the most impo

    • Mod parent up! Though a bit heavy for many tiny devices, Jabber makes a lot of sense...

      -sid
    • Don't forget you can use XMPP as a transport for basically anything, and this WS-thing is certainly no exception. There is even an experimental JEP [jabber.org] on transporting SOAP over Jabber.

  • Ummm... (Score:3)

    by necro2607 ( 771790 ) on Friday October 08, 2004 @05:50PM (#10475299)
    Doesn't this sound like the kind of solution that would be primarily software-based?

    Despite that, the only largely software-based companies involved are two VERY proprietary-obsessed companies??

    Meanwhile, what can AMD and Intel offer to such a solution? Since when are they involved in building new networking-related systems?

    Also, someone else on here brought up the issue of patent-encumbered technology. This will *definitely* be an issue with these vendors/manufacturers, seeing as they'll all be interested merely in their capital gain as opposed to simply contributing to the general technological advancement of the internet/networks in general...

    "WS-Management can also be used to manage things like set-top boxes and TiVo-like digital video recorders"

    Yup, all containing AMD or Intel CPUs, running an embedded MS/Sun OS... now we see why the CPU manufacturers are involved...

    Am I the only one getting sick of hearing about these new "great" proposals made by huge companies when their true intent is blatantly obvious? SNMP *works*, yet for some reason, as usual, some big company has to come along and try and run it over with their new crippleware, claiming it's the New & Improved (tm) version of whatever it was that worked just fine before...

  • What about JMX (Score:3, Informative)

    by ghost1911 ( 146095 ) on Friday October 08, 2004 @05:59PM (#10475387) Homepage
    Nobody else seemed to mention this yet so I thought I'd point out that Sun seems to be contradicting their latest monitoring framework:

    JMX [sun.com]

    By going along with this new specification. Network Management, monitoring, and other SNMP-like operations in Java are moving to the JMX or java media extension framework. In Java 5, the VM has JMX hooks built in for monitoring and control. Alas, I have to agree that SNMP is tired and old, but it still is in place in a lot of environments (and in routers, firewalls, and other hardware appliances) and is really easy to interface and use. I doubt this will catch on very quickly...
  • How is it possible in this era of security issues that new standards are still being drawn up without security being a requirement?
  • "Microsoft will build support for WS-Management into an update to Windows Server"

    Once this support is built, I have a feeling that if you so much as ping a Windows server, regardless of whether it's enabled, it'll instantly give you full-administrator in some fun only-by-Microsoft way. Combining IIS and the management level that they're talking about seems to just beg for disaster.

    --sean

  • Why should I or should I not quit SNMP (Score:3, Informative)

    by thanasakis ( 225405 ) on Friday October 08, 2004 @07:07PM (#10475930)
    Ok, lets try to summarize why we like SNMP:
    -Implementations can fit in a few kb memory footprint. I don't see web services beating that any time soon. (Oh, and not all the devices on the planet are 4Ghz P4's with a gigabyte of ram so it is still important not to be a memory hog on many areas).
    -For relatively simple purposes, S(imple)NMP is almost as simple as it gets. Like say, for the monitoring of the temperature of a router, using something like web services would surely be overkill.
    -There are many implementations for your favorite unix flavor. Probably best is the excelent net-snmp [sourceforge.net] package. The 5.x version has many new methods of extending the main agent instrumentation through compiled in modules, dynamicaly loadable modules, external (pass) scripts, even embedded perl. Solaris 10 will be using the net-snmp package as part of the standard installation.
    -The protocol is extremely efficient so there is little presure on the underlying medium. The PDU's are encoded in BER, so the implementations are abundant and quite standard. And yes, this is very very important because practicaly all versions of agents and toolkits are 100% compatible between them.
    -Because the SMI is defined in ASN.1, there is no ambiguity in the structure of the management information. See previous bullet why this is important.
    -There are excellent tools like HP OpenView NNM which can really simplify monitoring of even extremely large networks.

    Now let's see some of its disadvantages:
    -Poor security, corrected in version 3 (somewhat complex) but still most people use version 1 or 2c.
    -Setable objects are IMHO a nightmare to use. For those of you who are reloading their router by setting sysUpTime to 0, I may seem dead wrong, but it appears that most people's safe bet would be just to log in to the machine and do the job they want. To generalize that idea, SNMP is unbeatable when it comes to monitoring things, but when it comes to actualy controlling things from away, it loses. Perhaps that is exactly the niche that those web services will complement (not replace!) SNMP.
    -Extremely difficult to describe complex data structures using SMI. But then again I may be too impatient.

    Lastly, though it will sound bitter, there is no clear evidence that web services or WBEM or whatever will be able to actualy help network administrators do their job better than they do it today.

    And remember everyone, there is no big company that can necessarily know your job and your needs better than you, as much as they profess to. So on this matter we must not take the word of those who are trying to sell us the New Management Ubertool but on the contrary try to evaluate it in the real world and figure out if it actualy is usefull or not.

    And that's my five cents for tonight.

    • vendors using retarded convoluted proprietary MIBs when an existing standard one would work just as well (or better).

      vendors using proprietary datatypes (or strings) when existing standard datatypes work just fine. laziness? stupidity? beats me.

      SNMP also works very poorly through NAT. or lossy/high latency WANs.

      vendors seem to think the 'simple' in SNMP means they can cut corners and do a minimal implementation, so you get devices which crash when you request large sets of data. a simple snmpwalk can cra
  • Everything these guys touch turns into a bloated mess. We run thousands of web service transactions a day at work and not a single one of them uses anything WS and or SOAP related. We choose to stick with xml-rpc since it is simple yet powerful. There is not a single reason so far that we could come up with that would justify us moving to WS and SOAP.
  • If it guarantees delivery it would be much better. SNMP is udp and there is no way to know if the trap was recieved.

    I've seen systems that are snmp based, where a cluster is used, and if the system has a fail-over many old traps are read again and alerted on. I think if the sending application can get an acknowledgement from the central app (netiq, netcool, compaq insight manager, tivoli, hp openview, etc) these type of false alerts would go away. When the sender can see the alert as a transaction it el
  • There still seems to be a trend to XML-ize everything that I just don't understand.

    If I was to build a cheap DSL modem, switch, IP camera or wireless gateway, I would probably be working with an 8/16 bit processor and limited memory to save money. In such a case, I would want to minimize my code and memory footprint and my CPU requirements.

    Now lets look at XML. It is a bloated, complex, textual way of representing information. It requires some sort of a parser to read requests and storage of strings rat

  • security issue (Score:2, Interesting)

    by radonix ( 820461 )
    I think the idea is a good one, however it is prone to a security risk. A website has a domain name, these can easily be remembered and found by using a search engine. Now lets say you have this WS Management software, what good is it if it is run on a domain to control systems, because it could be searched and found out easily, this would mean that blackhat hackers would have an easy time finding out where to access the management software, and then they could proceed to gain access to it through exploit

Slashdot Top Deals

"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell

Close