Soap что это за программа

Содержание

Soap что это за программа

Применение SOAP при интеграции систем

Для начинающих аналитиков,

не имеющих опыта web-разработки

Смотреть запись вебинара
Историческая справка

В предыдущей статье мы говорили про то, что REST — это архитектурный стиль, который Рой Филдинг сформулировал в своей диссертации в 2000 году.

С протоколом SOAP дела обстоят несколько иначе.
SOAP — это не стиль, а протокол. Аббревиатура SOAP так и расшифровывается: Simple Object Access Protocol — простой протокол доступа к объектам. То есть правила передачи информации в SOAP строго стандартизированы, есть спецификация, которой нужно соответствовать.

SOAP появился 1998 году и был передан в организацию World Wide Web Consortium (W3C) — международная организация, которая курирует развитие интернета.

Почему разница в 2 года в появлении REST и SOAP так сказалась на их популярности?

Все просто — компания Microsoft активно вкладывала деньги в продвижении SOAP. На тот момент Microsoft активно продвигал свою новую платформу .NET (платформа, в которой все конфигурационные файлы представлены в формате XML, и используется протокол SOAP). Так вот, на рекламу этой платформы Microsoft потратил 200 млн долларов.

Различия REST и SOAP за 4 минуты

Если сравнить это с тем фактом, что Рой Филдинг просто представил REST в своей диссертации, то вы поймете, почему SOAP завоевал популярность очень быстро.

Тем не менее на данный момент можно говорить о том, что в основном для интеграции систем используется REST.

Жив ли еще SOAP?

Просмотрев статистику вакансий на сайте hh.ru, можно обнаружить, что примерно четверть вакансий аналитиков содержат требования к знанию SOAP, WSDL и, как следствие, XML. В основном это крупные компании, которые занимаются проектами более 10 лет (банки, телеком).

В чем разница между REST и SOAP?

Для того, чтобы наглядно показать отличие REST от SOAP, приведем вот такую аналогию. Представьте себе дерево, в котором есть дупло, и из этого дупла выглядывает птичка. Когда вы обращаетесь к какому-то приложению, вы как будто обращайтесь к такому дереву и стучитесь в окошко. Условно можно считать, что в это окошко выглядывает некоторая функция.

Если вы работаете с REST, то можно себе представить дерево, в котором есть много таких окошек — большое количество птичек, каждая из которых выглядывает из своего дупла. Это дупло называется Endpoint, но это отдельный разговор. Важно, что каждый раз, обращаясь к дуплу, вы обращаетесь только к одной функции.

SOAP основывается на технологии удаленного вызова процедур. Сервис, который работает на базе SOAP — это дерево с одним-единственным дуплом. Но каждый раз, обращаясь к этому дуплу, вы должны указать название процедуры, то есть название функции, которую вы хотите вызвать, потому что функций там может быть несколько. И, разумеется, вы должны передать те входные данные, которые нужны для процедуры, которую вы собираетесь вызвать.

Что происходит, когда мы отправляем SOAP или REST запрос

Стандарт;протокол;архитектурный стиль Создан;1998, Дейв Винер, передан в W3C;Рой Филдинг, 2000 Транспорт; HTTP;HTTP Формат обмена сообщениями;XML;можно использовать XML, JSON или любой другой удобный формат Описание сервиса;использует WSDL (Web Services Description Language) — язык описания веб-сервисов и доступа к ним, основанный на языке XML;не имеет стандартного языка определения сервиса

Источник: systems.education

Рельсы веб-интеграции. 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

SOAP (Simple Object Access Protocol) — данные передаются в формате XML.

отраслевой стандарт по версии W3C;
наличие строгой спецификации;
широкая поддержка в продуктах Microsoft,
однозначность.

сложность реализации;
сложность/ресурсоемкость парсинга XML-данных.

Любое сообщение в протоколе SOAP — это XML документ, состоящий из следующих элементов (тегов):

