Soap что это в программировании

SOAP API

В конце 1990-х годов протокол SOAP был разработан для обмена данными в формате XML между клиентом и сервером. Давайте разберемся что такое SOAP API сейчас и в каких случаях его использовать. Поговорим о недостатках, а также почему ему на пятки наступает REST API.

SOAP(Simple Object Access Protocol) — это протокол обмена сообщениями между компьютерными системами.

SOAP API (Application Programming Interface) — это интерфейс, который позволяет взаимодействовать с удаленными сервисами или приложениями с использованием SOAP протокола. SOAP API основан на использовании XML для описания структуры и содержимого сообщений. Сообщения в SOAP API представляют собой XML-документы, которые содержат данные и вызовы методов для удаленного выполнения операций.

Базовые понятия SOAP API

Пакеты. В SOAP API данные передаются в виде пакетов — это обертки для информации, передаваемой между клиентом и сервером. Каждый пакет содержит заголовок (header) и тело (body). В заголовке можно указать дополнительные метаданные, такие как информацию о безопасности или версии протокола. В теле пакета находятся сами данные, которые могут быть представлены в виде XML-структуры.

Правила кодировки. SOAP API работает с XML для кодирования данных. XML (eXtensible Markup Language) использует теги и атрибуты для описания структуры данных. SOAP определяет набор правил, которые определяют, как данные должны быть представлены в XML-формате. Например, SOAP определяет правила для сериализации объектов, передачи значений и обработки ошибок.

Стили взаимодействия. SOAP API поддерживает различные стили взаимодействия, которые определяют, как клиент и сервер обмениваются данными, например:

• RPC-стиль. В RPC-стиле клиент вызывает удаленный метод на сервере, передавая ему параметры. Сервер выполняет метод и возвращает результат обратно клиенту. RPC-стиль абстрагирует вызовы удаленных методов, делая их похожими на вызовы локальных методов.
• Document-style. В Document-стиле данные передаются в виде XML-документа. Вместо вызова методов, клиент и сервер обмениваются структурированными XML-данными. Document-style более гибкий и позволяет передавать сложные объекты и атрибуты.

Модель данных SOAP

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

Элементы модели данных SOAP

Элементы XML: нужны для представления данных в SOAP сообщениях. Каждый элемент имеет имя и может содержать другие элементы или текстовые данные.

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

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

Сложные типы данных: структуры и массивы. Структуры содержат несколько элементов разных типов, а массивы — несколько элементов одного типа.

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

Что может SOAP API

• Создавать структурированные сообщения: при помощи описания формата сообщений в XML, который понятен для большинства языков программирования и платформ
• Работать с различными протоколами: такими как HTTP, HTTPS, SMTP, FTP. Это делает его гибким и позволяет интегрировать системы, использующие разные протоколы
• Поддерживать разные платформы и языки программирования: такие как Java, .NET, PHP. Это делает его доступным для широкого круга разработчиков и позволяет создавать межплатформенные приложения
• Расширять функциональность: SOAP API позволяет определять собственные пользовательские типы данных и имеет такие расширения, как WS-Security для обеспечения безопасности или WS-ReliableMessaging для обеспечения надежной доставки сообщений.

Популярность и актуальность

SOAP API нашел широкое применение в интеграции между системами, особенно в крупных предприятиях, где требуется обмен данными между приложениями и платформами. Также он используется в веб-сервисах для предоставления API для внешних разработчиков.

В последние годы популярность SOAP снизилась в связи с развитием более легковесных и простых в использовании протоколов, таких как REST (Representational State Transfer). REST API стал более известным из-за своей простоты, гибкости и поддержки форматов данных, таких как JSON.

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

Отличия SOAP от REST

Архитектура:

• REST использует стандартные HTTP-методы, такие как GET, POST, PUT и DELETE
• SOAP работает с форматом XML для сериализации данных и предоставляет возможность обмена сложными объектами и атрибутами.

Протокол передачи данных:

• REST основан на протоколе HTTP
• SOAP более гибок в выборе протокола передачи данных.

Формат данных:

• REST работает как с JSON, XML, так и с простым текстом.
• SOAP использует XML для сериализации и передачи данных.

