When and how to use REST

WSDL is moving to the fore as the core foundation standard of web services, with both SOAP and UDDI seen as often useful but still optional extras. SOAP is great for easily exposing existing functionality as a web service, or for quickly creating a client application to consume a web service. But often times SOAP is overkill, and in those circumstances REST provides a simpler and more elegant solution, for reasons that XML.com's Kendall Clark eloquently sets out this week in his column Webs At Rest and In Motion:

Using REST principles is about as prudentially wise a choice as a Web developer can make. REST is safe because it is the architectural style of the Web itself, and, despite its flaws and warts, the Web just plain works and has been working, billions and billions of times every single hour, for years.

WSDL can be used to reference a web service whether it's formulated in REST or SOAP (though not all toolkits currently support REST formulations, which is something the vendors are working on in response to the recent interest in REST), and REST proponents are mostly happy with WSDL (bar the usual suspects). So it looks as though REST will become accepted as a mainstream alternative to SOAP, with WSDL acting as the neutral go-between (for more background on SOAP vs REST, see my posting last week).

Because developers find SOAP more convenient to use, it will often be their first choice when implementing a web service. But I suspect that in many cases they will end up going back and refactoring it out of the application in favor of REST, in order to reach out to a broader universe with less overhead.

Having said that, Kendall Clark goes on to note that there is as yet no accumulated best practice for how to build web applications using REST, and reports on some suggestions that have been made in recent weeks by members of the rest-discuss mailing list. "I think it's worth noting briefly that many REST best practices, at least as the rest-discuss list formulates them, are what we might otherwise have called the aesthetics of URI design," he notes, and goes on to set out a list of recommendations suggested in the discussion.

The discussion list is currently in the throes of examining how REST interacts with WebDAV's resource management capabilities, he reports, and is clearly recommended reading for anyone interested in keeping abreast of REST.

posted by Phil Wainewright 2:53 AM (GMT) | comments | link

Desktop apps will deconstruct, says Sun

Japan is buzzing with web services excitement, as IDG's Web Services Conference gets under way with as many as 1,000 attendees. John Bobowicz, chief technical strategist at Sun Microsystems's Sun One, enthralled delegates with a vision of deconstructed desktop productivity apps, according to this report from InfoWorld:

"Ultimately, things I get today as applications can almost become features once you can get to them as services ... If we were to apply these concepts to what we call a word processor, the different capabilities could act by themselves as Web services and word processing could become a virtual application ... You may be able to decide whose dictionary you want to use without having to get different versions of the application. Eventually, word processing isn't necessarily an application but it could be considered a feature itself ..." Once such functions are available as services, it also becomes easier to build other applications because many of the same services can be re-used, he went on to say.

This all sounds like an intriguing possibility, but isn't it also rather familiar — dare I say hackneyed — as a proposition? This concept of modular desktop apps delivered over the network almost brought Corel to its knees in an early flush of Java enthusiasm when it attempted to create a network-delivered version of its WordPerfect suite. Similar aspirations at IBM and Lotus led to the creation of a toolkit that was supposed to make it possible to build your own set of component-based desktop apps. That technology ended up being given to NetObjects, which collapsed in bankruptcy last year. Sun's own Star Office suite was also supposed to be delivered as a component-based hosted service. I've heard many promises but still haven't seen it in action yet.

Come to think of it, Microsoft's vision of the "Universal Canvas" sounds remarkably similar. Here's how I described it in a column on ASPnews early last year:

The concept of the Universal Canvas is that users shouldn't be forced to work in discrete individual applications to get their work done. Instead, they should be able to simply call up the functionality they need on demand. Or, as Bill Gates put it at the .Net launch in June last year, "This universal canvas is the idea that you no longer leave the browser. You're always in the browser, even when you're doing your creativity work."

As I noted at the time, there's another way of looking at this: "To put it another way, Office XP becomes the browser, and users can access all of the rich function of the collaborative Internet without ever having to leave the Microsoft Office environment."

Maybe Sun's strategists shouldn't get so excited about this idea after all.
posted by Phil Wainewright 12:48 PM (GMT) | comments | link

Forrester warns of web services wildfire

Web services will sweep through the enterprise like wildfire, and CIOs will be powerless against the onrush, according to a new report by Forrester Research analyst Bobby Cameron. Quoted on Line56 yesterday, the analyst debunks some myths about web services, in particular the notion that implementation will always be led from the center:

"Web services are so damned easy to implement, you can give it to any Tom, Dick or Harry ... The skill sets required are very low. A person with minimal budget and management approval, and no unique skills, can deliver a web service in a matter of hours ... [this is] the same formula that led to the website explosion in the 1990s, with no top-down control ... Any developer can build a SOAP interface, any manager can fund it, and any app can call the interface."

