New Distributed Computing Model Takes On SOAP, Web Services

By Antone Gonsalves

Major vendors including Microsoft, IBM, and Sun Microsystems have joined in a united front around emerging Web services standards, believing that widespread adoption is more likely if everyone plays by the same rules.

But despite their best efforts to hold developers' attention, a new approach to building Web applications has left some wondering whether the vendor-promoted technology is really the easiest solution.

The debate is between a core Web services standard called SOAP, or Simple Object Access Protocol, and a new model for distributed computing called REST, or Representational State Transfer.

REST is described as an architectural style for building applications that leverages more of the current Web technology for passing data between computer systems. In a sense, REST takes the same technological concepts behind a browser requesting data from an application running on a server, and applies them to application-to-application communications. The architecture uses XML, URLs, and "get" and "put" commands commonly used over the Internet.

On the other hand, SOAP builds a remote procedure call (RPC) layer over HTTP and XML. Commonly used on LANs, RPCs are a programming interface that allows an application to use the services of another in a remote system. SOAP uses XML syntax to send text commands between applications across the Internet and is promoted as lighter weight and less programming-intensive than RPC or similar technologies like DCOM from Microsoft.

But as an RPC-style technology, SOAP takes many of the problems of object-oriented computing to the Web. Therefore, it makes more sense to leverage as much current Web technology as possible, some experts argue. "REST says, 'Let's make Web services an extension of what's great about the Web already,' in terms of a small set of verbs and a document-centric philosophy," said Scott Means, CEO of Enterprise Web Machines Inc. in Columbia, S.C., and author of several books on XML.

For example, using SOAP to get information on an employee may involve drawing data from several sources and bringing it all together for display as one document. REST architecture, on the other hand, would request an XML document containing all the information and deliver it to another application, or use XSLT (eXtensible Stylesheet Language Transformation) to convert it to HTML for display in a browser.

Means argues that a lot of information is already stored in XML on the Web and can be made available as a Web service without building new SOAP-based applications. "The goal in the end would be a unified infrastructure, so that there's never duplicated effort in terms of one system to deliver things for public use on the Internet and another for delivering to partner sites," Means said.

Of course, REST is no panacea. SOAP would be the better method for opening a legacy application to the Web, provided the developer can deploy an adequate security mechanism. But REST would be an alternative to the Web services stack if companies agreed in advance to adopt the architecture in their computer systems for moving documents, such as purchase orders, back-and-forth over the Internet.

"It's fairly simple," Ronald Schmelzer, analyst for IT research firm ZapThink LLC, said. "You can do some robust things with it, and it doesn't have the layers of complexity that Web services protocols have."

REST is simpler because it has less ambiguity than the Web services stack, and fewer points of failure. SOAP supporters had to form a separate group, the Web Services Interoperability Organization, to develop standards that ensure SOAP-enabled applications can communicate.

However, SOAP and its relatives can perform both asynchronous and synchronous messaging, while REST is best suited for the latter. In addition, because many vendors support the Web services stack, more applications will support SOAP out of the box, making it easier for developers to tie the software together over the Internet using SOAP.

REST supporters argue their preferred architecture enables an IT department to be less dependent on vendors by circumventing the Web services technology stack, which includes SOAP, WSDL, and UDDI.

"The discussions are really debates about Web services for the people vs. Web services for businesses," Schmelzer said. "There are a lot of open-source people behind REST and a lot of vendor stuff behind Web services. It's very religious."

Nevertheless, large companies won't get involved in religious wars and are more likely to stick with the option that has the strongest vendor support. The emerging Web services stack is supported by all the major vendors.

"The enterprise is going to go with the safer bet -- and the safer bet, to be honest -- is the Web services stack," Schmelzer said.