Универсальность и простота использования:

• REST прост и гибок в использовании.
• SOAP предоставляет богатый набор функций и поддерживает сложные операции и транзакции. SOAP требует наличия WSDL (Web Services Description Language) для описания веб-служб.

Пример SOAP API

Пример REST API

GET /api/stocks/IBM HTTP/1.1 Host: example.com

В примере SOAP мы видим структурированное XML-сообщение, в котором указывается операция GetStockPrice и параметр StockName со значением IBM.

В примере REST мы видим простой HTTP-запрос GET, в котором указывается адрес ресурса /api/stocks/IBM для получения информации об акции IBM.

В каких случаях используют SOAP API

• В интеграции сложных систем. SOAP поддерживает передачу сложных объектов и атрибутов, что позволяет эффективно обмениваться данными между системами.
• Когда есть необходимость в строгих стандартах безопасности с поддержкой SSL. SOAP API использует WS-Security для обеспечения безопасности приложений на уровне предприятия и для связи с унаследованными системами.
• Когда нужны надежные функции обмена сообщениями. Если вам необходимо гарантировать, что сообщения будут доставлены в надежном порядке и без потерь, то SOAP API обеспечит надежную доставку сообщений между системами при помощи расширения WS-ReliableMessaging.
• Когда необходимо сохранить конфиденциальность. SOAP API включает в себя соответствие стандарту ACID (Atomicity, Consistency, Isolation, and Durability) и это соответствие уменьшает избыточность и повышает безопасность и целостность сообщений.

Недостатки SOAP

• Объемные сообщения: SOAP API использует XML для сериализации данных, что приводит к увеличению объема передаваемых сообщений. Проблемы возникают при передаче больших объемов данных или при работе с медленными сетевыми соединениями.
• Поддержка только одного формата: SOAP API ограничен использованием только XML в качестве формата данных. В некоторых случаях это может означать дополнительные накладные расходы на преобразование данных из других форматов в XML и обратно.
• Один запрос — один ответ: клиент должен отправить запрос и дождаться ответа от сервера, прежде чем продолжить выполнение следующих операций. Это может привести к блокировке клиентского приложения, если запрос долго обрабатывается.
• Возможность нарушения работы клиента при смене описания веб-сервиса: смена описания потребует дополнительных усилий для согласования изменений между поставщиком и потребителем сервиса.

SOAP API

SOAP — это протокол, по которому веб-сервисы взаимодействуют друг с другом или с клиентами. Название происходит от сокращения Simple Object Access Protocol («простой протокол доступа к объектам»). SOAP API — это веб-сервис, использующий протокол SOAP для обмена сообщениями между серверами и клиентами. При этом сообщения должны быть написаны на языке XML в соответствии со строгими стандартами, иначе сервер вернет ошибку.

Освойте профессию «Frontend-разработчик»

Появление, развитие и актуальность SOAP API

Протокол SOAP был представлен в 1998 году и быстро стал одним из главных стандартов веб-служб, когда Microsoft продвигала платформу .NET, приложения которой взаимодействовали с помощью SOAP API. Сейчас протокол и API уступают по популярности архитектурному стилю REST. Но веб-приложения, использующие SOAP API, все еще пользуются спросом, особенно в банковском и телекоммуникационном секторах.

Профессия / 9 месяцев
Frontend-разработчик

Создавайте интерфейсы сервисов, которыми пользуются все

Особенности SOAP API

SOAP может использоваться с протоколами SMTP, FTP, HTTP, HTTPS. Чаще всего — с HTTP как с наиболее универсальным: его поддерживают все браузеры и серверы. Корректное SOAP-сообщение состоит из нескольких структурных элементов: Envelope, Header, Body и Fault.

Envelope («конверт»). Это корневой элемент. Определяет XML-документ как сообщение SOAP с помощью пространства имен xmlns_soap=»http://www.w3.org/2003/05/soap-envelope/». Если в определении будет указан другой адрес, сервер вернет ошибку.