His report, CIOs: Govern Web Services Now, is the latest of a total of seven reports on web services published recently by Forrester, as spelt out in this press release republished on WebServices.Org. Every report is packed with the kind of solid advice you'd expect from Forrester, yet tinged with the radical predictions that made the research company's reputation (here's one we like, from Apps Market, Interrupted: "Enterprise apps will deconstruct from monoliths into components").

Bobby Cameron's latest report says all the right things, and provides a good action plan for CIOs to follow as they struggle to stay on top of the web services tsunami that they see rolling in on the horizon. But his recommendations also have two very notable flaws.

One of them is timing, a fault which is less a consequence of any failure by the analyst, and more a case of Forrester corporate policy. Just as no Gartner report is complete without a "magic quadrant", so no Forrester report passes muster unless it forecasts "three waves" of evolution over a five-year period. No matter that the evolution will actually take fifteen years and unfold in umpteen waves — to admit that would be to give the impression that Forrester trades in vague, blue-sky predictions that no-one could ever use as the basis for real-world corporate planning. So five years and three waves it is, no matter what.

I'm still fond of some of Bobby's reports from 1997 (in particular The Apps Market Resets and Portfolio Assembly), even though the five-year predictions he made then still haven't come to pass. They will, sooner or later, but the future is never quite as pat as Forrester analysis is inclined to make it sound. Indeed, I could claim that I myself already predicted the conclusions in Bobby's latest report almost eight years ago — but that kind of thing is no basis on which to found a corporate strategy.

The second flaw is rather less forgivable, and here I'm afraid I'm going to have to be more forthright in my comments. According to the line56 article, Bobby singles out IBM, BEA and WebMethods as companies best placed to exploit the move to web services. Unfortunately this may go down in history alongside the promotion in the early 80s of the DEC Rainbow as a means of exploiting enterprise adoption of PCs; or Gartner's infamous recommendation several years later that corporates standardize on IBM's ill-fated OS/2 operating system as a means of regaining some semblance of accountability and control over the then burgeoning PC revolution.

These historical parallels highlight the one overriding challenge that CIOs will face with web services — how to manage the anarchy of a major change in computing technology, without suppressing the innovation that will be required to take advantage of the opportunities that it is sure to bring. The lesson of history is that the 'safe choice' of sticking with established big-name vendors will lead many enterprises into expensive wild goose chases down tortuous and bruising blind alleys. Making the right choices will demand a lot of imagination and hands-on involvement from those CIOs — along with a recognition that neither Gartner nor Forrester nor any other analyst is going to be in a position to provide all the answers.
posted by Phil Wainewright 2:18 PM (GMT) | comments | link

Christensen on standards and componentization

The race to define standards for web services looks distinctly premature. We have a core foundation set on which more or less everyone agrees (the holy trinity of SOAP, WSDL and UDDI), yet the air is thick with a host of competing acronyms as vendors fall over each other to add more.

"We must love standards — we seem to endorse so many of them," Amy Wohl recently commented. "It’s good if it’s about extending web services up a steadily more defined and agreed upon infrastructure and applications stack. It’s bad if it’s about competing standards and market fragmentation. After all, web services is all about interoperability."

If standards are supposed to be all about everyone agreeing on a thing, then why is it that they so often arouse such passionate dissent? The shenanigans over Sun's (non-)participation in the Web Services Interoperability organization (WS-I) have become so repugnant that it reminds me of the doublespeak in George Orwell's 1984 — a world where Truth means Propaganda, Peace means War, and Interoperability means Proprietary Lock-in.

The trouble with web services is that they operate at so many layers of the computing and communications stack. At some of those layers, there is very clear consensus, which is where standards are useful. But where there is no consensus, a "standard" is nothing more than a proprietary specification that happens to have been endorsed by an industry body. People seem to have forgotten that it is the market that asserts standards — the industry's customers, rather than the industry itself.

Which brings me to Christensen, writing on The Rules of Innovation in last month's Technology Review, published by MIT. As author of The Innovator's Dilemma, Christensen is pretty much the high priest of innovation, and in this article he identifies when markets need proprietary solutions and when they prefer standardized offerings. Proprietary first:

"In markets where product functionality is not yet good enough, companies must compete by ... making products whose architecture is interdependent and proprietary."

That's the stage we are today in web services implementation. There are hundreds of startups working hard to promote and establish their own proprietary solutions to the gaps in the web services fabric, and out of their successes and failures will emerge the best practice that ultimately becomes established as the market's chosen standards. To minimize as far as possible the risks of fragmentation, it is helpful if there are some broadly agreed specifications that define the parameters within which that competition takes place, but no-one should be under the illusion that those frameworks constitute a durable, standardized architecture. That only comes later:

"When the functionality of products has overshot what mainstream customers can use, however, companies must compete through improvements in speed to market, simplicity and convenience, and the ability to customize products to the needs of customers in ever smaller market niches. Here, competitive forces drive the design of modular products, in which the interfaces among components and subsystems are clearly specified. Ultimately, these coalesce as industry standards."

Where we are today with web services is that business software has reached a level of maturity where it is beginning to componentize, and web services are the means of that componentization. But the implementation, deployment and management of those components is a completely new proposition that remains in its infancy. So we have a disruptive innovation (web services) being enabled by maturity (componentization) in an established industry. We can define standards for the componentization (ie SOAP, WSDL and UDDI or some variation thereon), but the implementation and management of those components remains at its earliest stage of innovation.

Any attempt to define an all-embracing standards framework for web services interoperability today is both futile and counter-productive. It will only throttle innovation by forcing it to conform to the sustaining logic of yesterday's proprietary application architectures. The challenge facing us is to define the core web services standards for componentization in a way that will unleash and extend innovation, rather than embrace and extinguish it.

posted by Phil Wainewright 1:51 AM (GMT) | comments | link

Acquiring a network mindset

Closed systems aren't designed to get the best out of a networked environment, that much is obvious. But most people find it incredibly hard to throw off the closed-system mindset. Brent Sleeper has highlighted an interesting discussion among employees and associates of website designer Agency.com from earlier this year, which raged under the heading Why Web Services are dangerous.

The essence of this discussion revolves around the proposition that the traditional aim of website design is to draw visitors into a website (ie, a closed-system model), whereas web services make it possible to deliver content and offerings out into the network:

"In a network, one node doesn't cut it. It's he who has the most nodes that wins ... Rather than build the perfect site, perhaps we should aim for having the most nodes on the network. The most people connected, no matter where they are."

Now go back and substitute the word 'application' instead of the word 'site'.
posted by Phil Wainewright 3:44 AM (GMT) | comments | link