A bit of rest always helps. We have to seize every opportunity to pause and reflect on where we've been before making new plans to move forward. In the topsy-turvy world of SOA (Service-Oriented Architecture), which has now become one of the foundations of enterprise architecture, a bit of introspection goes a long way toward building greater robustness into the business applications on top.
Although the term SOA was coined in 1994 by Gartner Group's Alexander Pasik, SOA and related technologies didn't become mainstream pieces of enterprise architecture until around 10 years later. Some would say SOA still hasn't reached its full potential in the enterprise.
But even before there was SOA there were Web services. And behind the ecosystem of Web services was a protocol called SOAP, which at one time used to be an acronym for Simple Object Access Protocol. (With the newest SOAP specification from the World Wide Web Consortium -- version 1.2, which came out in 2003 -- SOAP is now supposed to be called just SOAP; it is no longer an acronym.)
Enter SOAP
Through a project led by Microsoft in 1998, SOAP came into being to resolve the conflicts between the then-prevalent distributed middleware standards such as CORBA, led by IBM and others, and DCOM (Distributed Component Object Model) led by Microsoft. The goal with SOAP was to provide an open alternative that worked well both within and across firewalls, as opposed to working with only one or the other. SOAP also offered a secure and reliable method to support Internet-based distributed architectures.
So, its mission was very simple and straightforward -- to promote the use of business services throughout the Web. Yet its underpinnings were rooted in the enterprise, and were more influenced by the architectural principles governing SOA than the Web, including strong data typing of parameters and providing the fine details about associated services.
Consequently, while SOAP turned out to be great for integration needs behind the firewall, it was a bit too heavy for lightweight B2B and B2C integration needs -- the very sweet spot it was meant to dominate.
So, perhaps not surprisingly, SOAP started losing some ground to a more lightweight and Web-friendly architectural style called Representational State Transfer (REST), which complements SOAP. Together, they offer a comprehensive framework for building Web services.
The growth of e-commerce (and lately of mobile commerce), the popularity of social networking and the promise of cloud computing require a simpler and more scalable Web-based mechanism than SOAP. This is true even given SOAP's most recent upgrade, which at least one observer seems to think solves many of the traditional problems associated with the protocol.