Header («заголовок»). Включает в себя атрибуты сообщения, связанные с конкретным приложением (аутентификация, проведение платежей и так далее). В заголовке могут использоваться три атрибута, которые указывают, как принимающая сторона должна обрабатывать сообщение, — mustUnderstand, actor и encodingStyle. Значение mustUnderstand — 1 или 0 — говорит принимающему приложению о том, следует ли распознавать заголовок в обязательном или опциональном порядке. Атрибут actor задает конкретную конечную точку для сообщения. Атрибут encodingStyle устанавливает специфическую кодировку для элемента. По умолчанию SOAP-сообщение не имеет определенной кодировки.

Body («тело»). Сообщение, которое передает веб-приложение. Может содержать запрос к серверу или ответ от него. Пример сообщения, которое запрашивает стоимость ноутбука в онлайн-магазине:

Пример ответа сервера онлайн-магазина:

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

Fault («ошибка»). Опциональный элемент. Передает уведомление об ошибках, если они возникли в ходе обработки сообщения. Может содержать вложенные элементы, которые проясняют причину возникновения ошибки:

• faultcode — код неполадки;
• faultstring — «человекопонятное» описание проблемы;
• faultactor — информация о программном компоненте, который вызвал ошибку;
• detail — дополнительные сведения о месте возникновения неполадки.

Читайте также Кто такой frontend-разработчик?

Отличия SOAP от REST

SOAP — протокол, а REST — архитектурный стиль, набор правил по написанию кода. REST был представлен в 2000 году. К этому времени недостатки SOAP были очевидны:

• объемные сообщения;
• поддержка только одного формата — XML;
• схема работы по принципу «один запрос — один ответ»;
• смена описания веб-сервиса может нарушить работу клиента.

Разработчик стиля REST Рой Филдинг учел недостатки SOAP. REST поддерживает несколько форматов помимо XML: JSON, TXT, CSV, HTML. Вместо создания громоздкой структуры XML-запросов при использовании REST чаще всего можно передать нужный URL. Эти особенности делают стиль REST простым и понятным, а приложения и веб-сервисы, использующие его, отличаются высокой производительностью и легко масштабируются.

Пример простого URL-запроса, возвращающего результаты поиска по ключевому слову DNA («ДНК»), можно посмотреть в международной базе научных статей.

Несмотря на простоту использования, у REST есть ряд недостатков, которые отсутствуют у SOAP:

• при использовании REST сложнее обеспечить безопасность конфиденциальных данных;
• трудности с проведением операций, которым необходимо сохранение состояния. Как, например, в случае с корзиной в онлайн-магазине, которая должна сохранять добавленные товары до момента оплаты.

Основные различия SOAP и REST API мы собрали в таблице для большей наглядности:

В каких случаях используют SOAP

• Асинхронная обработка и последующий вызов. Стандарт SOAP 1.2 обеспечивает клиенту гарантированный уровень надежности и безопасности.
• Формальное средство коммуникации. Если клиент и сервер имеют соглашение о формате обмена, то SOAP 1.2 предоставляет жесткие спецификации для такого типа взаимодействия. Пример — сайт онлайн-покупок, на котором пользователи добавляют товары в корзину перед оплатой. Предположим, что есть веб-служба, которая выполняет окончательный платеж. Может быть достигнуто соглашение, что веб-сервис будет принимать только название товара, цену за единицу и количество. Если сценарий существует, лучше использовать протокол SOAP.
• Операции с состоянием. Если приложение требует, чтобы состояние сохранялось от одного запроса к другому, то стандарт SOAP 1.2 предоставляет структуру для поддержки таких требований.

Frontend-разработчик

Научитесь создавать удобные и эффектные сайты, сервисы и приложения, которые нужны всем. Сегодня профессия на пике актуальности: в России 9000+ вакансий, где требуется знание JavaScript.

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

SOAP и REST – это два механизма обмена данными в Интернете. Например, представьте, что ваша внутренняя бухгалтерская система передает данные бухгалтерской системе клиента с целью автоматизации задач выставления счетов. Оба приложения обмениваются данными с помощью API, определяющего правила связи. SOAP и REST – это два разных подхода к разработке API. Подход SOAP отличается высокой степенью структурированности и использует формат данных XML. REST более гибкий и позволяет приложениям обмениваться данными в нескольких форматах.

