WS-Bandwagon or WS-JustRight?

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

Comments (1)

  1. Len Bullard says:

    It will be interesting to see if the WS series is an accelerant or a retardant.  It may be both to different people at different times and that may just be a blessing.

    Sitting here watching my team wrestle down NET2.0, Visual Studio and SQL Server 2005, realizing that while I am comfortable with Response.write, server controls are an unfolding mystery, I am convinced that the WS vs REST is not as much a cry about elegance and some instinctive resistance to churn.  How often do industries renovate the fundamentals of building systems as often as we have since the web was launched.  At the time when asked what it would mean, relying on my studies into cybernetics, complexity and chaos, and operant conditioning, all I could say was "Things will change faster" and so far that’s been true.

    But operant conditioning predicts too much change too fast makes for a very nervous rat that begins to bite the hand that feeds it.  Then the little things like "why CAN’T we put the images in the APP_DATA directory and if we can’t, WHY DOESN’T the MS DOC SAY SO!!!#@$#" begin to drive the rats nuts.

    The cry for REST is a cry for simplicity but we do it by making it harder for someone somewhere else.   After learning n-tier, we are told we are going back to two-tier because SQL Server stored procedures are now way more powerful and why not have the data server do the heavy lifting.  That should make Michael Rys happy but I have to wonder how many paradigm changes one can absorb in a career or even a project before the spectre of Charles Babbage wandering muttering among the ever smaller boxes of labeled parts begins to haunt us.

    The web is a car careening from turn to turn down the mountain.  As Max Baer tells Bea Bennaderet when they finally stop at the Clampett cabin and she asks him why he didn’t get rid of the brakes like she told him to, "I did, Ma.  That’s why we ain’t got none."

    I mean, I enjoy the ride but those stops are pretty fearful.