In a recent article on CNET News.com, Jim Allchin, Microsoft's senior vice president for Windows, bemoans the slow adoption of Web services, particularly in consumer-facing applications. Could this be the beginning of the downhill side of the Web services hype curve? And why should the current state of affairs surprise anyone, especially Jim Allchin?
Every new approach to building applications faces the same cycle: a large degree of hype, subsequent confusion, an ensuing backlash, and, finally, realistic adoption and a reasonable growth curve. No one should expect revolution. Evolution always takes a course that, while increasingly rapid, rarely occurs overnight. The Web services framework has certainly seen the hype stage of the cycle, and confusion over security and conflicting standards has reigned for the last six months or so. And now we’re seeing some early signs of the negative comments that dominate the backlash.
Interestingly enough, Allchin wonders in the article if complexity is to blame for slow adoption. Well, Jim, yes, it’s a big part of the issue developers face. That and the huge security issues that remote and shared procedure models create, as well as a flood of overlapping, competing, and confusing standards. It will take several more years for the confusion to abate, for products that support the reasonable architecture that will inevitably emerge out of the confusion to wend their way into production environments. And you know what? At that point the trade press won’t be talking about Web services anymore. It’s always a point of “market irony”: the minute developers really start doing something meaningful, the trade press moves on to the next new thing because the subject in question is no longer controversial.
And while I think that shared and remote procedure application models will find their way into the mainstream—particularly in financial services and other markets where transactions are a must-have—data sharing models are starting to demand equal time in the application model conversation. In the discussion of the “representational state transfer” (REST) model going on at xml.org and other locales throughout the Web, developers are raising valid concerns over how exactly we will manage the security and complexity of transactional Web architectures. And they’re pointing to simpler data sharing techniques, such as REST or the use of Rich Site Summary in blogging tools, that may meet the needs of many applications. (If you’re interested, you can read Roy Fielding’s dissertation, in which he coined the term REST.)
In summary, data sharing services turn data into shareable, addressable objects, leveraging the strengths of the Web and the Extensible Markup Language (XML). Instead of having to share procedures, code to remote interfaces, and manage a distributed application, developers can simply retrieve the data they need by using a URL. The data itself becomes an object. And a variety of other XML-oriented services can transform the data to meet the needs of different applications and different scenarios.
As Mike Neuenschwander, one of Burton's analysts, has pointed out in a research report we’re getting ready to publish, business process automation remains a high priority for enterprises. But most integration architectures focus on sharing procedures and largely ignore the need for sharing data. Perhaps even more important, many enterprise application developers mistakenly implement procedure sharing architectures—with their attendant higher costs and other problems—when data sharing services are better-suited to the needs of the applications they’re trying to integrate.”
Does this mean REST and data sharing techniques will take over the world and render SOAP and the Web services framework moot? No. In fact, it’s safe to assume that these programming techniques will receive the same hype treatment as Web services has. As Fielding points out in a recent posting, and in his dissertation, application frameworks are not like stretch socks. One size does not fit all, and we will always need multiple approaches to serve different needs. One day, we will have an interoperable framework for transactions, because there are clearly applications that need it. I think it’s also fair to say that REST, or something like it, will also find a place at the table. Today, we’re still in the early stages of sorting it out.
What is happening today is that the basics of a new distributed application model are taking hold. Today, enterprises view XML as a way to increase interoperability and integration in the application environments. They’re starting to leverage XML in that regard. Some are using techniques like REST. Others are using SOAP-based procedural models. In such cases, folks can talk SOAP, WSDL, and UDDI as givens. But we’ve only begun the security discussion.
In the meantime, no one should wonder why everyone isn’t dropping everything and plowing full steam ahead with Web services. Complexity, confusion, and legitimate concerns over security—combined with the new “show-me ROI” economy—will continue to slow progress. And that will be a good thing if it forces the vendors involved to solve some problems.