В чем сходство между SOAP и REST?

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

SOAP и REST можно использовать для создания API или точек связи между различными приложениями. Термины веб-сервис и API используются взаимозаменяемо. Однако API – это более широкая категория. Веб-сервисы – это особый тип API.

Ниже приведены другие сходства между SOAP и REST.

• В обоих протоколах описываются правила и стандарты того, как приложения создают и обрабатывают запросы данных от других приложений, а также реагируют на них.
• Они оба используют для обмена информацией стандартизированный интернет-протокол HTTP.
• Они оба поддерживают SSL/TLS для безопасной зашифрованной связи.

Для создания безопасных, масштабируемых и отказоустойчивых распределенных систем можно использовать SOAP или REST.

В каких случаях следует использовать SOAP и REST?

Прежде чем выбирать между SOAP и REST, изучите сценарии и требования пользователей API. Заслуживают внимания нижеприведенные критерии.

Общий дизайн приложения

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

Безопасность

Общедоступные API предъявляют более низкие требования к безопасности и требуют большей гибкости, благодаря чему с ними может взаимодействовать любой желающий. Поэтому REST – лучший выбор при создании общедоступных API. И наоборот, некоторые частные API для выполнения внутренних корпоративных задач (например, для составления отчетов для обеспечения соответствия требованиям) могут выиграть от ужесточения мер безопасности в WS-Security of SOAP.

Соответствие требованиям ACID

Требуется ли вашим пользователям API строгая согласованность и целостность данных во всей цепочке транзакций? Например, финансовые транзакции требуют сбоя целого пакета обновлений данных в случае сбоя хотя бы одного обновления.

SOAP имеет встроенный набор свойств ACID. И SOAP, возможно, лучше подходит для удовлетворения высоких требований к целостности данных. В этом случае REST API могут потребоваться дополнительные программные модули для контроля состояния на уровне сервера или базы данных.

Каков принцип работы SOAP API и REST API?

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

SOAP API

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

• Web Services Security (WS-Security) определяет меры безопасности, такие как использование уникальных идентификаторов – токенов.
• Web Services Addressing (WS-Addressing) требует включения маршрутной информации в виде метаданных.
• WS-ReliableMessaging стандартизирует обработку ошибок в сообщениях SOAP.
• Язык описания веб-сервисов (Web Services Description Language, WSDL) определяет область применения и функции веб-сервисов SOAP.

При отправке запроса в SOAP API необходимо обернуть HTTP-запрос в конверт SOAP. Это структура данных, которая изменяет базовый HTTP-контент в соответствии с требованиями к запросам SOAP. Благодаря конверту вы также можете отправлять запросы веб-сервисам SOAP с помощью других транспортных протоколов, таких как TCP или Протокол межсетевых управляющих сообщений (Internet Control Message Protocol, ICMP). Однако SOAP API и веб-сервисы SOAP всегда возвращают в своих ответах XML-документы.

REST API

REST – это архитектурный стиль программного обеспечения, который определяет шесть условий работы API. Ниже перечислены шесть принципов, которым следуют REST API.

1. Клиент-серверная архитектура. Отправитель и получатель независимы друг от друга в отношении технологии, платформы, языка программирования и т. д.
2. Многоуровневость. На сервере может быть несколько скрытых от клиентов посредников, которые совместно выполняют их запросы.
3. Единый интерфейс. API возвращает данные в стандартном формате, который является полным и полностью пригодным для использования.
4. Отсутствие состояний. API выполняет каждый новый запрос независимо от предыдущих.
5. Кэшируемость. Все ответы API можно кэшировать.
6. Код по запросу. При необходимости ответ API может включать фрагмент кода.

Запросы REST отправляются с использованием таких HTTP-команд, как GET и POST. Ответы Rest API обычно представлены в формате JSON, но также могут иметь другой формат данных.

Ключевые различия: SOAP и REST

SOAP – это протокол, а REST – архитектурный стиль. Это создает значительные различия в функционировании SOAP и REST API.

Проектирование

