My previous post used WS-Management to illustrate the larger point that "the WS technologies are taking hold, deep down in the infrastructure, doing the mundane but mission critical work for which they were designed." Perhaps because WS-Management is one of the more controversial bits of the WS-* infrastructure, that example stimulated more pushback than the other example I used -- the increasing success of the WS-* based identity metasystem (which is a lot more newsworthy at the moment). But it's easy to justify the value of standards and open source work in the identity space, where the prevalence of phishing indicates that the web does not have a good native story that falls out of the REST architecture. Let's look more closely at the harder question of why WS-Management exists and why it is gaining traction.
A couple of points in reply to comments on the earlier post:
WS-Management leverages some key benefits of SOAP such as its protocol neutrality while adopting some of the REST abstractions to avoid the complexity of an RPC API for all possible management service invocations. In other words, it exemplifies what Jon Udell calls WS-JustRight for its intended domain: "I stand by what I’ve been saying all along, in a variety of places including this InfoWorld cover story: there’s WS-Heavy, there’s WS-Lite, and for every situation there’s a WS-JustRight that may rely on elements of one, the other, or both. The Richardson/Ruby book brings much-needed clarity to the WS-Lite end of the tolerance continuum, and that’s a great thing. But when we celebrate one end of the continuum, why must we deprecate the other?"