May 26, 2007
@ 01:00 AM

Mike Champion has a blog post entitled WS-* and the Hype Cycle where he writes

There's a persistent theme talked up by WS-*ophobes that it's all just a fad, rapidly sliding down toward the "Trough of Dilillusionment" in the Gartner Hype Cycle. I've come to the opposite conclusion after six weeks back in the web services world.  The WS technologies are taking hold, deep down in the infrastructure, doing the mundane but mission critical work for which they were designed. Let's consider one example, WS-Management, which I had barely heard of when I started in CSD Interoperability.
At first glance this appears to duplicate widely deployed bits of the web.  For example, it depends on the oft-criticized WS-Transfer spec, and some are advocating using Atom and the Atom Publishing Protocol rather than WS-* for describing collections and subscribing to notifications of their contents.  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.
In short, from what I have learned recently, the trajectory of WS-* isn't pointing toward oblivion, it looks headed toward the same sort of pragmatic ubiquity that XML has achieved.  That's not to say all is rosy; there is lots of confusion and dissension, again just like there was in the early days of the Web and XML.   Likewise, "ubiquity" doesn't mean that the WS technologies are the best or the only option across the board,  but that it they are increasingly available as a very viable option when developers need protocol-neutrality, security, identity, management capability, etc.

I was going to post a response when I first read his post on Monday but I decided to wait a few days because I couldn't think of anything nice to say about this post and Mike Champion is someone I consider a friend. After a few days of calm reflection, the only thing I can say about this post is...So what?

It seems Mike is trying to argue that contrary to popular belief WS-* technologies are still useful for something. Seriously, who cares? The general craptacular nature of WS-* technologies was a major concern when people were marketing them as a way to build services on the Web. Now it is quite obvious to anyone with a clue about Web development that this is not the case. 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.

Now if WS-* technologies wants to own the niche of one proprietary platform technology talking to another in a homogeneous, closed environment...who cares? Good riddance I say. Just keep that shit off the Web.


Saturday, May 26, 2007 5:45:58 AM (GMT Daylight Time, UTC+01:00)
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.
Saturday, May 26, 2007 7:38:14 AM (GMT Daylight Time, UTC+01:00)
" 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.
Saturday, May 26, 2007 2:44:17 PM (GMT Daylight Time, UTC+01:00)
The problem with WS-* is that the technology is too complex and inflexible for it to ever really "disappear" into the infrastructure. On the specific issue of representing identity in loosely coupled distributed environments, from my perspective the reason that WS-* has gotten any traction there is an accident of history. The big vendors started working on these technologies at the height of the WS-* hype storm.

There are definitely easier ways to solve this problem (see OpenID, Yahoo! BBAuth, etc) and in fact it is somewhat funny to read posts like where you see people complaining that RESTful Web-centric approaches are reinventing WS-* technologies.

Since all the big vendors have already taken the bet on WS-* in this space and the big Web companies are happy to roll their own solutions, I doubt we'll ever see a "standardized" Web-like end to end solution in the area of distributed identity and trust. Of course, "standardization" doesn't mean much at the end of the day when it comes to being successful on the Web (see RSS and XMLHttpRequest).

PS: I do agree that a service oriented approach is a lot easier to map most existing systems to than a resource oriented approach. It is up to the entities exposing the service to decide if the benefits are worth the additional costs that come from a redesign of their conceptual model and interfaces.
Saturday, May 26, 2007 6:16:55 PM (GMT Daylight Time, UTC+01:00)
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.
Wednesday, May 30, 2007 1:38:22 PM (GMT Daylight Time, UTC+01:00)
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.
Sunday, June 3, 2007 9:30:22 PM (GMT Daylight Time, UTC+01:00)
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.

Comments are closed.