SOAP API раскрывают функции или операции, а REST API основаны на данных. В качестве примера рассмотрим приложение с данными сотрудников, которыми могут управлять другие приложения. SOAP API приложения может раскрыть функцию CreateEmployee. Чтобы создать запись о сотруднике, нужно указать название функции в сообщении SOAP при отправке запроса.

Однако REST API приложения может раскрыть URL-адрес /employees, и запрос POST на этот URL-адрес создаст новую запись о сотруднике.

Гибкость

SOAP API негибкие и допускают обмен сообщениями между приложениями только в формате XML. Сервер приложений также должен сохранять состояние каждого клиента. Это означает, что при обработке нового запроса он должен помнить все предыдущие.

REST более гибкий и позволяет приложениям передавать данные в виде обычного текста, HTML, XML и JSON. REST также не сохраняет состояние, поэтому REST API обрабатывает каждый новый запрос независимо от предыдущих.

Производительность

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

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

Масштабируемость

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

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

Безопасность

SOAP требует дополнительного уровня WS-Security для работы с HTTPS. WS-Security использует дополнительное содержимое заголовков, чтобы содержимое сообщений SOAP мог считывать только назначенный процесс на указанном сервере. Это увеличивает расходы на связь и негативно влияет на производительность.

REST поддерживает HTTPS без дополнительных накладных расходов.

Надежность

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

SOAP — это просто

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

Как ни странно, но SOAP ( Simple Object Access Protocol , кросс-платформенная , кросс-языковая технология запуска объектов) — это действительно просто, хотя когда я только начинал с ним работать на Delphi , никак не мог понять с какой стороны к нему подступиться. В действительности, при проектировании SOAP приложений необходимо выполнять совсем немного условий, после чего все будет прекрасно работать, и эти простые условия я и постараюсь тут рассмотреть.

Прежде всего, а зачем нужен этот самый SOAP? Основных плюса два: SOAP является public стандартом межпрограммного взаимодействия, и клиенту не надо ничего знать о сервере — ни о его языке, ни о платформе; SOAP интерфейсы являются самодокументирующимися, т.е. сервер обязан предоставить клиенту подробное описание интерфейса, его функций, входных и выходных параметров.

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

• нельзя явно управлять транзакциями с клиента (этим занимается сервер),
• соответственно нельзя заблокировать запись на время редактирования (разве что сделать специальные поля-флаги в БД),
• нельзя одной командой передать параметры, а другой считать результат — все должно происходить в рамках одной команды
• нельзя работать с классической связкой мастер-деталь (однако TClientDataset предоставляет для этого великолепное средство: nested datasets — вложенные таблицы),
• нельзя использовать свойство ClientDataSet.PacketRecords >0, т.к. сервер «не помнит», что он уже передал на клиента, а что — нет, подобную функциональность приходится реализовывать при помощи дополнительных параметров запроса,
• . если чего забыл — допишу позже

Замечание: чтобы запустить SOAP приложение, прежде всего нужен Web-сервер, если его у вас нет — дальше можете не читать. Для отладки можно воспользоваться WebAppDebugger из меню Tools , тогда серверную часть надо создавать как WebAppDebugger Executable (см .н иже, о работе с WebAppDebugger — см. документацию к Delphi )
Примечание от Ivan Babikov : можно найти в каталоге Indy IdHTTPWebBrokerBridge.pas , научиться делать SOAP executable и читать дальше

Простое SOAP-приложение

Подобные примеры рассмотрены в любой литературе, посвященной разработке SOAP на Delphi .
Запустите Delphi и выберите в меню File | New | Other . , перейдите на закладку WebServices и выберите Soap Server Application .

Вам будет предложено на выбор 5 вариантов:

• ISAPI/NSAPI Dinamic Link Libarry — подключаемая библиотека для серверов IIS/ Netscape , каждый запрос передается как структура и обрабатывается отдельным тредом ,
• CGI Stand-alone Executable — консольное приложение, получает запрос на стандартный вход, возвращает ответ на стандартный выход, каждый запрос обрабатывается отдельным экземпляром приложения,
• Win-CGI Stand-alone Executable — приложение Windows , обмен данными происходит через INI-файл (не рекомендуется к использованию, как устаревшее),
• Apache Shared Module (DLL) — подключаемая библиотека для сервера Apache , каждый запрос передается как структура и обрабатывается отдельным тредом ,
• WebAppDebugger Executable — подключаемая библиотека для отладочного сервера, поставляемого в составе Delphi , поскольку WebAppDebugger является также COM сервером, необходимо указать (произвольное) CoClass Name для COM объекта, с помощью которого будет вызываться ваш веб-модуль .

