Thanks for saying that. It saved me from having to.

It's really unfortunate Mike has chosen that path for his career, when he could be applying his expertise to technology with a future. I *know* he gets the value of constrained-interface styles like tuple spaces, because IIRC he worked with Roguewave on Ruple when at SAG. And I know he at least partially understands the relationship between tuple spaces and REST, because he talked about it at XML 2005(?). I wish I knew the reason he opted for this path.

" None of the major Web companies or "Web 2.0" sites is taking a big bet on WS-* Web services for providing APIs on the Web, on the other hand they all are providing RESTful XML or JSON Web services." Nor should they, and nor should they have hyped WS-* to suggest that it would add any value typical Web applications. As I understand it, however, Live makes use of WS-* to synch up with behind-the-scenes enterprisey stuff, which is where WS-* is intended to add value.

"Who cares"? Definitely not those who build apps focused on retrieving public information where the identity of the user doesn't matter all that much and failure is an option with few bad consequences. On the other hand, people dealing with confidential information where the identity of the user and operation failures cause bad things to happen in the real world do tend to care about the services that WS-* claims to provide. If you're Google or MS or Yahoo you can hire really smart and experienced people who know how to make this stuff happen on the Web, no dobut about it. A lot of others, however, need to deal with "one proprietary platform technology talking to another in a homogeneous, closed environment...", and they don't want to do rocket science or hire rocket scientists to make this happen. The point of WS-* is to put these services down in the infrastructure, which usually includes but is not confined to the Web. A lot of it is pretty mundane stuff, but that was my point: Just as XML found its niche in mundane places like config files and subscription lists rather than living up to the early hype, WS-* is succeeding in similar ways.

The one area in which I've seen real interest in putting this stuff on the Web itself is identity and security. The principal arguments are over which set of WS specs are needed and which set of players will define the "standards", not between REST-based and WS-* based solutions. The "identity metasytem" (Windows Cardspace and other commercial and OSS information card technologies) seems to be getting real traction on the Web as well as the enterprise. I don't see a credible REST/POX alternative to the WS-based stuff in this area, and that's after listening to a lot of discussion of Web security issues at the recent W3C advisory committee meeting.

And thanks for the career advice Mark :-) I still haven't figured out why the tuple space idea gets so little real world traction. Maybe it's like the firm conviction many people have that if only the industry had stuck to LISP, we wouldn't need XML, the numerous dynamic languages, etc. etc. -- possibly right in hindsight, but a bit irrelevant in a "worse is better" world. The strength of the service-oriented approach as opposed to a resource-oriented or spaces-oriented approach, is that it is a whole lot easier to map those unconstrained verbs to the existing software infrastructure that nobody dares to rewrite than it would be to reconceptualize it using some unfamiliar paradigm. Maybe that will happen someday, but I'm still not seeing the existence proofs.

I generally agree, although I don't know enough about the identity technologies to predict how that will shake out.

I would push back a bit on the prediction that WS-* 'is too complex and inflexible for it to ever really "disappear" into the infrastructure.' My existence proof for a nightmarishly complex infrastructure that just works (more or less) is telecommunications. WS-* looks clean and sane (technically and politically) compared to the morass of protocols and standards involved when you dial a landline number on your cellphone.

Dare-- I appreciate that your focus is principally on 'web 2.0' applications and technologies, but it's opportune to remember that not every problem that businesses are trying to solve today, including some that use or involve the web, is readily amenable to a JSON or RESTful solution. We (at Cape Clear Software) have a large number of customers doing a lot of business-critical things in very distributed systems using precisely the 'craptacular' WS-* approach which you decry. When you need (genuine) end-to-end reliability and recoverability for long-running transactions, WS-* (and BPEL) work very nicely. We're now also working with a new generation of SaaS vendors for whom this is an acute difficulty, and for whose customers, for a variety of reasons, 'use this RESTful API' is generally not a viable approach to the problem of uploading, synchronizing and constantly updating large data sets and complex business processes.

This shit mightn't be as glamorous as facebook or silverlight, but it is the best approach I've seen to solving this class of business probems (and I worked in CORBA, J2EE and EAI-- admittedly none of them paragons of usability...). I think it has relevance and resonance as applications move from on-premise to hosted. It is also amenable to good tooling, which can hide much of the inevitable complexity. This problem space mightn't interest you personally, but I find your offhand dismissal a little pejorative.

I think you have gone off on a tangent there Dare.

You should look into infrastructure bits and pick out where they cannot be mapped onto REST or Web. Or why they cannot be baked in in anything? Have you found any to justify your comment? It is up to you to decide when you want to or not if you found something restrictive.

I doubt Web needs to need anything about it, just watch it materialise. LISP and telecoms is a great example, the former more worrying than anything else.

Also I see more deployments out there that you suggest, that are near enabled, they just don't know how to flick it on :)

Saving Mark from saying anything is like saying HTTP is the only thing that exists and cool because it is cool. Typical lack of experience and no work done out on the field.