Simple Object Access Protocol (SOAP) is an XML-based protocol that is designed to exchange structured and typed information on the Web.
According to Microsoft, one of the originators of the specification, the purpose of SOAP is to enable rich and automated Web services based on a shared and open Web infrastructure. SOAP can be used in combination with a variety of existing Internet protocols and formats including HTTP, SMTP, and MIME and can support a wide range of applications from messaging systems to a remote procedure call.
Within Web services, the architecture destined to replace traditional middleware, SOAP is simply the “definition of how to create an XML message that you will use to ultimately send to someone else’s Web server,” said Michael Flynn, Microsoft Canada’s senior product manager for development tools in Mississauga, Ont.
As a result, SOAP is key to software developers, Flynn said.
Tools such as those offered by Microsoft can make the creation of SOAP simple, according to Flynn. However, he added, in the same way that people with calculators should still know how to add and subtract, understanding the basics of SOAP will help developers architect better code, he added.
Although people often question whether IT needs yet another protocol, Princeton, N.J.-based Kent Brown, a senior consultant, researcher and trainer with Alpha Technologies said SOAP is needed because it is completely platform-, object model-, and language-independent. The main problems with the earlier protocols are their complexity, the difficulty they cause with firewalls and their proprietary nature, he said.
SOAP uses XML to package and parse the data, which means that it provides a universal language for making RPCs (remote procdure calls). Because it is built on top of HTTP, SOAP essentially extends the HTML effect. Since ASP pages receive and respond with standard HTML requests carried over the Internet in HTTP packets, the client using a Netscape browser really doesn’t care that the server is using a Microsoft-centric technology to get the work done on the back end. Because we have this generic way of sending a request and receiving a response, the server is free to employ whatever means necessary to get the work done, Brown said.
Since SOAP is simply another payload that can be carried via HTTP, Brown said the potential vulnerabilities are similar to straight HTTP. However, since SOAP packets declare their intent by publishing interface and method names in the HTTP header, it is possible for firewalls to perform filtering based on this information, he said.
Flynn also noted that since SOAP is XML based it can slip through Port 80 – the primary door on a firewall. As a result, moving to XML-based middleware means eliminating more and more firewall ports and getting back to the basic one. “It means you only need one security guard now,” he said.
According to Brown, the main shortcomings of SOAP is its performance over the wire – since XML is a fairly verbose method of packaging data, its lack of support for sophisticated ORPC mechanisms and the lack of a built-in security protocol. However, he said these are all a result of conscious decisions to leave SOAP as simple and as platform independent as possible. Ultimately, he said, the goal is universal acceptance of the protocol – so platform neutrality takes a much higher priority than performance and richness of features.
“Vendors who refuse to support SOAP – at least in concept – are revealing their real stance toward open software. If they have legitimate technical objections, hopefully the SOAP spec writers can accommodate them. It’s long past time to get over the petty stuff and move on,” Brown said.
