Что такое soap простыми словами
Введение в SOAP
Что такое SOAP?
SOAP расшифровывается как Simple Object Access Protocol (Простой Протокол Доступа к Объектам). Надеюсь по прочтении статьи вам останется только недоумевать: «Что за странное название?»
SOAP в теперешней его форме – это метод удаленного вызова (RPC, Remote procedure Call) по сети. (Да, он также используется для передачи документов в виде XML, но мы это пока опустим).
Давайте разбираться. Представьте, что у вас есть сервис, который возвращает биржевую котировку (stock quote) для заданного тикера (stock symbol). Он посылает данные на сайт Nasdaq и формирует на основе возвращенного HTML нужный результат. Дальше, чтобы позволить другим разработчикам использовать его внутри своих приложений, вы делаете из этого сервиса компонент, который через Интернет находит информацию о котировках. Работает он отлично, пока в один прекрасный день Nasdaq не меняет разметку своих страниц. Вам приходится пересмотреть всю логику работы компонента и разослать обновления всем разработчикам, использующим его. А им в свою очередь необходимо разослать обновления всем своим пользователям. Если это происходит на более-менее постоянной основе, вы можете нажить немало врагов среди коллег-разработчиков. А с программистами, как известно, шутки плохи. Вы же не хотите завтра доставать фотографию любимого кота из офисного шредера, правда?
Что же делать? Посмотрим. все, что вам нужно, это предоставить одну функцию, которая будет принимать на вход тикер (типа string) и возвращать биржевую котировку (типа float или double). Так не проще ли было бы просто позволить вашим разработчикам каким-то образом вызвать эту функцию через Интернет? Отлично! Тоже мне новость, есть же COM и Corba, и Java, которые этим занимаются уже годами. что правда – то правда, но эти методы не без изъяна. Удаленная настройка COM не тривиальна. Кроме того, нужно открыть столько портов в брандмауэре, что на системного администратора пива не напасешься. Да, и придется забыть о пользователях всех операционных систем кроме Windows. Но ведь позьзователи Linux тоже иногда интересуются биржей.
Хотя, похоже, что не все потеряно для пользователей Linux, если они используют DCOM, больше здесь: http://www.idevresource.com/com/library/res/articles/comonlinux.asp.
На счет Corba и Java я много сказать не могу, так что в качестве упражнения предлагаю читателям найти минусы в этих подходах.
SOAP – это стандарт, который позволяет вам описать такой удаленный вызов и вид, в котором будет возвращаться результат. Таким образом вам нужно разместить вашу функцию в приложении, доступном по сети и получать вызовы в виде SOAP пакетов. После этого вы валидируете входные данные, запускаете вашу функцию и возвращаете результат в новом SOAP пакете. Весь процесс может работать через HTTP, так что вам не придется открывать кучу портов в брандмауэре. Правда просто?
О чем эта статья
Это первая из серии статей о SOAP, которые мы пишем в Agni Software. В этой статье я постараюсь дать вам представление о том, что такое SOAP и как написать приложение, общающееся с SOAP сервером.
Soap и XML
Если вам SOAP пока еще кажется простым, добавим XML. Теперь вместо имени функции и параметров мы получаем довольно сложный XML-конверт, как будто созданный для того, чтобы сбить вас с толку. Но не спешите пугаться. Дальше – больше, и вам нужно увидеть всю картину, чтобы оценить всю сложность SOAP.
Если вы не знаете, что такое XML, для начала прочтите мою статью об XML здесь: http://www.agnisoft.com/white_papers/xml_delphi.asp.
Все SOAP пакеты имеют XML формат. Что это значит? Посмотрим. Взгляните на эту функцию (Pascal):
Выглядит отлично, но проблема в том, что это – Pascal. Какая польза от этого простого определения для Java-разработчика? Или для кого-то, кто работает с VB? Нам нужно что-то, что будет понятно всем, даже VB-программистам. Так дайте им XML, содержащий одну и ту же инфрмацию (параметры, значения биржевых котировок и т.д.). Вы создаете SOAP пакет, который по сути является вызовом вашей функции, обернутый в XML, чтобы любое приложения на любой платформе могло его понять. Теперь посмотрим, как выглядит наш SOAP вызов:
Информативно, правда? SOAP упрощается на глазах. Ладно, шутки в сторону. Теперь я постараюсь объяснить вам, как разобраться в этом SOAP вызове.
Расшифровка тегов
Лирическое отступление на счет пространств имен: Пространство имен дает возможность квалифицировать XML тег. Нельзя, к примеру, иметь две переменные с одинаковым именем в одной процедуре, но если они в двух разных процедурах, проблем не возникает. Таким образом процедура – это пространство имен, так как все имена в ней уникальны. Точно так же XML теги имеют свою область видимости внутри пространств имен, так что имея пространство имен и имя тега, можно однозначно его идентифицировать. Мы определим пространство имен как URI, чтобы отличать наш NS1 от подражателей. В приведенном выше примере NS1 – это алиас, указывающий на urn:xmethods-quotes.
Обратите внимание также на атрибут encodingStyle – этот атрибут определяет каким образом сериализуется SOAP вызов.
Внутри тега указано «IBM». Это – значение параметра symbol функции GetStockQuote.
Ну и в конце, как порядочные люди, мы закрыли все теги.
Вот и разобрались с SOAP пакетом, определяющим вызов к SOAP серверу. А SOAP сервер с помощью XML парсеров, красной кнопки и космической станции «МИР» декодирует этот вызов и определяет, что вам нужна биржевая котировка. Он тут же находит нужную котировку и возвращает вам ее в таком виде:
После разворачивания SOAP конверта, срывания ленточек и шуршания оберткой, мы узнаем, что цена акции IBM – 34.5.
Большинство коммерческих серверов вернуло бы гораздо больше информации, например, в какой валюте и за какую цену была куплена последняя акция. Да и цена акции, пожалуй, была бы поточнее.
Таким образом мы знаем, чего ожидает SOAP сервер и что он вернет. Так КАК же отправить эту информацию? Использовать можно любой транспорт. Самым освещенным является HTTP. Я не стану вдаваться в подробности HTTP, для тех, кто не знает – это то, что использует ваш браузер, чтобы общаться с сайтами, на которые вы заходите.
Нужный HTTP запрос будт выглядеть приблизительно так:
Единственное, что еще стоит отметить – это заголовок SOAPAction. Этот заголовок указывает на цель запроса и является обязательным. Каждый SOAP сервер может иметь неограниченное количество функций и может использовать заголовок SOAPAction чтобы определить какую функцию вызывают. Брандмауэры и мультиплексоры также могут фильтровать контент на основании этого заголовка.
SOAP ответ от HTTP сервера будет выглядеть следующим образом:
Почему HTTP? Во-первых, сетевым администраторам не придется открывать уйму отдельных портов для SOAP вызовов. веб-сервер может спокойно обрабатывать вызовы, т.к. 80-й порт обычно открыт для всех для приема входящих запросов. Еще одним преимуществом является расширяемость веб-серверов с помощью CGI, ISAPI и других нативных модулей. Эта расширяемость позволяет написать модуль, обрабатывающий SOAP запросы не задевая другого веб-контента.
Надеюсь, эта статья помогла пролить немного света на SOAP. Если вы еще здесь и хотите почитать больше на эту тему, посетите сайт авторов: http://www.agnisoft.com/soap
Если Вам понравилась статья, проголосуйте за нее
Голосов: 15 Голосовать 
Что такое SOAP?
Объясните, пожалуйста, простыми словами, что такое SOAP, для чего нужен, и, если можно, пару примеров использования.
6 ответов 6
Лирическая часть.
Представьте что у вас реализована или реализуется некая система, которая должна быть доступна извне. Т.е. есть некий сервер, с которым вам надо общаться. Например веб-сервер.
Этот сервер может выполнять множество действий, работать с базой, выполнять какие-то сторонние запросы к другим серверам, заниматься каким-то вычислениями и т.д. жить и возможно развиваться по ему известному сценарию (т.е. по сценарию разработчиков). С таким сервером общаться человеку неинтересно, потому что он может не уметь/не хотеть отдавать красивые странички с картинками и прочим юзер-френдли контентом. Он написан и работает чтобы работать и выдавать на запросы к нему данные, не заботясь, чтоб они были человекочитаемые, клиент сам с ними разберется.
Практическая часть.
Веб-сервис (так называется то, что предоставляет сервер и то, что используют клиенты) дает возможность общения с сервером четко структурированными сообщениями. Дело в том, что веб-сервис не принимает абы какие данные. На любое сообщение, которое не соответствует правилам, веб-сервис ответит ошибкой. Ошибка будет, кстати, тоже в виде xml с четкой структурой (чего нельзя сказать правда о тексте сообщения).
WSDL (Web Services Description Language). Правила, по которым составляются сообщения для веб-сервиса описываются так же с помощью xml и также имеют четкую структуру. Т.е. если веб-сервис предоставляет возможность вызова какого-то метода, он должен дать возможность клиентам узнать какие параметры для данного метода используются. Если веб-сервис ждет строку для метода Method1 в качестве параметра и строка должна иметь имя Param1, то в описании веб-сервиса эти правила будут указаны.
Для клиентов достаточно знать url веб-сервиса, wsdl всегда будет рядом, по которому можно получить представление о методах и их параметрах, которые предоставляет этот веб-сервис.
Какие плюсы у всех этих наворотов:
Описание, имеющее четкую структуру, читается любым soap-клиентом. Т.е. какой бы ни был веб-сервис, клиент поймет какие данные веб-сервис принимает. По этому описанию клиент может построить свою внутреннюю структуру классов объектов, т.н. binding’и. В итоге программисту, использующему веб-сервис, остается написать что-то типа (псевдокод):
Минусов тоже полно:
В качестве примера есть открытый веб-сервис belavia:
Можете вручную создать и послать запрос типа:
ЗЫ Раньше был открыт веб-сервис аэрофлота, но после того как 1C добавили поддержку soap в 8ку, куча 1с-бета-тестеров с успехом положили его. Сейчас что-то там поменяли (адреса не знаю, можно поискать, если интересно).
ЗЗЫ Дисклеймер. Рассказал на бытовом уровне. Пинать можно.
Рельсы веб-интеграции. REST и SOAP
В каждой отрасли бизнеса, каждой компании, как правило, используется целый зоопарк ПО. Одни системы «из коробки» умеют взаимодействовать с «соседними» продуктами, другие же приходится дорабатывать. За десятилетия существования веба как отрасли сформировались следующие практики межсетевого взаимодействия:
Обмен файлами по FTP.
Неструктурированные HTTP-запросы, договорённости между разработчиками.
Экзотика: сокеты, порты, бинарные объекты.
В данной статье мы поговорим о веб-сервисах. Чем они отличаются от прочих способов и какие они бывают.
Что такое веб-сервисы?
Веб-сервисы (или веб-службы) — это технология, позволяющая системам обмениваться данными друг с другом через сетевое подключение. Обычно веб-сервисы работают поверх протокола HTTP или протокола более высокого уровня. Веб-сервис — просто адрес, ссылка, обращение к которому позволяет получить данные или выполнить действие.
Главное отличие веб-сервиса от других способов передачи данных: стандартизированность. Приняв решение использовать веб-сервисы, можно сразу переходить к структуре данных и доступным функциям. Например, в SOAP (как более строгом протоколе), уже решён вопрос уведомления об ошибках.
Самые известные способы реализации веб-сервисов:
XML-RPC (XML Remote Procedure Call) — протокол удаленного вызова процедур с использованием XML. Прародитель SOAP. Предельно прост в реализации.
SOAP (Simple Object Access Protocol) — стандартный протокол по версии W3C. Четко структурирован и задокументирован.
JSON-RPC (JSON Remote Procedure Call) — более современный аналог XML-RPC. Основное отличие — данные передаются в формате JSON.
REST (Representational State Transfer) — архитектурный стиль взаимодействия компьютерных систем в сети основанный на методах протокола HTTP.
Специализированные протоколы для конкретного вида задач, такие как GraphQL.
Менее распространенный, но более эффективный gRPC, передающий данные в бинарном виде и использующий HTTP/2 в качестве транспорта.
Остальные протоколы не так широко распространены. Подробно рассмотрены в статье будут SOAP и REST.
SOAP (Simple Object Access Protocol) — данные передаются в формате XML.
отраслевой стандарт по версии W3C;
наличие строгой спецификации;
широкая поддержка в продуктах Microsoft,
сложность/ресурсоемкость парсинга XML-данных.
Любое сообщение в протоколе SOAP — это XML документ, состоящий из следующих элементов (тегов):
Envelope. Корневой обязательный элемент. Определяет начало и окончание сообщения.
Header. Необязательный элемент — заголовок. Содержит элементы, необходимые для обработки самого сообщения. Например, идентификатор сессии.
Body. Основной элемент, содержит основную информацию сообщения. Обязательный.
Fault. Элемент, содержащий информацию об ошибках, возникающих в процессе обработки сообщения. Необязательный.
Пример SOAP запроса:
Пример SOAP ответа:
REST (Representational State Transfer) — на самом деле архитектурный стиль, а не протокол. В отличие от SOAP, REST не подкреплен официальным стандартом. Фактически, он основывается на соглашениях. Веб-сервис, построенный с учетом всех требований и ограничений архитектурного стиля, можно назвать RESTful веб-сервисом.
REST не использует конвертацию данных при передаче, данные передаются в исходном виде — это снижает нагрузку на клиент веб-сервиса, но увеличивает нагрузку на сеть. Управление данными происходит с помощью методов HTTP:
GET — получить данные;
POST — добавить данные;
PUT — изменить данные;
DELETE — удалить данные.
Использование этих методов позволяет реализовать типичный CRUD (Create/Read/Update/Delete) для любой информации. Но это лишь соглашение: часто используются только 2 метода: GET для получения и POST для всего остального. Разобраться поможет такое понятие, как REST-Patterns. Паттерны связывают HTTP методы с тем, что они делают.
экономичность в плане ресурсов;
не требует программных надстроек (json_decode есть почти в каждом языке).
неоднозначность методов управления данными.
Пример REST запроса:
Пример REST ответа:
Что же использовать?
Вопрос «Какой способ реализации использовать?» необходимо рассматривать в контексте реализуемой системы и ее ограничений. Обычно, SOAP используется в крупных корпоративных системах со сложной логикой, когда требуются четкие стандарты, подкрепленные временем. XML-RPC, пожалуй, устарел и не имеет смысла ввиду наличия собрата JSON-RPC. RPC-протоколы подойдут для совсем простых систем с малым количеством единиц информации и API-методов.
Если же вы разрабатываете публичное API и логика взаимодействия во многом покрывается четверкой методов CRUD — смело выбирайте REST. Он наиболее популярен в WEB. Яндекс, Google и другие используют именно его для своего API.
Веб-сервисы в живом производстве
Разработка веб-сервисов — типичная задача интеграции. ИНТЕРВОЛГА, как веб-интегратор, регулярно сталкивается с задачами разработки веб-сервисов и успешно с ними справляется. Наши сайты были и SOAP/REST серверами, и SOAP/REST клиентами.
Успешным примером внедрения веб-сервисов является проект Enterprise-уровня — Личный кабинет клиентов компании Евраз Металл Инпром. Все функции личного кабинета основываются на взаимодействии с удаленным SOAP веб-сервисом. Сайт выступает клиентом. В процессе эволюции в угоду безопасности сайт переквалифицировался в SOAP-сервер, а учетная система в SOAP-клиента.
Еще один личный кабинет для клиентов компании Евраз — еще один пример сайта в качестве клиента удаленного SOAP веб-сервиса.
Если у вас есть потребность организовать взаимодействие с веб-сервисом, сделать из сайта REST/SOAP/RPC клиент или сервер, пишите нам.
Подведем итог, выделив, два важных тезиса в пользу выбора веб-сервисов в качестве «рельс» для веб-интеграции.
Наш опыт неоднократно демонстрировал, что создание веб-сервисов, в реальном времени передающих необходимые данные между сайтом и другим ПО — лучшее решение, чем классические обмены по расписанию. Такой подход проще сопровождать, вести его отладку, это более эффективная трата времени программиста, чем проектирование и разработка сложного двунаправленного обмена с кучей сущностей.
Можно провести аналогию с эволюцией разработки сайтов. Когда-то, на заре сайтостроения, каждый разработчик делал сайт с нуля на той технологии, которую мог знать лишь он один. Это порождало проблемы в развитии таких сайтов. Как работали такие сайты — знал только автор кода. Со временем появлялись фреймворки и CMS. Разработку начинали не с нуля, а с известных широкой массе разработчиков «заготовок» — стандартных решений стандартных проблем с возможность расширения и углубления.
Также и с обменом данными. Не нужно тратить месяцы на объяснение новому сотруднику и самому себе, как работает обмен. Есть стандарт, обмен работает по нему.
2) Простой протокол доступа к объектам
Что такое SOAP?
SOAP — это основанный на XML протокол для доступа к веб-сервисам по HTTP. У него есть некоторая спецификация, которая может быть использована во всех приложениях.
SOAP известен как простой протокол доступа к объектам, но в более поздние времена был сокращен до SOAP v1.2. SOAP — это протокол, или, другими словами, это определение того, как веб-сервисы взаимодействуют друг с другом или взаимодействуют с клиентскими приложениями, которые их вызывают.
SOAP был разработан как промежуточный язык, чтобы приложения, построенные на разных языках программирования, могли легко общаться друг с другом и избегать чрезмерных усилий по разработке.
В этом уроке вы узнаете
SOAP Введение
Обмен данными между приложениями имеет решающее значение в современном сетевом мире. Но обмен данными между этими разнородными приложениями будет сложным. Так же будет сложность кода для осуществления этого обмена данными.
Одним из методов, используемых для борьбы с этой сложностью, является использование XML (Extensible Markup Language) в качестве промежуточного языка для обмена данными между приложениями.
Каждый язык программирования может понимать язык разметки XML. Следовательно, XML был использован в качестве основного средства для обмена данными.
Но нет стандартных спецификаций использования XML для обмена данными на всех языках программирования. Вот где приходит SOAP.
SOAP был разработан для работы с XML через HTTP и имеет некоторую спецификацию, которую можно использовать во всех приложениях. Мы рассмотрим более подробную информацию о протоколе SOAP в последующих главах.
Преимущества SOAP
SOAP — это протокол, используемый для обмена данными между приложениями. Ниже приведены некоторые из причин использования SOAP.
SOAP Строительные блоки
Спецификация SOAP определяет нечто, известное как « сообщение SOAP », которое отправляется веб-службе и клиентскому приложению.
На приведенной ниже схеме показаны различные строительные блоки сообщения SOAP.
Сообщение SOAP — это не что иное, как простой XML-документ, который имеет следующие компоненты.
Простой пример сложного типа показан ниже.
Предположим, что мы хотим отправить структурированный тип данных, который имеет комбинацию «Имя учебника» и «Описание учебника», тогда мы определим сложный тип, как показано ниже.
Структура сообщения SOAP
Следует отметить, что сообщения SOAP обычно автоматически генерируются веб-службой при ее вызове.
Всякий раз, когда клиентское приложение вызывает метод в веб-службе, веб-служба автоматически создает сообщение SOAP, в котором будут содержаться необходимые данные, которые будут отправлены из веб-службы клиентскому приложению.
Как обсуждалось в предыдущем разделе, простое сообщение SOAP имеет следующие элементы:
Давайте рассмотрим приведенный ниже пример простого сообщения SOAP и посмотрим, что на самом деле делает элемент.
Теперь вышеуказанное SOAP-сообщение будет передаваться между веб-службой и клиентским приложением.
Вы можете увидеть, насколько полезна вышеуказанная информация для клиентского приложения. Сообщение SOAP сообщает клиентскому приложению, как называется веб-служба, а также какие параметры она ожидает, а также тип каждого параметра, принимаемого веб-службой.
Элемент конверта SOAP
Первый бит строительного блока — конверт SOAP.
Конверт SOAP используется для инкапсуляции всех необходимых деталей сообщений SOAP, которыми обмениваются веб-служба и клиентское приложение.
Элемент конверта SOAP используется для указания начала и конца сообщения SOAP. Это позволяет клиентскому приложению, которое вызывает веб-службу, знать, когда заканчивается сообщение SOAP.
Следующие пункты могут быть отмечены в элементе конверта SOAP.
Ниже приведен пример версии 1.2 элемента конверта SOAP.
Сообщение о неисправности
Когда выполняется запрос к веб-службе SOAP, возвращаемый ответ может иметь либо 2 формы, которые являются успешным ответом, либо ответом об ошибке. При успешном генерировании ответ от сервера всегда будет SOAP-сообщением. Но если генерируются ошибки SOAP, они возвращаются как ошибки «HTTP 500».
Сообщение о сбое SOAP состоит из следующих элементов.
Пример сообщения об ошибке
Пример сообщения об ошибке приведен ниже. Ошибка генерируется, если сценарий, в котором клиент пытается использовать метод с именем TutorialID в классе GetTutorial.
Приведенное ниже сообщение об ошибке генерируется в том случае, если метод не существует в определенном классе.
Вывод:
Когда вы выполните приведенный выше код, он покажет ошибку типа «Не удалось найти метод (GetTutorialID) в классе (GetTutorial)»
Модель связи SOAP.
Вся связь по SOAP осуществляется по протоколу HTTP. До SOAP многие веб-сервисы использовали стандартный стиль RPC (удаленный вызов процедур) для связи. Это был самый простой тип общения, но у него было много ограничений.
Давайте рассмотрим диаграмму ниже, чтобы увидеть, как работает эта связь. В этом примере давайте предположим, что на сервере размещен веб-сервис, который предоставил 2 метода:
При обычной связи в стиле RPC клиент просто вызывает методы в своем запросе и отправляет необходимые параметры на сервер, а затем сервер отправляет желаемый ответ.
Приведенная выше модель связи имеет следующие серьезные ограничения
Чтобы преодолеть все ограничения, указанные выше, SOAP будет использовать следующую модель связи
Практический пример SOAP
Давайте посмотрим на практический пример,
Вероятно, один из лучших способов увидеть, как генерируются SOAP-сообщения, — это реально увидеть веб-сервис в действии.
В этом разделе рассматривается использование инфраструктуры Microsoft.Net для создания веб-службы ASMX. Этот тип веб-службы поддерживает SOAP версии 1.1 и 1.2.
Веб-службы ASMX автоматически создают документ языка определения веб-служб (WSDL). Этот WSDL-документ требуется вызывающему клиентскому приложению, чтобы приложение знало, на что способен веб-сервис.
В нашем примере мы собираемся создать простой веб-сервис, который будет использоваться для возврата строки в приложение, которое вызывает веб-сервис.
Visual Studio также покажет нам, что SOAP-сообщение передается между веб-службой и вызывающим приложением.
Первым предварительным условием для установки нашего приложения веб-службы, которое можно выполнить, выполнив следующие шаги.
Пожалуйста, убедитесь, что у вас установлена Visual Studio 2013 в вашей системе для этого примера.
Шаг 1) Первый шаг — создать пустое веб-приложение ASP.Net. В Visual Studio 2013 щелкните пункт меню Файл-> Новый проект.
После того, как вы нажмете на опцию «Новый проект», Visual Studio предоставит вам другое диалоговое окно для выбора типа проекта и предоставления необходимых деталей проекта. Это объясняется на следующем шаге.
Шаг 2) На этом этапе
После этого вы увидите файл проекта, созданный в обозревателе решений в Visual Studio 2013.
Шаг 3) На этом этапе
Мы собираемся добавить файл веб-службы в наш проект
Шаг 4) Добавьте следующий код в файл asmx Tutorial Service.
Объяснение кода:
Если код выполнен успешно, при запуске кода в браузере будет показан следующий вывод.
Вывод:
Запрос SOAP, который генерируется при вызове веб-службы, показан ниже.
Объяснение кода:
Объяснение кода:
Резюме