Выберите CGI Stand-alone Executable , как наиболее простой для отладки формат, потом приложение можно будет легко преобразовать в любой другой. Вся хитрость в том, что если вся логика приложения сосредоточена в написанных Вами модулях, то Вы просто создаете новое приложение нужного типа, подключаете к ниму свои модули, и оно работает!

После того, как Вы нажмете ОК, будет сгенерировано новое приложение, содержащее WebModule с тремя компонентами:

• THTTPSoapDispatcher — получает входящие SOAP пакеты и передает их компоненту, определенному его Dispatcher property (обычно THTTPSoapPascalInvoker ),
• THTTPSoapPascalInvoker — получает входящий SOAP запрос, находит в Invocation Registry вызываемый метод, выполняет ( invokes ) его, формирует ответ и передает его обрабно THTTPSoapDispatcher ,
• TWSDLHTMLPublish — формирует WSDL ( Web Services Description Language ), описание данных и интерфейсов, поддерживаемых Вашим модулем.

Сохраните созданное приложение, это будет скелет нашего сервера.

Примечание: если заменить THTTPSoapDispatcher и THTTPSoapPascalInvoker компонентами, поддерживающими другой транспортный механизм, отличный от HTTP, то можно заставить работать приложение, например, с обменом по e-mail .

Странность: позднее я заметил, что WebModule , создаваемый для WebAppDebugger , немного отличается от остальных вариантов приложений строками

uses

initialization 

 = TWebModule2; 

в чем тут дело я не разбирался, но без них приложние под WebAppDebugger-ом не работает.

Займемся наполнением его логикой. Поскольку и серверу и клиенту потребуются описания структур передаваемых данных и интерфейсов, то лучше их вынести в отдельный модуль, а всю серверную реализацию — в другой. Для этого создайте два модуля ( File | New | Unit ) и сохраните один из них под именем CentimeterInchIntf.pas , а другой — CentimeterInchImpl.pas . Внутри CentimeterInchIntf.pas наберите следующее:

unit  interface 

 uses 

 Types; 

 type 

 ICmInch = [''] 

 function Cm2Inch(Inch: Double): Double; stdcall; 

 function Inch2Cm(Cm: Double): Double; stdcall; 

 end; 

 implementation 

 uses 

 initialization 

  end.

Таким образом мы определили интерфейс ICmInch , предоставляющий две функции: преобразования сантиметров в дюймы и дюймов в сантиметры, и зарегистрировали его в InvokeRegistry .

Примечание: строку [»] — GUID нашего сервера, не надо копировать из этого примера, а надо сгенерировать в редакторе Delphi нажатием Ctrl-Shift-G

Разберемся с реализацией. В CentimeterInchImpl.pas определим потомка TInvokableClass , реализующего наш интерфейс ICmInch :

unit  interface 

 uses 

 InvokeRegistry; 

 type 

 TCmInch = public 

 function Cm2Inch(Inch: Double): Double; function Inch2Cm(Cm: Double): Double; stdcall; 

 end; 

 implementation 

 const 

 function TCmInch.Cm2Inch(Inch: Double): Double; 

 begin 

 Result := Inch / end; 

 function TCmInch.Inch2Cm(Cm: Double): Double; 

 begin 

 Result := Cm * end; 

 initialization 

  end. 

Как видите, в TCmInch мы реализовали обе функции интерфейса ICmInch , и также зарегистрировали наш новый invokable class в InvokeRegistry (вообще, все что будет передаваться по сети надо в нем регистрировать, за исключением скалярных типов).

Скомпилируем наше приложение и поместим полученный EXE-файл в каталог, откуда Web-сервер может запускать скрипты , например, / cgi-bin /, и обратимся к нему из браузера:
http://localhost/cgi-bin/MyWebService.exe/wsdl
В случае WebAppDebugger путь будет выглядеть так:
http://localhost:1024/MyWebService.exe/wsdl
Обратите внимание на дополнительный PathInfo в конце нашего URL. Должно получиться примерно следующее:

