Что такое SOAP?

Объясните, пожалуйста, простыми словами, что такое SOAP, для чего нужен, и, есл
можно, пару примеров использования.    

Ответы

Ответ 1

Лирическая часть.
Представьте что у вас реализована или реализуется некая система, которая должна быт
доступна извне. Т.е. есть некий сервер, с которым вам надо общаться. Например веб-сервер.

Этот сервер может выполнять множество действий, работать с базой, выполнять какие-т
сторонние запросы к другим серверам, заниматься каким-то вычислениями и т.д. жить 
возможно развиваться по ему известному сценарию (т.е. по сценарию разработчиков). 
таким сервером общаться человеку неинтересно, потому что он может не уметь/не хотеть отдавать красивые странички с картинками и прочим юзер-френдли контентом. Он написан и работает чтобы работать и выдавать на запросы к нему данные, не заботясь, чтоб они были человекочитаемые, клиент сам с ними разберется.

Другие системы, обращаясь к этому серверу уже могут распоряжаться полученными о
этого сервера данными по своему усмотрению - обрабатывать, накапливать, выдавать своим клиентам и т.д.
Ну вот, один из вариантов общения с такими серверами - это SOAP. SOAP протокол обмена xml-сообщениями.

Практическая часть.

Веб-сервис (так называется то, что предоставляет сервер и то, что используют клиенты
дает возможность общения с сервером четко структурированными сообщениями. Дело в том
что веб-сервис не принимает абы какие данные. На любое сообщение, которое не соответствует правилам, веб-сервис ответит ошибкой. Ошибка будет, кстати, тоже в виде xml с четкой структурой (чего нельзя сказать правда о тексте сообщения).

WSDL (Web Services Description Language). Правила, по которым составляются сообщени
для веб-сервиса описываются так же с помощью xml и также имеют четкую структуру. Т.е
если веб-сервис предоставляет возможность вызова какого-то метода, он должен дать возможность клиентам узнать какие параметры для данного метода используются. Если веб-сервис ждет строку для метода Method1 в качестве параметра и строка должна иметь имя Param1, то в описании веб-сервиса эти правила будут указаны.

В качестве параметров могут передаваться не только простые типы, но и объекты, коллекци
объектов. Описание объекта сводится к описанию каждой составляющей объекта. Если объек
состоит из нескольких полей, значит описывается каждое поле какой у него тип, названи
(какие возможные значения). Поля также могут быть сложного типа и так далее пока описание типов не закончится на простых - строка, булево, число, дата... Впрочем простыми могут оказаться какие-то специфические типы, важно чтоб клиенты могли понять какие значения могут в них содержаться.
Для клиентов достаточно знать url веб-сервиса, wsdl всегда будет рядом, по котором
можно получить представление о методах и их параметрах, которые предоставляет этот веб-сервис.
Какие плюсы у всех этих наворотов:

В большинстве систем описание методов и типов происходит в автоматическом режиме
Т.е. программисту на сервере достаточно сказать, что данный метод можно вызывать через веб-сервис, и wsdl-описание будет сгенерировано автоматом. 

Описание, имеющее четкую структуру, читается любым soap-клиентом. Т.е. какой бы н
был веб-сервис, клиент поймет какие данные веб-сервис принимает. По этому описанию клиент может построить свою внутреннюю структуру классов объектов, т.н. binding'и. В итоге программисту, использующему веб-сервис, остается написать что-то типа (псевдокод):
NewUser:=TSoapUser.Create('Вася','Пупкин','odmin'); soap.AddUser(NewUser);



Автоматическая валидация.

xml-валидация. xml должен быть well-formed. невалидный xml - сразу ошибка клиенту, пусть разбирается.
schema-валидация. xml должен иметь определенную структуру. xml не соответствует схеме - сразу ошибка клиенту, пусть разбирается. 
проверка данных осуществляется soap-сервером, чтобы типы данных, ограничения соответствовали описанию.


Авторизация и аутентификация может быть реализована отдельным методом. нативно. либо, используя http-авторизацию.
Веб-сервисы могут работать как по soap-протоколу, так и по http, то есть через get-запросы
То есть, если в качестве параметров идут простые данные (без структуры), то можно вызвать просто обычный get www.site.com/users.asmx/GetUser?Name=Vasia или post. Впрочем это не везде и не всегда.
... см. в википедии

Минусов тоже полно:

Неоправданно большой размер сообщений. Ну тут сама природа xml такова, что форма
избыточный, чем больше тэгов, тем больше неполезной информации. Плюс soap добавляе
своей избыточности. Для intranet-систем вопрос трафика стоит менее остро, чем для internet, поэтому soap для локальных сетей более востребован, в частности у Sharepoint есть soap веб-сервис, с которым с успехом (и некоторыми ограничениями) можно общаться.
Автоматическая смена описания веб-сервиса может сломать все клиенты. Ну это как б
для любой системы так, если не поддерживается обратная совместимость со старыми методами, все отвалится... 
Не минус, но недостаток. Все действия по вызову методов должны быть атомарными. Например
работая с субд мы можем начать транзакцию, выполнить несколько запросов, потом откатиться или закоммитить. В soap транзакций нет. Один запрос-один ответ, разговор закончен.
Разбираться с описанием, что на стороне сервера (все ли правильно описано у меня?)
что на клиенте (что мне тут наописывали?) бывает довольно сложно. Было несколько раз
когда мне приходилось разбираться с клиентской стороны, и убеждать серверного программера, что у него неверно описаны данные, а он в них вообще ничего понять не мог, ибо автоматическая генерация и он как бы и не должен, это дело софта. А ошибка естественно была в коде метода, программер ее не видел просто.
Практика показывает, что разработчики веб-сервисов страшно далеки от народа, использующег
эти веб-сервисы. В ответ на какой-либо запрос (валидный со стороны) может прийти невразумительная ошибка "Ошибка 5. Все плохо". Все зависит от совести разработчиков :)
еще наверняка что-то не вспомнил...

