SOAP е в основата на концепцията за Web services, наследник на идеята за Семантичната мрежа. В момента Интернет е насочен към хората, които четат и разбират съдържанието на различните web сайтове или комуникират чрез IM, чат или e-mail. Но за машините голяма част от съдържанието на Web е неясно. Това е така, защото при публикуването на информацията чрез HTML ние наблягаме на нейното представяне, но по никакъв начин не указваме смисловото съдържание на документите. XML вече се използва от множество разработчици за да се поправи този недостатък, но все още не съществува единна концепция за начините по които различните програми, работещи на различни операционни системи обработват и връщат входящата информация.

Разработените преди SOAP протоколи за отдалечено повикване на процедури са в малка или голяма степен неподходящи за масово използване в Интернет. Най-вече защото те са зависими от операционните системи и други фактори на средите, където функционират приложенията. Целта на SOAP е да осигури възможност за пълна интеграция на ресурсите и информацията в мрежата.

Идеята за Уеб услугите изисква създаването на стандарт, който да позволи различните системи, написани на различни езици, да обменят информация помежду си. Затова SOAP няма никакви изисквания към езика на който ще бъдат написани приложенията, които го обработват. Всяко приложение, което може да обработва HTTP заявки, може да поддържа SOAP. Най-популярните езици за писане на Уеб услуги са C# и Java, но съществуват и множество приложения на Perl, PHP и други.

Най-общо казано, комуникацията между две Уеб услуги тече под формата на съобщения - запитване и отговор. Услугата клиент изпраща запитването си, в което чрез методите на SOAP са описани името на процедурата, която желае да задвижи и входящите й параметри. След извършването на тази процедура, активната услуга изпраща отговор - отново в SOAP, в който по специфичен начин са дадени върнатите резултати.
Ако заявката е обработена успешно, сървърът ще върне код 200 ОК, което означава, че процедурата е била изпълнена. При грешка ще получим код 500 - Internal Server Error. Спецификацията на SOAP покрива голяма част от тази комуникация, поставяйки точни изисквания за съдържанието и начина на представяне на данните. Но на ниво данни - входящи параметри или резултати, структурата на XML документа зависи най-вече от характерните особености на Уеб услугата. Тези особености са описани в нейния WSDL файл.
Въпреки че в официалните предложения и документи се твърди, че SOAP не е точно обектно - ориентирана концепция, на практика в повечето случаи е така. Официално, фактът че повечето сървъри за Уеб услуги използват COM или Java обекти е въпрос на приложение на стандарта (SOAP), а не на спецификация. Все пак, добре е да се има предвид, че SOAP произлиза от XML - RPC като начин за предаване на XML по HTTP, като най-основната разлика е във възможността за предаване на обекти. При всички положения, обаче, SOAP не е обвързан с концепцията за обектно програмиране и би могъл да се използва свободно и в други среди.
Също така спецификацията не обвързва SOAP с каквито и да било други технологии и интерфейси, освен HTTP. Изключение от правилото се явява зависимостта му от XML Schema, използвана за описване на типовете разменяни данни.
Всъщност дори и зависимостта от HTTP не е толкова силна. Въпреки че се посочва като основен начин за извършване на транспорта и идентификацията на така наречените SOAP protocol data units (PDU), все пак съществуват възможности за използване на други протоколи за тази цел - например SMTP, Microsoft Message Queue, MQ series на IBM и други. Правят се опити за пълно разделяне на сериализацията на SOAP от HTTP транзакциите.

За сега въпросът изглежда до голяма степен резонен. Но след година той ще е равносилен на питане като защо да пиша на Java или на VB, а да не си измисля собствен език. SOAP е стандарт, възприет от най-големите играчи на пазара за Уеб услуги - Microsoft, IBM, Sun и други. Той е и услилено популяризиран и буквално налаган от тях. Така че ако сега разработите приложенията си в свой XML рчник, рано или късно ще трябва да се върнете и да свършите работата отново. Разбира се при приложения за собствена употреба е мого по-логично да се използва XML със собствено DTD, отговарящ на конкретните нужди, но публичните Уеб услуги говорят на SOAP. И това няма да се промени в скоро време.