Where's the simplicity in Web services?
As the number of Web services specifications proliferates, some developers advocate a return to a simpler approach.
A debate is raging over whether the number of specifications based on Extensible Markup Language (XML), defining everything from how to add security to where to send data, has mushroomed out of control. Defenders of advanced Web services specifications say they are needed to ensure that new computing architectures are flexible enough to accommodate both sophisticated and smaller-scale applications. Detractors say that simpler application development methods are good enough.
The rallying cry for people who favor simplicity is a technology approach called REST, or Representational State Transfer, a method of building applications by sending XML documents over existing Internet protocols. This allows programmers to construct applications with existing tools and computing infrastructure, notably HTTP (Hypertext Transfer Protocol).
What's new:
The complexity of Web services is raising hackles. A vocal minority wants the more complicated protocols to give it a rest in favor of a simpler approach.
Bottom line:
Analysts say REST, a Web services alternative that sends XML documents over existing Internet protocols, is suited for relatively simple applications. But businesses wanting the benefits of the flexible systems design called a services-oriented architecture should adopt Web services.
The long-running dispute has even drawn in some of the technological fathers of Web services. Tim Bray, co-inventor of XML and director of Web technologies at Sun Microsystems, said recently that Web services standards have become "bloated, opaque and insanely complex."
At stake is whether, or how quickly, customers will continue to invest in emerging Web services software--considered the foundation of modern computing systems--to replace older methods of wiring business applications together. Researchers at the Radacati Group last week forecasted that the market for Web services-related software and services will balloon from $950 million this year to about $6.2 billion in four years.
An attempt at flexibility
The term "Web services" emerged about four years ago to describe a set of software specifications, or blueprints, designed to make incompatible programs communicate over Internet protocols. Heavy hitters IBM, Microsoft and others agreed to back the specifications rather than pursue differing approaches to software compatibility as they had done in the past.
In an effort to make these Web services systems as reliable as older computing systems, but more flexible, vendors have supplemented the initial basic Web services specifications with a number of extensions. Infrastructure software providers IBM, Microsoft, BEA Systems, Oracle and others have authored specifications to add security, reliability and other features on top of the basic Web services protocols, notably SOAP (Simple Object Access Protocol) and WSDL (Web Services Description Language).
That ongoing process of specification development has caused consternation among some people, who claim that programmers and their employers cannot absorb the flow of new specifications. There are now more than 30 specs, which include hundreds of pages of technical guidelines. IBM and Microsoft have fostered the development and publication of many of those specifications, referred to collectively as the "WS-*" or "WS-star" rubric.
Bray, among others, has voiced some skepticism over the committee-driven specifications development process, which has been dominated by large vendors such as IBM and Microsoft. Bray's concerns cross political boundaries as well. His employer, Sun, is actively participating in Web services standards development. Sun, along with IBM, Microsoft and others, holds a seat on the board of the Web Services Interoperability group (WS-I), an organization formed to provide guidelines to make sure standards-based applications are compatible.
Other programmers share Bray's concerns. Rather than learn the latest specifications for doing Web services security, some developers claim that simply sending XML-formatted documents over existing Internet protocols can get most jobs done.
Independent software consultant Mike Gunderloy bemoans the complexity and growing number of Web services specifications. Having given up trying to keep pace with the regularly published specifications--which are then meant to be submitted to standards bodies for standardization--Gunderloy recommends that other developers not "bother to learn all of this WS-stuff," he wrote recently.
Some corporate customers are also cautious about embracing Web services technology and the standardization process. Many of them have stuck to the most basic Web services protocols rather than aggressively pursue the latest specifications.
Business process automation company Ultimus has decided not to use the Business Process Execution Language specification (BPEL) in its products because the industry already has the "right building blocks" in place, according to Hank Barnes, vice president of product marketing. "This focus on standards, particularly ones that are incomplete, is misplaced," Barnes said.
So what's the alternative?
Advocates of Representational State Transfer argue that REST allows the same application-to-application communication that Web services promises. One of the most successful public Web services using REST is offered by Amazon.com, which allows programmers to use Amazon's services in e-commerce applications.
But REST has its limitations, according to experts.
Michael Champion, a research and development specialist at Software AG, said "nasty enterprise integration problems" demand more sophisticated protocols and methods. In a blog posting, he called on backers of both approaches--Web services and REST--to make their cases as to why their approach is better.
Ron Schmelzer, an analyst at Web services research company ZapThink, said REST can indeed yield better results in isolated instances. But the method misses the overall point of Web services, where interoperability between products from different vendors is the ultimate goal.
"You can build whatever you want and optimize it behind your own firewall," Schmelzer said. "But if you want interoperability, then you have to agree to something. It's not meant to be optimal--it's what companies can agree to do together, given that they have very different products."
Schmelzer noted that the advanced Web services protocols now under development are designed for thorny computing problems that demand complex protocols. For example, REST does not address aspects, such as security, reliable messaging, or business process automation in a standardized way, he noted.
Other Web services advocates argue that developers can be shielded from a great deal of complexity by the development tools they choose.
"If you don't understand all the specs, don't worry about it. Tools are being created by people everywhere to make it so you can just indicate the capabilities you need, and the rest will be done for you," said Matt Powell, a content strategist at Microsoft's developer network, in a posting.
Also, Web services advocates note that the specifications were designed so that the latest capabilities, such as reliable messaging and security, can work with applications that use simpler Web services standards, such as the transport protocol SOAP. Microsoft earlier this month published a white paper stating that Web service protocols are designed to be "autonomous," which allows developers to pick the level of sophistication they need.
Randy Heffner, an analyst at IT consulting company Forrester Research, noted that REST-style development is suited for relatively simple applications. But ultimately, corporations that want to reap the benefits of a flexible systems design called a services-oriented architecture should adopt Web services based on SOAP.
Heffner draws a parallel to the early days of Web services, where SOAP was meant to be a simpler method than CORBA, an older programming standard that never reached market ubiquity, in part because of its complexity. But as Web services become more mainstream, companies will need to exploit the advanced protocols embedded in the latest products.
"Given REST?s simpler technology stack, it is reasonable that it should be faster," Heffner said. "The pursuit of development productivity...adds overhead to SOAP and, in most cases, the overhead will be worth it."