No surprise, but I have problems with Mike Champion's recent argument in favor of WS-*...
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.My main problem with his argument is this: I do not believe technical reasoning was used in the decisions to use WS-* in these apparently "non-HTTP" situations. To some degree my beliefs are based on direct conversations with people involved with WS-Management.
The decision to go WS-* in this case was made like this: WS-* is the future for integration, system management requires integration, so we'll use WS-*.
This is not to mention the fact that ws-management is essentially a shell of a solution with little agreement on what goes in that shell.
Other problems with his argument include no explanation about what "where the web-scale alternatives really don't fit". I am not necessarily of the sort that everything has to be HTTP, but then again, HTTP has been implemented on some pretty tight spaces and processors. I'd like to see the evidence that HTTP is not suitable for certain ws-management scenarios. I assume ws-management still specifies a fair bit of verbose XML over those supposedly tight spaces. Hmm.
It is precisely this lack of rigor that has failed ws-* from the start. There's nothing new or significant in Mike's argument that I can see.