In The Hitchhiker's Guide to the Galaxy, Douglas Adams says: "The Babel Fish is small, yellow, and simultaneously translates from one spoken language to another. When inserted into the ear, its nutrition processes convert sound waves into brain waves, neatly crossing the language divide between any species you should happen to meet whilst traveling in space."
Like the Babel Fish, Web services bridge the gap between development languages and disparate species ... er, platforms. Insert Web services into the "ear" of your application infrastructure, between the consumer of the service and the back-end system--the brain, if you will--that will ultimately process the request, in its own language of course, and you're in business.
The evolution of the Babel Fish--and Web services--are no accident. The past two decades have seen many attempts to provide a mechanism through which business and applications can talk to one another without regard to platform or language, and without the distasteful side effect of requiring modifications to existing business processes.
CORBA and COM arose out of a need to provide enterprises with a way to exchange data between systems and with business partners that did not require a massive investment. EDI standards have been the traditional, and somewhat successful, mechanism through which businesses have exchanged data for everything from purchase orders to scheduling shipments to invoices.
And yet EDI isn't the solution we had hoped for. Standard formats across industries were a start, but the data formats weren't flexible enough to support every business, which resulted in additional code to translate from EDI to an internal representation and then back to EDI. And the expense of using value-added networks to transport and ensure message delivery pushed the price of entry too high for many small and midsize enterprises.
XML and the Internet were big evolutionary jumps. A self-defining format with an accepted, standard description language exchanged over an easily accessible, standardized network suddenly offered a better way to integrate businesses and applications. But even as XML became the de facto standard for exchanging data, the manner in which that data was sent and received varied greatly from business to business. Distribution channels could not count on being able to send an order to Business A in the same manner as Business B. As a result, the time and cost to implement such connectivity remained high.
Enter SOAP. Taking advantage of the flexibility and widespread acceptance of XML, SOAP provides a standardized transport mechanism for messages, and when combined with WSDL (Web Services Definition Language), offers a standard method of describing supported business services. (For more on how all this works, see "SOAPing Up Web Services".)