XML Journal published an article today on the OASIS WSDM (web services distributed management standard). Having been involved from day-1 with WSDM, I thought I could give a bit of color commentary on the standard. The good, the bad, and the ugly...
As the article outlined, there are two parts to WSDM: MUWS (management using web services) and MOWS (management of web services).
Easiest way to think of MUWS is that it is web-service-based replacement for SNMP. Unlike SNMP, it is - shock of all shocks - secure! And it can be reliable (by leveraging WS-ReliableMessaging). And you don't need to understand arcane wire protocols like ASN.1 just to work with the standard. Right now, to support SNMP in a product, you essentially need to buy a 3rd party library since the protocol is so complicated. With MUWS, all you really need is a web service protocol stack and you can fairly easily support the standard. While WUWS is a heavier weight than I would have liked, it's still lightyears easier to work with than SNMP or other similar protocols. The SOA security issues, together with the ease-of-use issues are the two key reasons I think MUWS will (eventually... in many many years) replace SNMP.
MOWS is something quite different. MOWS defines what control and visibility you have into a web service (you can start/stop it, you can see the response times, etc.). While MOWS 1.0 is an important stepping stone, unfortunately we'll have to wait until MOWS 2.0 for most real-world use cases. The reason is that MOWS 1.0 is focused on metrics about the service not about its operations. For example, with an ordering service you could see that there were 1000 requests to the service with an average response time of 250ms and where 8 of the requests had faults. This issue is that this service might have two operations (create and query) that have dramatically different usage:
create might have 10 requests, with an average response time of 10s, and with 8 faults (an 80% failure rate!)
query might have 990 requests, with an average response time of 152ms, with no faults
The issue is that the service-wide averages are meaningless. You might see a 0.8% failure rate and think that everything is OK when, in reality, you have a 80% failure rate of your revenue producing requests.
Unfortunately, we'll have to wait until MOWS 2.0 to get operation level metrics. Until then, MOWS 1.0 is good for interoperability testing and demos, but I suspect it won't be leveraged much in the real world. Don't get me wrong, MOWS is important -- it's just not ready for prime time yet.