WebService Listing

Если нажать на ссылку WSDL for ICmInch , то мы получим полное WSDL описание нашего интерфейса.

Клиент

Создайте новое приложение (обычного типа), укажите в секции uses наш интерфейсный модуль CentimeterInchIntf , поместите на главную форму две кнопки, два поля ввода и компонент THTTPRIO с палитры WebServices .

У компонента HTTPRIO1 в свойстве WSDLLocation укажите путь к WSDL вашего сервиса (например, http://localhost/cgi-bin/MyWebService.exe/wsdl/ICmInch), затем из выпадающего списка у свойства Service выберите ICmInchService , а у Port — ICmInchPort (если выпадающие списки пустые, значит что-то не работает . ). После этого в обработчиках кнопок OnClick напишите:

Sender: var 

 Cm: Double; 

 begin 

 Cm := = FloatToStr((HTTPRIO1 as end; 

 procedure TForm1.btnInch2CmClick(Sender: TObject); 

  Inch: Double; 

 begin 

 Inch := = FloatToStr((HTTPRIO1 as end;

Теперь после компиляции и запуска приложения можно преобразовывать сантиметры в дюймы и наоборот.

Q: А что делать, если SOAP сервер написан кем-то другим и у нас нет интерфейсного модуля?
A: Тогда надо воспользоваться Web Service Importer , который находится в меню File | New | Other . , на закладке WebServices . Этот мастер сгенерирует интерфейсный модуль по WSDL сервиса.

Передача сложных типов

Наш компонент THTTPSOAPPascalInvoker уже знает как пересылать скалярные типы и динамические массивы (последние надо предварительно зарегистрировать в InvokeRegistry , см. ниже), однако для пересылки сложных типов, таких как static array , interface , record , set или class , необходимо сначала описать их как потомков класса TRemotable , обладающего RunTime Type Information (RTTI). Например, если мы хотим объявить класс, возвращающий курс валюты и ее наименование, то наш интерфейсный модуль будет выглядеть так:

unit  interface 

 uses 

 type 

 TCurrency = private 

 FExchangeRate: double; 

 FName: string; 

 public 

 property read FExchangeRate write property Name: string read write FName; 

 end; 

 TCurrencyArray = array of 

 implementation 

 initialization 

   end. 

Здесь мы дополнительно объявили динамический массив TCurrencyArray , на случай если захотим его передавать (обратите внимание на различие в командах регистрации класса и массива).
На самом деле полный синтаксис команды регистрации класса несколько шире, желающие могут прочитать о нем в документации к Delphi :

RemClassRegistry.RegisterXSClass(TXSDateTime, dateTime', True); 

Замечание: если имеется тип, который в WSDL документе является скалярным, но не имеет прямого соответствия в Object Pascal (например, DateTime ) то в качестве базового класса следует использовать TRemotableXS , который объявляет два метода XSToNative и NativeToXS для преобразования строкового представления в Object Pascal и обратно (эти методы надо, естественно, реализовать).
В составе Delphi поставляется модуль XSBuiltIns , в котором уже реализовано много полезных функций (однако в версии 6.0 там были ошибки в обработке даты, если национальные настройки в системе были не английские).

Возникает интересный вопрос с созданием-уничтожением объектов, передаваемых в качестве параметров. Вот что об этом говорится в документации к TRemotable :
«Со стороны сервера потомки TRemotable , являющиеся входными параметрами, автоматически создаются при распаковке ( unmarshal ) вызова метода, и автоматически уничтожаются после упаковки ( marshal ) выходных параметров для передачи клиенту.
Потомки TRemotable , созданные внутри метода, вызванного через invokable interface , автоматически уничтожаются после того как их значение упаковано ( marshal ) для передачи клиенту.
Клиент, вызывающий invokable interface , отвечает за создание объектов, используемых как входные параметры и за уничтожение всех потомков TRemotable , которые он создал, а также полученных в результате вызова метода .»

Передача Dataset-а

Здесь все совсем просто. Находясь в проекте Soap Server Application , выберите в меню File | New | Other . , перейдите на закладку WebServices и выберите Soap Server Data Module . Дальнейшее не отличается от разработки обычного MIDAS приложения, с двумя особенностями: сервер обязан быть stateless — получил запрос, ответил и забыл (например, CGI модуль в буквальном смысле завершается после каждого вызова), и иметь не более одного SoapDataModule .
Поместите на полученный модуль компоненты доступа к данным (например, TClientDataset ), установите у них все необходимые для работы свойства. Поместите TDataSetProvider , соедините его с компонентом доступа к данным.

Скомпиллируйте приложение и положите его туда, где оно может быть запущено Web-сервером (почему-то мне не удалось запустить его под WebAppDebugger , вероятно я использовал не тот WebModule , см. замечание выше).

В клиентском приложении поместите на форму TSoapConnection и TClientDataset , в SoapConnection.URL укажите путь к интерфейсу вашего сервера:

http://localhost/cgi-bin/CGIProject1.exe/soap/ISOAPDataMod42

можно использовать конкретный интерфейс SoapDataModule , а можно и более общий — IAppServer . В TClientDataset.RemoteServer укажите на TSoapConnection . Теперь, поставив TClientDataset.Active:=true , получим наши данные на клиента.

Если для отрытия датасета на сервере ему требуются какие-то параметры, то удобно будет вместо установки Active:=true использовать запрос DataRequest (напомню, что для SOAP приложений все параметры должны передаваться в составе единого запроса, т.е. нельзя сначала установить параметры, а потом запросить данные, т.к. с большой вероятностью второй запрос уйдет к другому экземпляру сервера). Это выглядит так .
На клиенте :

 procedure TForm1.Button1Click(Sender: TObject); 

 begin 

 Screen.Cursor:= try 

 = BiolifeCDS.DataRequest( finally 

 Screen.Cursor:= end; 

 end; 

 function TSOAPDataMod42.dspBiolifeDataRequest(Sender: TObject; 

 Input: OleVariant): begin 

 with (Sender as do 

 begin 

 Query1.ParamByName('Num'). Query1.Open; 

 Result := Data; 

 end; 

end;

т.е. серверу можно передать любые данные (передаваемый тип — OleVariant ) и получить назад данные опять же любого типа, например datapacket , как в приведенном случае.

Если вы изменили данные на клиенте и хотите их сохранить на сервер, то есть несколько способов это сделать. Самый простой — установить TDataSetProvider.ResolveToDataSet:=false и вызвать у TClientDataset метод ApplyUpdates . Запросы обновления пусть формирует сам TDataSetProvider , а контроль (довольно слабый, однако) за формированием этих запросов можно осуществлять с помощью свойств TField.ProviderFlags .

Другой способ: установить TDataSetProvider.ResolveToDataSet:=true , однако в этом случае в событии TDataSetProvider.OnBeforeApplyUpdates придется открыть связанный датасет , так чтобы в него была загружена та запись, которую собираетесь изменять. Зато теперь можно задействовать методы датасета BeforeInsert-BeforePost .

И последний вариант: воспользоваться своим собственным методом, добавленным к интерфейсу, как это ранее было проделано с Cm2Inch, и передавать ему ClientDataset.Delta , или набор инструкций для обновления, или то что подсказывает Ваша фантазия разработчика. Например :

 procedure TForm1.SendButtonClick(Sender: TObject); 

  X: ISOAPDataMod42; 

 begin 

 Screen.Cursor:= try 

 X:=httprio1 as ISOAPDataMod42; 

 cdsErrors.Data:= if and (cdsErrors.RecordCount>0) 

 then raise !') 

 else finally 

 Screen.Cursor:= end; 

 end; 

 function TSOAPDataMod42.SaveChanges(Input: OleVariant):  ErrorCount: integer; 

 begin 

 cdsTmp.Data:=Input; 

//. здесь какая-нибудь предобработка полученных данных .

cdsTmp.Data:= if then //. и тут можно что-то сделать, например Rollback транзакции

end; 

 Result := end; 

что заставит ваш модуль использовать именно русскую кодировку по умолчанию.