Envelope. Корневой обязательный элемент. Определяет начало и окончание сообщения.
Header. Необязательный элемент — заголовок. Содержит элементы, необходимые для обработки самого сообщения. Например, идентификатор сессии.
Body. Основной элемент, содержит основную информацию сообщения. Обязательный.
Fault. Элемент, содержащий информацию об ошибках, возникающих в процессе обработки сообщения. Необязательный.

Пример SOAP запроса:

Пример SOAP ответа:

REST

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 есть почти в каждом языке).

отсутствие спецификации;
неоднозначность методов управления данными.

Что же использовать?

Вопрос «Какой способ реализации использовать?» необходимо рассматривать в контексте реализуемой системы и ее ограничений. Обычно, SOAP используется в крупных корпоративных системах со сложной логикой, когда требуются четкие стандарты, подкрепленные временем. XML-RPC, пожалуй, устарел и не имеет смысла ввиду наличия собрата JSON-RPC. RPC-протоколы подойдут для совсем простых систем с малым количеством единиц информации и API-методов.

Если же вы разрабатываете публичное API и логика взаимодействия во многом покрывается четверкой методов CRUD — смело выбирайте REST. Он наиболее популярен в WEB. Яндекс, Google и другие используют именно его для своего API.

Веб-сервисы в живом производстве

Разработка веб-сервисов — типичная задача интеграции. ИНТЕРВОЛГА, как веб-интегратор, регулярно сталкивается с задачами разработки веб-сервисов и успешно с ними справляется. Наши сайты были и SOAP/REST серверами, и SOAP/REST клиентами.

Еще один личный кабинет для клиентов компании Евраз — еще один пример сайта в качестве клиента удаленного SOAP веб-сервиса.

Если у вас есть потребность организовать взаимодействие с веб-сервисом, сделать из сайта REST/SOAP/RPC клиент или сервер, пишите нам.

Подведем итог, выделив, два важных тезиса в пользу выбора веб-сервисов в качестве «рельс» для веб-интеграции.

Наш опыт неоднократно демонстрировал, что создание веб-сервисов, в реальном времени передающих необходимые данные между сайтом и другим ПО — лучшее решение, чем классические обмены по расписанию. Такой подход проще сопровождать, вести его отладку, это более эффективная трата времени программиста, чем проектирование и разработка сложного двунаправленного обмена с кучей сущностей.
Можно провести аналогию с эволюцией разработки сайтов. Когда-то, на заре сайтостроения, каждый разработчик делал сайт с нуля на той технологии, которую мог знать лишь он один. Это порождало проблемы в развитии таких сайтов. Как работали такие сайты — знал только автор кода. Со временем появлялись фреймворки и CMS. Разработку начинали не с нуля, а с известных широкой массе разработчиков «заготовок» — стандартных решений стандартных проблем с возможность расширения и углубления.

Источник: habr.com

Что такое SOAP?

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

Отслеживать
задан 29 сен 2013 в 18:27
653 1 1 золотой знак 9 9 серебряных знаков 16 16 бронзовых знаков

Я вижу вы последовали моей рекомендации почитать про SOAP, чтобы понять, почему XML является востребованным форматом. Это хорошо 🙂 Чуть позже я напишу вам ответ, где доступными словами объясню назначение и его практическое применение.

29 сен 2013 в 19:15

6 ответов 6

Сортировка: Сброс на вариант по умолчанию

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

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

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

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

Ну вот, один из вариантов общения с такими серверами — это 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-сервером, чтобы типы данных, ограничения соответствовали описанию.

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

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

Использование протокола SOAP в распределенных приложениях

Simple Object Access Protocol (SOAP) – основанный на XML протокол, предназначенный для обмена информацией в распределенных системах. SOAP устанавливает стандарт взаимодействия клиент-сервер и регламентирует, как должен осуществляться вызов, передаваться параметры и возвращаемые значения. Для представления любой информации, передаваемой от клиента к серверу и наоборот, используется XML.

ПРИМЕЧАНИЕ

SOAP не накладывает ограничений на используемый транспорт. Для передачи сообщений могут использоваться любые протоколы и продукты, например, протоколы HTTP, HTTPS, SMTP. Данные могут передаваться через Microsoft Message Queueing, IBM MQ Series и т.д. Однако чаще всего используется протокол HTTP. Microsoft SOAP Toolkit включает в себя только поддержку HTTP.

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

