WS-Bandwagon or WS-JustRight?

  • Article

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: 

  • It overlaps in functionality with WSDM, another family of specs, and this overlap is a source of friction between the MS and IBM web services stories.  I won't get into the history or politics here other than to speculate that WS-Management is a classic example of the Pareto Principle -- it does quite a bit less than WSDM (maybe 20% of the functionality and complexity of WSDM), but its relative simplicity makes it easier to implement while being good enough for 80% of the important use cases.  So, even in the allegedly pathological WS ecosystem, evolution favors the simple and functional over the the more highly but complexly designed.
  • Why didn't something even simpler and more RESTful evolve, which Patrick Logan's comment suggests would have been easy?  I don't know the history, but it's clear that REST concepts were in fact leveraged to keep the spec relatively simple.  Patrick also pushed back that that it is a "shell of a solution with little agreement on what goes into the shell." REST is also a "shell of a solution", and WS-Management adopts the same basic approach to allow late binding to the resources in a catalog rather than tight coupling to a predefined set of objects.
  • Why not just use HTTP rather than WS-Transfer?  I created a bit of contention by asserting that WS-Man is designed for use "in situations where the web-scale alternatives really don't fit, such as deep within operating systems or in the firmware of chips".  A number of people pointed out (probably correctly, but I don't really know) that an HTTP implementation would "fit" in the same amount of code or memory as a WS-Transfer implementation.  That being as it may, I meant "fit" in the architectural sense -- I thought the common REST argument that HTTP is an application protocol indicated that it would not "fit" so deep down in the stack as the firmware on a chip or device.  More significantly, HTTP does "fit" on top of TCP/IP, but WS-Management was designed for use in situations where only UDP network services are available.  
  • Whether or not the designers were simply riding the WS bandwagon rather than thinking hard about RESTful alternatives,  WS-Management sits on a number of WS specs, not just WS-Transfer.  By building on WS-* they could leverage services that HTTP does not provide.  WS-Eventing provides asynchronous "push"  notifications, WS-Enumeration supports the traversal of collections of resources, and WS-Security, WS-Trust, and WS-SecureConversation provide a security infrastructure.

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?"