SOAP Opera


      Bookmark and Share

BEST PRACTICES SERIES

Last April when Google released the Google API, a programmable API-Web service using SOAP (and WSDL), it received a lot of attention. In part, the interest was because it allowed users to access Google's extensive database with a SOAP call, but primarily it was because it was an actual, working Web services—and after years of waiting, the computing community was more than ready for one. Yet instead of uniting people around this seeming milestone, it brought to a boil the long-simmering debate regarding SOAP (and Web services in general) and its integration with World Wide Web technologies.

SOAP (Simple Object Access Protocol) provides a way for applications to communicate with one another over the Internet regardless of the operating system, using HTTP and XML. The potential is enormous and, if met, SOAP would allow data to move freely over the Internet from platform to platform in a true distributed computing environment.

Yet some question the long-term viability of SOAP, wondering whether it can handle high-end Web services and complain that it doesn't adhere to the standards of the Web itself. Among those detractors is Paul Prescod, who was part of the original XML working group at W3C (The World Wide Web Consortium) and author of The XML Handbook. Prescod has been very vocal in his dissatisfaction with Google's use of SOAP because he believes it is not Web compatible. Prescod says, "Let's say that SOAP doesn't use Web technologies as they were designed to be used." He uses this analogy to help explain: "SOAP tries to use a fork as if it were a spoon." In other words, SOAP uses the Web as if it were a messaging bus, rather than a Web of interconnected information.

Dave Winer, one of the people who helped define SOAP and president of UserLand software disagrees with Prescod's position stating, "What's important is that it [the Google API] works. It's immediately useful in every scripting environment and on every operating system. That makes it valuable."

Nelson Minar, a software engineer at Google who helped develop the API says that they chose SOAP because "there are a lot of development tools for it and a lot of developers are using it." Further, Minar thinks SOAP is easy to use. He says, "You don't have to be an XML expert and you can drop it into .NET or Java and it allows developers to concentrate on the applications, rather than the technology."

Paul Prescod sees it differently, however, claiming that Google's use of SOAP is "a way of blindly following trends in the industry without understanding the trade-offs." Says Prescod, "We can do the things the Web way, which is extremely flexible,. Or we can do them the SOAP RPC way, which is more constraining. The Web way is more compatible with W3C technologies..." But Dave Winer counters that Prescod's is an academic vision without practical application.

Meanwhile, work on SOAP 1.2 is near completion, but the same debate seems destined to continue even with this update as W3C advocates criticize its lack of integration with the Web. And it seems unlikely to go away until or unless one side is proven right or at least reaches critical mass in terms of adoption. In the meantime, the two sides will wage their debates in the press, on Web logs, in newsgroups, and at conferences, while the world waits to see if the promise of a Web services model is truly viable.