Одна из наиболее известных технологий – DCOM, позволяющая эффективно осуществлять RPC-вызовы, передавать и принимать данные, распределять нагрузку между несколькими back-end серверами. Однако у систем, построенных на DCOM, есть очень важный недостаток, затрудняющий взаимодействие уровня представления и уровня бизнес-логики через Internet.

Хотя DCOM-приложения могут использовать TCP/IP для передачи вызовов RPC, большинство современных сетевых экранов будут запрещать передачу таких пакетов из соображений безопасности. Конечно, с помощью утилиты DCOMCNFG можно настроить DCOM на использование любого порта в диапазоне от 1024 до 65535. Но при изменении настроек одного из промежуточных файрволлов DCOM может перестать работать. Можно сказать, что DCOM является доминирующей технологией для обмена информацией и передачи вызовов в пределах корпоративной локальной сети, но при выходе за ее пределы DCOM приносит большое количество хлопот, связанных с настройкой портов, файрволлов и т.д.

ПРИМЕЧАНИЕ

Чтобы расширить сферу применения DCOM, Microsoft выпустила COM Internet Services (CIS). CIS использует специальный “туннельный” TCP-протокол, позволяющий DCOM-приложениям осуществлять RPC-вызовы через порт 80. На стороне сервера находится ISAPI-расширение, перехватывающее запросы, идущие на порт 80, и перенаправляющее их дальше для обработки с помощью обычного RPC. Особенностью CIS является то, что только начальное “рукопожатие” клиента с сервером происходит в соответствии с протоколом HTTP, остальной трафик не является HTTP (сделано это, видимо, из соображений эффективности). Поэтому, несмотря на использование 80-го порта, CIS не устраняет проблему сетевых экранов, которые могут запретить передачу “подозрительных” пакетов.

Альтернативой DCOM при построении распределенных систем может служить использование Web-интерфейса на основе ASP. В таких системах от клиента ничего не требуется, кроме наличия браузера, способного соединиться с корпоративным Web-сервером. Для передачи запроса от клиента к серверу можно применить, например, метод POST для HTML-формы, а обработка запроса будет происходить уже на серверной стороне. Несмотря на популярность такого подхода, у него есть недостатки – состав передаваемой информации, а главное, способ ее передачи в методе POST специфичны для конкретного приложения. А если на уровне представления необходим полноценный пользовательский интерфейс Windows-приложения, не миновать проблем.

Как в этом случае может быть построено взаимодействие клиента с сервером? И, наконец, как быть, если необходимо обеспечить поддержку не только HTTP, но, например, SMTP или MSMQ (для асинхронного взаимодействия)? Эти задачи можно решить следующим образом:

Преобразовать вызов в текстовое представление с сохранением информации обо всех параметрах и их значениях.
Передать текст на сервер по HTTP, SMTP и т.д.
Интерпретировать текстовое сообщение на сервере и осуществить вызов некоторого метода.
Преобразовать out-параметры или информацию об ошибке, возвращаемые методом, в текстовое представление.
Передать текст клиенту по HTTP, SMTP и т.д.
Интерпретировать результат.

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

Необходимо упомянуть о еще одном достоинстве протокола SOAP – он нейтрален к платформе, т.е. не накладывает ограничений на платформы, которые используются клиентом и сервером. Запрос клиента, работающего под управлением Windows 98, может быть обработан сервером под управлением Unix.

Simple Object Access Protocol

SOAP описывает преобразование в XML следующих элементов вызова:

Запрос (SOAP Request).
Отклик (SOAP Response).
Сообщение об ошибке (SOAP Fault).

SOAP Request

Вызов метода по протоколу SOAP преобразуется в XML следующим образом:

В приведенном примере запроса вызывается метод Add, которому передаются два параметра: 1 и 2. Информация о том, какой метод и у какого объекта необходимо вызвать, передается в заголовке. В случае протокола HTTP заголовок может выглядеть так:

soapaction>»http://tempuri.org/Sample1/action/Adder.Add» text/xml; charset=»UTF-8″ SOAP Toolkit 3.0 ivan:8080 516 Keep-Alive no-cache no-cache

В теге SoapAction указывается, какое действие необходимо выполнить на сервере.

SOAP Response

Ответ сервера содержит значения возвращаемых параметров.

В данном случае сервер ответил на вызов метода Add с параметрами 1 и 2 значением 3.

SOAP Fault

В случае возникновения ошибок до или во время обработки запроса сервер возвращает информацию об ошибке. Ошибки могут быть двух типов:

Клиентские ошибки. Неправильный запрос к серверу. Запрос содержит неверные значения параметров, неправильно сформирован и т.д.
Серверные ошибки. Ошибки могут быть связаны как с функционированием самого сервера (закончились свободные ресурсы), так и с обработкой запроса (компонент вернул ошибку).

Пример серверной ошибки:

SOAP-ENV:Server Can add no more numbers http://ivan:8080/Sample1/Sample1.ASP -2147467259 : Unspecified error Can add no more numbers Sample1.Adder.1 WSDLOperation Executing method Add failed -2147352567 : Exception occurred. .

В теге faultcode указывается источник ошибки – клиент или сервер. Faultstring содержит строковое описание ошибки. Faultfactor – указывает URL, по которому обращался клиент. Тег detail содержит дополнительную информацию об ошибке (например, call stack).

Microsoft SOAP Toolkit 3.0

Разработку распределенных приложений, использующих протокол SOAP, необязательно начинать с нуля, существует большое количество наборов компонентов, облегчающих процесс разработки и берущих на себя обработку различных этапов вызова и получения отклика от сервера. В этой статье мы будем рассматривать один из таких “наборов” – Microsoft SOAP Toolkit, который в значительной степени облегчает процесс создания серверных компонентов SOAP, обеспечивающих прием и обработку запросов, и предоставляет стандартный Proxy, реализующий динамический IDispatch –интерфейс, что позволяет легко преобразовывать вызовы COM в SOAP-запросы.

Состав

SOAP Toolkit включает в себя следующие части:

SOAP Listener – серверные компоненты, предназначенные для обработки входящих запросов. Представлены в 2-х разновидностях – ASP-страница и ISAPI-расширение.
Proxy – клиентский компонент, позволяющий преобразовать вызов метода, осуществляемый через IDispatch-интерфейс, в SOAP-вызов.
Утилита для трассировки SOAP-вызовов, позволяет перехватывать вызовы к серверу и анализировать запросы и ответы сервера.
WSDL-генератор. По библиотеке типов компонента генерирует файлы, необходимые для работы SOAP Listener’а и Proxy. В этих файлах находятся описания методов, параметров, типов параметров и т.д.
Набор низкоуровневых компонентов, предназначенных для создания SOAP-запросов, преобразования различных типов данных в текстовый формат, приема и передачи пакетов по протоколу HTTP и преобразования ответа сервера.
Документация и примеры.

WSDL- и WSML-файлы

WEB Service Description Language (WSDL) основан на XML и предназначен для описания тех сервисов, которые поддерживает сервер. Для каждого сервиса в WSDL-файле перечисляется набор операций, поддерживаемых данным сервисом, а также определяется формат сообщения, которого должен придерживаться клиент, чтобы сформировать правильный запрос.

WSDL-файл задает контракт между сервером и клиентом, который клиент обязан выполнять, чтобы быть обслуженным.

Основные разделы WSDL-файла:

Схема – – описывает сложные типы данных, используемые в параметрах методов.

Описание SOAP-сообщений –

Описание SOAP-портов и операций, которые поддерживаются этими портами:

Источник: www.rsdn.org

SOAP для чайников

Постараюсь коротко и своими словами. SOAP сейчас весьма популярный протокол web API сервисов. То есть способ взаимодействия Вашей информационной системы через web с другими информационными системами.