В качестве примера есть открытый веб-сервис belavia:

http://86.57.245.235/TimeTable/Service.asmx - точка входа, там же текстовое описание методов для сторонних разработчиков.
http://86.57.245.235/TimeTable/Service.asmx?WSDL - wsdl описание методов и типо
принимаемых и возращаемых данных.
http://86.57.245.235/TimeTable/Service.asmx?op=GetAirportsList - описание конкретного метода с примером вида xml-запроса и xml-ответа.

Можете вручную создать и послать запрос типа:
POST /TimeTable/Service.asmx HTTP/1.1
Host: 86.57.245.235
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://webservices.belavia.by/GetAirportsList"



  
    
      ru
    
  


в ответ придет:
HTTP/1.1 200 OK
Date: Mon, 30 Sep 2013 00:06:44 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 2940



  
    
      
        
        
        
      
    
  


ЗЫ Раньше был открыт веб-сервис аэрофлота, но после того как 1C добавили поддержк
soap в 8ку, куча 1с-бета-тестеров с успехом положили его. Сейчас что-то там поменяли (адреса не знаю, можно поискать, если интересно).
ЗЗЫ Дисклеймер. Рассказал на бытовом уровне. Пинать можно.


Ответ 2

Вот вам, например, надо передать некоторому серверному сценарию имена и значени
переменных - такое происходит практически при каждом переходе по ссылке или после нажатию на кнопке формы. Выглядит это так:
http://www.server.ru/page.php?name=Vasya&age=20&sex=male&street=Gagarin%2013&city=Tashkent&country=Uzbekistan

Здесь передаются 6 переменных (name, age, sex, street, city и country) со своим
значениями. page.php, в свою очередь, принимает эти значения и обрабатывает в соответстви
с заданными инструкциями. Все эти переменные равны по статусу в цепочке и не описываю
зависимость друг от друга (ниже поймете, что это означает). Тем более, даже если всего лишь логически рассматривать все 6 переменных как одну связку, то они описывают один объект, - т.е. некоторого индивидуума мужского пола, которого зовут Вася и которому 20 лет (и т.д), хотя нигде в этом URL не говорится, что все 6 переменных вместе описывают один объект. Только интуитивно мы догадываемся и это подходит только для этого примера.
Понятно, что у этих 6-ти переменных нет описания зависимости друг от друга - но дл
того, чтобы показать зависимость и иерархию, надо что-то добавить.... И тогда приходит на помощь XML.
XML, как вам уже известно, предоставляет удобный синтаксис для описания иерархи
данных. Формат вам уже знаком:

    1000
    Vasya
    20
    male
    

        Gagarin 13
        Tashkent
        Uzbekistan
    


В коде выше наглядно видны зависимость и иерархия. Единицей информации, описывающе
1 объект, является пространство от  до , которое имеет вложенные элементы
расположенные по иерархии относительно  ниже. Вложенные элементы, как видн
из 
, тоже могут иметь свои вложенные элементы. Грубо говоря, пространство  описывает объект индивидуума (вместе с 
 и т.д., так как является старшим в иерархии), а вот 
 внутри  еще и группирует свое подпространство из ,  и . Т.е. если символически спросить адрес, то получим 3 значения из вложенных элементов (замечу, что это всего лишь символическое объяснение).
