After reading all good answer, i still couldn´t resist adding my ´super laymans´ version. Forgive me.
SOAP is like the computer version of where we humans use the postal services ´enveloppes and letters to our lovers`. (Mhh, is this analog still valid in todays world? Oh, well.. UPS still exists, so i guess so)
A large part of what SOAP is, is an XML vocabulary. i.e. defines a vocabulary, using the XML specification, to describe how to express ´how to send messages´.
It standarizes what we call
- "an enveloppe" (Actually called enveloppe)
- "the letter" (called 'the body')
- and the "Annotations for the post services like stamps, signature request, sender information and the likes" (called 'headers')
It also contains a ´type-system´. Just like your type systems of .Net, Java or XSD. I won´t eleborate on this. Plenty of documentation out there as mentioned in previous answers.
The primary design focus of this language/vocabulary was to allow interoperability accross platforms. So, Java calling COM, calling .Net, calling J2EE and the rest while remaining extendable for the foreseeable future. So, instead of building ´yet another bridge between a COM object and a Java class´ we would be using SOAP to expose our functionality of our object so other platforms could call them without the need for bridges. Or, to put it differently, SOAP was the last bridge that we would ever build too.
By now, all major development toolkits have some, if not all, form of SOAP support. Interoperability became easier to implement than before, but remains ´a cream´ to get right.
SOAP no longer stands for what it original intend was; I´m still waiting for some important person to (re)name it: ´Service Oriented Access Protocol´.
I hope this helps,