WS-* Usage
Mike Champion defends WS-*, using WS-Management as one example:
On closer examination, WS-Management is widely used today in situations where the web-scale alternatives really don’t fit, such as deep within operating systems or in the firmware of chips.
Sorry, unconvincing. I plainly refuse to believe that something capable of processing WS-Transfer, WS-Management, SOAP, XML (all over TCP, as the bare minimum) doesn’t have enough power to run HTTP.
Likewise, I don’t believe the term “pragmatic ubiquity” belongs anywhere near a WS -* spec.
OK, let’s assume that chip firmware could run an HTTP server just as easily. Then what? What else would be neede to provide the actual functionality that the device management ecosystem needs? When all that is added in, what have you gained over WS-Management? How would you persuade one of HP’s competitors that doing that would give them an edge over the WS-Lemmings?
There’s no doubt that the WS-* stack could be replaced by something “better”, given what we know in hindsight. So could XML, HTTP, TCP, etc. (e.g. to make spamming and phishing harder). The trouble is, the network effect of all that “good enough” stuff greatly outweighs the benefit of the “better”. For example, your hypothetical REST-Management device manufacturer would not only have to figure out a better way to expose a management interface using HTTP rather than WS-Transfer, but would have to get the systems management vendors to support it. Sheesh, one of them already thinks that WS-Management is way too simple; check out WS-DistributedManagement, lots of luck persuading them that the world needs something even simpler than WS-Management.
Mike,
I believe there are two ways to approach this discussion.
The first one is this: Whatever the respective merits of WS-* vs. REST/HTTP are, WS-Management and friends is already implemented in some environments, e.g. Microsoft’s, and to change it to something else — even something better — would be prohibitively expensive. Except for the cost, which I cannot estimate, I can live with this reasoning: it basically says: we were wrong, sorry, but now we have to live with it. But that was not how this discussion started, I believe.
The other approach is based only on the relative technical merits. And I see absolutely nothing that WS-Transfer adds over HTTP — and HTTP was there first, for a very long time, so WS-Transfer is not improved upon by HTTP; rather it offered a new, untested and pretty bad solution to a problem that was solved a long time ago.
Regarding WSDM (which I don’t like at all), I believe it did not intend to improve on WS-Management since IIRC it was there first. Nevermind, though.
Regarding WS-Management, I believe a standard with equivalent functionality would be rather trivial based on plain HTTP; I know that at the moment, there is no willingness to do so, but let’s check again in a couple of years.
Basically, it seems to me you’re asking me to defend the idea that HTTP is an improvement over WS-, while I’m only asking you to acknowledge that it was the WS- proponents that claimed their architecture was an improvement over HTTP (which, in the end, more and more people acknowledge it isn’t).
I’m not following. “we were wrong, sorry” — who was wrong, and why?
As for the technical merits, WS-Transfer is indpendent of underlying protocol, and HTTP is dependent (IIRC) on TCP, and the PUT and DELETE verbs are not widely supported. That, and the basic idea that a SOAP message should be self-contained and binding-neutral, I think are the only reasons the WS-Transfer exists. Debatable, definitely, but “bad”?
The way I understand the history, WSDM came first; Microsoft declined to participate because it seemed like overkill for the immediate problems at hand, and with a different set of partners created WS-Management. Whatever the technical merits and market share of each, I don’t buy the notion that the first standard to plant the flag in some domain owns it forever.
“I’m only asking you to acknowledge that it was the WS- proponents that claimed their architecture was an improvement over HTTP”. I’m not sure if “improvement” is the right word, but I basically agree: Once HTTP was used extensively to POST commands to server-side software that did real business transactions, some of HTTP’s limitations became problematic, e.g. the lack of an end-to-end reliability model, the lack of an identity system, the hand-coded RPC code behind early websites, etc. I don’t know how much the early WS work was driven by these concerns with HTTP. The way I understood it at the time, Microsoft owned the desktop and needed to get to the enterprise infrastructure because that is where the real money is; IBM owned the infrastructure but needed to get to the desktop, because that’s where the actual users are; HTTP was the means to get between the desktop and the mid-tier, and below that is all sorts of stuff that can’t be changed but will outlive us all. So, WS was a modus vivendi among MS, IBM, and the mid-tier vendors; the idea that it was somehow in opposition to HTTP emerged later (late 2001-early 2002).
IMHO the question of whether HTTP is an improvement on WS-* or vice versa has a simple but unsatisfying answer: “mu” http://en.wikipedia.org/wiki/Mu_%28negative%29 . Improvement with respect to what? Richness or reachiness? Accessibility or security? Browser-friendliness or IT infrastructure-friendliness? We could spend eternity meditating on whether WS-* has Web-nature … or we could just build stuff with what appears to be the right tool for the job, and learn from the results.