Так вот, передавая в SOAP именно такую структуру, мы можем сообщить некоему серверном
сценарию не только переменные и их значения, но и их зависимость и иерархию. Вот я неслучайн
привел пример с 
 - ведь серверному сценарию очень легко получить полный адре
из трех элементов, видя, что родительский (объединяющий) элемент 
 имеет вложенные элементы! Как бы вы тогда сгруппировали бы эту структуру зависимости, используя обычный формат (как приведено в примере URL в самом начале)? Ок, в таком случае где-то в серверном сценарии должно быть указано, что некий адрес необходимо формировать из значений street, city и country - тоже выход, не спорю.
А теперь усложним задачу: вам надо передать за один раз данные о нескольких "Васях". SOAP дает нам такую возможность:

    
        1000
        Vasya
        ....
    
    
        1001
        Petya
        ....
    


Но вот как организовать это с помощью конструкции name=Vasya&age=20&sex=male? Дважд
имя переменной (хотя бы) name (одно для Васи, другое для Пети) ведь невозможно использовать в одной строке..
Вот ниже рабочий пример, как SOAP используется на практике (из одного из моих рабочи
проектов). Нетрудно визуально увидеть структуру данных и их иерархию (специально привож
очень простой пример из двух значимых переменных String_1 и String_2). Выше видны верхние атрибуты и соответствующий синтаксис, принятый для сообщений SOAP (почитайте документацию).

P.S. Написано весьма условно и символически - целью ставил уровень специально для читателя, который, ознакомившись, пойдет по правильному руслу.


Ответ 3

Факты: сразу видно, что половина ответчиков слабо представляют что такое SOAP. SOAP это всего лишь протокол обмена данными в виде XML и точка. 
Лирика: был придуман в свое время для веб-сервисов, но жизнь расставила все по места
- сейчас у SOAP достаточно узкая ниша именно как протокола обмена данными в виде XML, причем изначально в качестве транспортного протокола предусматривался HTTP, то сейчас понужают его вовсю поверх любых транспортных протоколов.
Будущее: весьма туманно. Скорее всего более простые и экономичные протоколы вытесня
SOAP из веб-сервисной ниши. Лет 10 назад все взахлёб говорили только о SOAP, а сейчас уже есть люди, которым надо объяснять что это за зверь.


Ответ 4

Простыми?..ну ок: это хрень которая изначально планировалась, как штука, котора
позволяла вызывать методы объектов удаленно (РПЦ не побоюсь этого слова)...т.е. на клиентско
машине реализуется только интерфейс, а вся работа происходит на сервере. Теперь используется еще и для обмена данными, т.е. вы посылаете некое XML сообщение, с запросом, Вам возвращается XML сообщение с ответом.

Но это все очень грубо.


Ответ 5

Очень многие гос.услуги и системы оплаты (QIWI, cyberplat, Сбербанк)  предоставляют сервисы по SOAP-протоколу.
Системы эти очень "туги" на развитие, так что будущее у SOAP не туманно - никуд
он пока не уйдет.
Кроме жесткой структуры сообщений-ответов SOAP позволяет подписывать сообщения 
помощью различных средств (крипто-провайдеров), что является одним из основных аргументов для использования "серъезных" web-сервисов (услуги ПФР, ФМС, запись к врачу, etc.).
С точки зрения разработчика клиента плюсом является возможность сгенерировать класс
по имеющейся схеме WSDL, и обращаться к удаленному WS как к обычному объекту (вызово
методов). Для разработчика WS тоже удобны два подхода - генерация реализации WS по имеющейся WSDL или создание WS с помощью аннотаций и генерации WSDL на основе кода (java, С#).
Про минусы SOAP выше все написали.
Могу лишь поправить:

Не минус, но недостаток. Все действия по вызову методов должны быть атомарными. Например
работая с субд мы можем начать транзакцию, выполнить несколько запросов, потом откатиться или закоммитить. В soap транзакций нет. Один запрос-один ответ, разговор закончен.

можно обойти с помощью логики на сервере и клиенте. Реализовывали "диалоги" для одно
системы оплаты между клиентом и сервером по SOAP. Протокол общения просто расположен на уровне выше SOAPа.


Ответ 6

технология получения данных путем отправки конверта с запросом. конверт с полученным
данными может содержать код ошибки, и это надо учитывать. в файле wsdl описывается структура конверта с запросом и ответом, и адрес обработчика на сервере, который и будет отвечать на запрос.