В самом общем виде SOAP это протокол обмена структурированными XML сообщениями в произвольной распределенной вычислительной среде. Отсюда следует, что мы должны куда-то передать XML и получить назад также XML. Для передачи нам нужен транспорт. Или протокол передачи данных. Например SMTP, FTP, HTTP, HTTPS.

Чаще всего HTTP, но это не принципиально.

Залогом успеха нашего обмена является способность правильно создать и передать XML запрос и правильно принять и разобрать XML ответ. Для того чтобы сделать все правильно нужно соблюдать (извиняюсь за тавтологию) правила. Эти правила описываются файлом специального формата: WSDL. WSDL — это язык описания правил использования web сервисов в том числе и сервиса SOAP.

Встроенный в 1С объект платформы WS-ссылка позволяет нам загрузить эти правила и на их основе использовать web сервис с максимальным удобством. Поставщик сервиса разрабатывает правила и размещает их по доступному для клиентов адресу. Естественно, что изменения в работе сервиса должны в случае необходимости сопровождаться внесением изменений в WSDL инструкцию.

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

В общем-то объект WS-ссылки и создается и задается всего лишь ссылкой на WSDL правило:

После создания WS-ссылки и загрузки правил Вы можете просмотреть набор возможных методов и наборы их параметров с типизацией.

Вызвав одной универсальной функцией нужный метод (предварительно создав и передав нужную ему структуру параметров) SOAP сервиса Вы уже можете видеть результат в виде дерева. Описание ответных данных как правило содержится в документации поставщика, но это не обязательно. В любом случае в качестве ответа Вы получите некую структуру данных в виде XML файла, которая в общем виде может быть приведена к типу данных 1С «ДеревоЗначений». Вот это-то дерево и будет у Вас при любом вызове любого метода. Вызовите в этот момент отладчик для просмотра или выведите дерево результата на форму и разберитесь с каких ветвей снять заветные «плоды»-результаты. И все:)

Вот как просто можно вызвать и получить результаты разных методов в абсолютно разных сервисах (во втором примере метод без параметров):

Но как и в жизни в методы SOAP тоже можно обозначить как процедуры и функции. Процедуру мне посчастливилось увидеть всего один раз. Да и то, потому что публичный сервис с информацией о странах, который я использовал в качестве примера №1 перестал работать (на скрине он еще показан) и пришлось свочно искать ему замену. Что же делать с процедурой, ведь она не вернет нам ответ и не из чего будет создать дерево и, следовательно, неоткуда сорвать результат?

Но (опять же как часто бывает в жизни) с процедурой все стало даже проще. Она возвращает результат в свои же параметры. Как на скрине ниже:

Так как ПолучитьДеревоРезультатовДляSOAP задумывалась как функция то я ее заставил вернуть результат. В данном случае, не деревом, а структурой, содержащей выходные парметры метода. Какие из параметров выходные Вы всегда можете просмотреть в их свойствах. Хотя можно и не смотреть. Структура в результате будет содержать все выходные параметры метода.

В нашем примере это «image» и «encoding». Получить результат из структуры оказывается еще проще. Если с дерева нужно «доставать», то в структуре все уже готово к употреблению.

В последний год мне довелось трижды связывать через web API свою конфигурацию с поставщиками услуг и информации, для получения данных или заказа услуг (например услуги доставки товара или рассылки СМС). В последний раз имея готовый код примера и обработку для 1С от поставщика я отказался от них и выбрал вариантом решения универсальный SOAP сервис. Просто потому, что так оказалось с наработанными ранее функциями проще.

Для данной публикации специально нашел парочку публичных SOAP ресурсов и слепил использующую их конфигурацию. 95% времени заняла работа с формами вызова и вывода данных. Зато в демке Вы можете видеть курс валют от ЦБ РФ на любую дату и краткий набор сведений о любой стране мира скриншот web страницы для произвольного url.

В общем кому лень или некогда разбираться с этим вот всем, а нужно сделать быстро и чтобы работало ссылка на скачивание демо конфигурации после публикации.

И пункт обязательной программы:) Тестировалось на релизе платформы 8.3.9.2309.

Спасибо за внимание и удачных всем разработок!

Источник: infostart.ru