On the information superhighway or what is most commonly known as the “internet”, there is a superfluity of data that is constantly being produced or consumed. Information exchange seems to be the buzzword of most modern web services under development and your service should be able to “talk” to other services in order to produce desired results. Architecture is no more standalone with respect to the fact that a particular web service may require data that is produced by another web service and this idea may be extended across web services.
The moment you talk about information exchange across different web services, the first thought that probably strikes you is compatibility. For example, consider two web services, where one web service is running on a Microsoft IIS Server and the other on an Apache Tomcat Server with ASP.NET and JSP scripting respectively. How do these services communicate with each other?
Earlier, before the advent of the use of SOAP, such mechanisms were achieved by the XML-RPC, which was not a very safe and secure mode of communication. SOAP provides an optimal solution to this problem.
SOAP is a protocol, that has been implemented in the Application layer of the TCP/IP and it facilitates the exchange of XML-based messages over computer networks using both HTTP and HTTPS. It forms the foundation layer of the web services protocol stack thereby providing a basic messaging architecture upon which other abstract layers can be derived. SOAP uses XML as the standard message interchange format.
Due to the use of XML, SOAP has both potentially implicit benefits and drawbacks. On the one hand, it facilitates more readability for humans, makes the architecture extensible, and on the other hand, slows down processing speed. This is why the use of this protocol is avoided for longer messages.
If your messages are short and you require simple and brief communication among web services running on dissimilar architectures, SOAP is the way to go!