Acronym for Simple Object Access Protocol.
It's a way for a computer program to call a function on another computer, a concept known as RPC. Previously known RPC implementations have always been somewhat platform and/or language specific. SOAP's answer is to use XML for Serialisation in marshalling the call and HTTP to transport it. In other words: SOAP is a bloated, over engineered implementation of a perfectly trivial concept. Sigh.
The canonical SOAP service is a WebServer at IBM which returns (delayed) stock quotes.
This Wiki has a SOAP source letting you grab the wiki source of a webpage. There's a WSDL file describing this source, and you can use xmethods.net to get a human readable version of it.
See also AXIS.
From The Fishbowl: SOAPy Madness:
Question 153 of the Undernet #java FAQ reads:
Can I make an IRC chat client with SOAP?
Hmm. It's possible, but everything's possible. It's completely implausible. SOAP manages to maintain state through sessions, but the concept of long-running transactions like an IRC client would require is... sickening.
I've only ever written two SOAP applications. The first was “Hello World”, except it would give back a random quote from the fortune file instead of the boring Hello.
The second was truly diabolical. It was a tunneling proxy. It tunneled TCP/IP. Any TCP/IP whatsoever. Over SOAP.
Hey, I was bored.
Anyway, I tested this proxy by connecting my IRC client to it. It worked perfectly, albeit rather choppily, as the stream was being broken up into lots of little XML documents, turned into HTTP requests and then being reconstituted at the other end of the tunnel.
And yes, it was sickening, but in a compelling, car-crash kind of way.