веб сервис что это такое простыми словами
Что такое веб-сервис
7 ноября 2017 Опубликовано в разделах: Азбука терминов. 60310
Например, есть авиакомпания. У нее много рейсов, соответственно, много билетов. Информацию через веб-службу она передает сайту-агрегатору тур-путешествий. Пользователь, который заходит на агрегатор, сможет прямо там купить билеты этой авиакомпании.
Другой пример веб-сервисов — это сайт отслеживания погоды, который содержит сведения о метеоусловиях в конкретном городе или по стране в целом. Данная информация также часто используется сторонними приложениями.
Информация в интернете разнородна. Сайты управляются разными системами. используются разные протоколы передачи и шифрования. Веб-сервисы упрощают обмен информацией между разными площадками.
Архитектура и протоколы Web-сервисов
Можно определить 3 инстанции, которые взаимодействуют между собой: каталог, исполнитель и заказчик. После создания сервиса, исполнитель регистрирует его в каталоге, а там сервис находит заказчик.
Механизм обмена данными формируется в описании Web Services Description. Это спецификация, охватывающая форматы пересылки, типы контента, транспортные протоколы, которые применяются в процессе обмена сведениями между заказчиком и транспортировщиком услуг.
Сегодня чаще всего используются несколько технологий для реализации различных веб-сервисов:
Универсальность представленных технологий – основа для понимания веб служб. Они работают на стандартных технологиях, не зависящих от поставщиков приложений и прочих ресурсов сети. Могут использоваться в любых операционных системах, серверах приложений, языков программирования и т.д.
Преимущества
Недостатки
Задачи веб-сервисов
Веб-сервисы могут использоваться во многих сферах.
B2B-транзакции
Интеграция процессов идет сразу, без участия людей. Например, пополнение каталога интернет-магазина новыми товарами. Их привозят на склад, и кладовщик отмечает в базе данных приход. Автоматически информация передается в интернет-магазин. И покупатель вместо пометки “Нет на складе” на карточке товара видит его количество.
Интеграция сервисов предприятий
Если в компании используются корпоративные программы, то веб-сервис поможет настроить их совместную работу.
Создание системы клиент-сервер
Сервисы используются, чтобы настроить работу клиента и сервера. Это дает преимущества:
Веб-сервис — это приложение, которое упрощает техническую настройку взаимодействия ресурсов.
Веб-сервисы в теории и на практике для начинающих
Что такое веб-сервисы?
Прежде всего, веб-сервисы (или веб-службы) — это технология. И как и любая другая технология, они имеют довольно четко очерченную среду применения.
Если посмотреть на веб-сервисы в разрезе стека сетевых протококолов, мы увидим, что это, в классическом случае, не что иное, как еще одна надстройка поверх протокола HTTP.
С другой стороны, если гипотетически разделить Интернет на несколько слоев, мы сможем выделить, как минимум, два концептуальных типа приложений — вычислительные узлы, которые реализуют нетривиальные функции и прикладные веб-ресурсы. При этом вторые, зачастую заинтересованы в услугах первых.
Но и сам Интернет — разнороден, т. е. различные приложения на различных узлах сети функционируют на разных аппаратно-программных платформах, и используют различные технологии и языки.
Чтобы связать все это и предоставить возможность одним приложениям обмениваться данными с другими, и были придуманы веб-сервисы.
По сути, веб-сервисы — это реализация абсолютно четких интерфейсов обмена данными между различными приложениями, которые написаны не только на разных языках, но и распределены на разных узлах сети.
Именно с появлением веб-сервисов развилась идея SOA — сервис-ориентированной архитектуры веб-приложений (Service Oriented Architecture).
Протоколы веб-сервисов
На сегодняшний день наибольшее распространение получили следующие протоколы реализации веб-сервисов:
На самом деле, SOAP произошел от XML-RPC и является следующей ступенью его развития. В то время как REST — это концепция, в основе которой лежит скорее архитектурный стиль, нежели новая технология, основанный на теории манипуляции объектами CRUD (Create Read Update Delete) в контексте концепций WWW.
Безусловно, существуют и иные протоколы, но, поскольку они не получили широкого распространения, мы остановимся в этом кратком обзоре на двух основных — SOAP и REST. XML-RPC ввиду того, что является несколько «устаревшим», мы рассматривать подробно не будем.
Нас в первую очередь интересуют вопросы создания новых веб-служб, а не реализация клиентов к существующим (как правило поставщики веб-сервисов поставляют пакеты с функциями API и документацией, посему вопрос построения клиентов к существующим веб-службам менее интересен с точки зрения автора).
SOAP против REST
Проблемы данного противостояния хорошо описаны в статье Леонида Черняка, найденой на портале www.citforum.ru.
По мнению же автора, кратко можно выделить следующее:
SOAP более применим в сложных архитектурах, где взаимодействие с объектами выходит за рамки теории CRUD, а вот в тех приложениях, которые не покидают рамки данной теории, вполне применимым может оказаться именно REST ввиду своей простоты и прозрачности. Действительно, если любым объектам вашего сервиса не нужны более сложные взаимоотношения, кроме: «Создать», «Прочитать», «Изменить», «Удалить» (как правило — в 99% случаев этого достаточно), возможно, именно REST станет правильным выбором. Кроме того, REST по сравнению с SOAP, может оказаться и более производительным, так как не требует затрат на разбор сложных XML команд на сервере (выполняются обычные HTTP запросы — PUT, GET, POST, DELETE). Хотя SOAP, в свою очередь, более надежен и безопасен.
В любом случае вам решать, что больше подойдет вашему приложению. Вполне вероятно, вы даже захотите реализовать оба протокола, чтобы оставить выбор за пользователями службы и — это ваше право.
Практическое применение веб-сервисов
Поскольку речь идет о практическом применении, нам нужно выбрать платформу для построения веб-службы и поставить задачу. Так как автору ближе всего PHP 5, мы и выберем его в качестве технологии для построения службы, а в качестве задачи примем следующие требования.
Допустим, нам необходимо создать службу, предоставляющую доступ к информации о курсах валют, которая собирается нашим приложением, и накапливается в базе данных. Далее посредством веб-сервиса, данная информация передается сторонним приложениям для отображения в удобном для них виде.
Как видим задача довольно проста и, с точки зрения самой службы, ограничивается лишь чтением информации, но в практических целях нам этого будет достаточно.
Этап первый — реализация приложения сбора информации о курсах валют.
Информацию о курсах валют мы будем собирать со страниц сайта НБУ (Национального Банка Украины) ежедневно и складывать в базу данных под управлением СУБД MySQL.
Создадим структуру данных.
Таблица валют (currency):
Таблица номиналов обмена (exchange):
Для работы с базой данных воспользуемся ORM слоем на базе пакета PHP Doctrine. Реализуем граббер:
класс Grubber (models/Grabber.php):
и сам граббер (grabber.php):
Теперь заставим наш граббер отрабатывать раз в сутки в 10:00 утра, путем добавления команды запуска граббера в таблицы cron:
Все — у нас есть достаточно полезный сервис.
Теперь реализуем веб-сервис, который позволит другим приложениям извлекать данные из нашей базы.
Реализация SOAP сервиса
Для реализации веб-сервиса на базе SOAP протокола, мы воспользуемся встроенным пакетом в PHP для работы с SOAP.
Поскольку наш веб-сервис будет публичным, хорошим вариантом будет создание WSDL файла, который описывает структуру нашего веб-сервиса.
WSDL (Web Service Definition Language) — представляет из себя XML файл определенного формата. Подробное описание синтаксиса можно найти здесь.
На практике будет удобно воспользоваться функцией автоматической генерации файла, которую предоставляет IDE Zend Studio for Eclipse. Данная функция позволяет генерировать WSDL файл из классов PHP. Поэтому, прежде всего, мы должны написать класс, реализующий функциональность нашего сервиса.
класс CurrencyExchange (models/CurrencyExchange.php):
Отметим, что для автоматической генерации WSDL, нам необходимо написать комментарии в стиле javadoc, потому что именно в них мы прописываем информацию о типах принимаемых аргументов и возвращаемых значений. Неплохо также описывать в нескольких словах работу методов — ведь WSDL послужит описанием API для сторонних разработчиков, которые будут использовать ваш веб-сервис.
Не пишите в докблоках param void или return void — для WSDL это не критично, но вот при реализации REST доступа к тому-же классу у вас возникнут проблемы.
Теперь в Zend Studio входим в меню File->Export. выбираем PHP->WSDL, добавляем наш класс, прописываем URI-адрес нашего сервиса и создаем WSDL-файл. Результат должен быть примерно таким: http://mikhailstadnik.com/ctws/currency.wsdl
Если вы будете добавлять новую функциональность в ваш веб-сервис, вам нужно будет пересоздавать WSDL-файл. Но здесь не так все гладко. Следует учитывать, что SOAP-клиент, который уже запрашивал ваш WSDL файл, кеширует его на своей стороне. Поэтому, если вы замените старое содержимое новым в WSDL файле, некторые клиенты его не прочтут. А значит, при добавлении новой функциональности, дописывайте версию в имя вашего файла. И не забудбте обеспечить обратную совместимость для старых клиентов, особенно если вы не являетесь их поставщиком.
С другой стороны, WSDL довольно жестко задает структуру веб-сервиса, а это значит, что, если существует необходимость ограничить функциональность клиента по сравнению с сервером, вы можете не включать определенные методы ваших классов в WSDL. Таким образом они не смогут быть вызваны, несмотря на то, что существуют.
Реализация же самого сервера не предстваляет теперь никакой сложности:
Вы можете попробовать веб-сервис в работе по адресу: http://mikhailstadnik.com/ctws/
Там же доступен тестовый клиент: http://mikhailstadnik.com/ctws/client.php
Код простейшего клиента может быть таким:
Реализация REST сервиса
REST — это не стандарт и не спецификация, а архитектурный стиль, выстроенный на существующих, хорошо известных и контролируемых консорциумом W3C стандартах, таких, как HTTP, URI (Uniform Resource Identifier), XML и RDF (Resource Description Format). В REST-сервисах акцент сделан на доступ к ресурсам, а не на исполнение удаленных сервисов; в этом их кардинальное отличие от SOAP-сервисов.
И все же удаленный вызов процедур применим и в REST. Он использует методы PUT, GET, POST, DELETE HTTP протокола для манипуляции объектами. Кардинальное отличие его от SOAP в том, что REST остается HTTP-запросом.
Поскольку в PHP пока еще нет реалзации REST, мы воспользуемся Zend Framwork, в который включена реализация как REST клиента, так и REST севера.
Воспользуемся уже готовым классом CurrencyExchange. Напишем сам сервер:
Как видите все очень сходно и просто.
Однако, следует оговорить, что наш REST-сервис менее защищен, чем SOAP-сервис, так как любой добавленый метод в класс CurrencyExchange при его вызове отработает (сам класс определяет сруктуру сервиса).
Проверим работу нашего сервиса. Для этого достаточно передать параметры вызова метода в сроке GET-запроса:
При желании или необходимости вы можете самомтоятельно задавать структуру ваших XML ответов для сервиса REST. В этом случае, также будет необходимо позаботиться и о создании определения типа вашего XML документа (DTD — Document Type Definition). Это будет минимальным описанием API вашего сервиса.
Простейший тестовый клиент к REST сервису может быть в нашем случае таким:
В принципе, Zend_Rest на сегодняшний день нельзя назвать наиболее точной реализацией принципов REST. Утрируя, можно говорить о том, что эта реализация свелась к удаленному вызову процедур (RPC), хотя философия REST гораздо шире.
Вы можете скачать пример в исходных кодах c PHP Doctrine и Zend Framework (4,42 Мб).
Заключение
Мы выполнили задачу минимум и показали, что такое веб-сервисы, для чего они нужны и как их реализовывать. Естественно, приведенный пример, возможно, несколько оторван от жизни, но он был выбран лишь в качестве инструмента для объяснения предмета и сущности веб-сервисов.
Кроме того мы увидели, что реализация веб-сервиса — задача довольно простая при использовании современного инструментария, который позволяет сконцентрироваться, в первую очередь, на разработке функциональности самого сервиса, не заботясь о низкоуровневой реализации протоколов.
Автор надеется, что данный материал будет действительно полезен тем, кто становится на тропу разработки веб-служб.
1) Введение в WebService
Что такое веб-сервис?
Веб-сервисы — это механизм или средство связи, посредством которого два приложения / машины будут обмениваться данными независимо от их архитектуры подчеркивания и технологии.
Что такое тестирование веб-службы?
Тестирование веб-сервисов — это тип тестирования программного обеспечения, который проверяет веб-сервисы. Целью тестирования веб-служб является проверка функциональности, надежности, производительности и безопасности API (интерфейса прикладных программ). Тестирование веб-службы в некоторых случаях аналогично тестированию модулей. Вы можете протестировать Web-сервис вручную или создать свой собственный код автоматизации или использовать готовый инструмент автоматизации, такой как Postman.
Зачем нужен веб-сервис?
В общем, программные приложения разрабатываются для использования людьми, когда человек отправляет запрос в службу программного обеспечения, которая, в свою очередь, возвращает ответ в удобочитаемом для человека формате.
В современную технологическую эпоху, если вы хотите создать программное приложение, вам не нужно создавать все с нуля. Существует множество готовых сервисов, которые вы можете подключить к своему приложению, и вы можете начать предоставлять эти сервисы в своем приложении.
Например, вы хотите отображать информацию о прогнозе погоды, которая вам не нужна для сбора, обработки и отображения данных в вашем приложении. Вы можете купить услуги у людей, которые уже хорошо зарекомендовали себя в обработке и публикации такого рода данных.
Веб-сервисы позволяют нам делать такие реализации.
В качестве примера рассмотрим следующий WebService
Это дает стоимость акций для компании.
Давайте найдем цену акции для Google (Символ: GOOG)
XML ответа дает цену акции.
Этот веб-сервис может вызываться программным приложением с использованием протокола SOAP или HTTP.
Протоколы веб-сервисов
Веб-сервисы могут быть реализованы различными способами, но следующие два являются популярными подходами к реализации.
SOAP — это стандартный протокол, определенный стандартом W3C для отправки и получения запросов и ответов веб-служб.
SOAP использует формат XML для отправки и получения запроса и, следовательно, данные являются независимыми от платформы данными. Сообщения SOAP обмениваются между приложениями поставщика и принимающим приложением в конвертах SOAP.
Поскольку SOAP использует простой транспортный протокол http, его сообщения не блокируются брандмауэрами.
ОСТАТОК
REST означает REpresentational State Transfer; это архитектура, которая обычно работает через HTTP. Стиль REST подчеркивает взаимодействия между клиентами и сервисами, которые улучшаются благодаря ограниченному количеству операций. REST является альтернативой SOAP (Simple Object Access Protocol), и вместо использования XML для запроса REST в некоторых случаях использует простой URL. В отличие от SOAP, приложения RESTFUL используют HTTP-заголовки для переноса метаинформации.
Rest API поддерживает формат XML и JSON. Как правило, он предпочтителен для мобильных и веб-приложений, поскольку он делает работу приложений более быстрой и плавной.
WSDL (язык описания веб-сервисов) — это язык на основе XML, который будет использоваться для описания сервисов, предлагаемых веб-сервисом.
WSDL описывает все операции, предлагаемые конкретным веб-сервисом в формате XML. Он также определяет, как могут быть вызваны сервисы, то есть какое входное значение мы должны предоставить и какой будет формат ответа, который он будет генерировать для каждого вида сервиса.
Как проверить веб-сервис?
Для тестирования веб-сервиса вы можете
Тестирование WebService включает в себя следующие шаги:
Предположим, мы хотим протестировать веб-сервис, который предоставляет средство конвертации валют. Это будут текущие курсы обмена между валютами разных стран. Этот сервис мы можем использовать в наших приложениях для преобразования значений из одной валюты в другую валюту.
Теперь давайте посмотрим на шаги выше
Шаг с 1 по 4: Понимание WSDL и определение операций и форматов XML
Файл WSDL Currency Convertor можно увидеть @ ( http://www.webservicex.net/CurrencyConvertor.asmx?wsdl ), который предоставит информацию о методах веб-службы Currency Convertor, которые он будет поддерживать, параметр, который нам нужно передать, и тип параметров… и т. д.
Шаг 5: Использование инструмента или написание кода для отправки запроса и проверки ответа
Для тестирования веб-сервисов доступно множество инструментов. SoapUI — один из популярных инструментов, который поможет нам протестировать веб-сервисы. Фактически вы можете использовать любой язык программирования, который способен отправлять XML-запрос приложению поставщика веб-услуг через http и может анализировать и проверять XML-ответ в соответствии с ожидаемым результатом. В нашем случае мы будем тестировать WebService
ЧАСТЬ 1) Тестирование WebService с использованием Apache Axis2 API (Java).
Обычно веб-служба принимает запрос и отправляет ответ в формате XML.
Axis2 может отправлять сообщения SOAP и получать и обрабатывать сообщения SOAP. Мы можем написать небольшую Java-программу, используя API для создания веб-сервиса. Axis2 сгенерирует WSDL из Java-программы, которая будет использоваться для передачи сервисов, предлагаемых веб-сервисом. Мы можем использовать тот же Axis2 для генерации Java-класса (заглушки) из файла WSDL, который мы можем использовать в качестве клиентской программы для генерации запроса веб-сервиса, отправки запроса конечной точке сервиса и обработки ответа.
Давайте посмотрим на шаги выше в деталях
Шаг а) Загрузите API-интерфейс axis2 @ https://axis.apache.org/axis2/Java/core/download.cgi и установите переменную среды AXIS2_HOME.
Шаг б) Создайте папку для хранения всех сгенерированных артефактов
Пример: C: \ Axis \ Projects \ CurrencyConverter
Шаг c) Откройте командную строку и перейдите к структуре папок, в которой вы хотите создать артефакты, и выполните следующую команду, которая сгенерирует заглушки
Шаг d) После успешного выполнения команды вы увидите папку с необходимыми файлами.
Шаг д) Далее мы должны создать клиентскую программу, с помощью которой мы будем отправлять фактический запрос, используя сгенерированные заглушки. Откройте затмение и создайте новый проект Java и выберите папку, которую мы создали выше.
Шаг f) Добавьте все файлы jar, связанные с axis2, в путь сборки проекта, который будет находиться в папке lib в папке программного обеспечения axis2
(например: C: \ Axis \ axis2-1.6.2 \ lib)
Шаг g) Создайте новый класс Java (например: Client.Java) и создайте экземпляр объекта-заглушки. Используя объект-заглушку, мы можем вызвать все поддерживаемые методы конкретного WebService.
ЧАСТЬ 2) Использование SoapUI для тестирования WebService
Как вы можете заключить, использование таких инструментов, как SoapUI, ускоряет ваши усилия по тестированию WebService. Поэтому SoapUi будет центром нашего обучения в последующих уроках.
Резюме
Часто задаваемые вопросы
В чем разница между WebService и WebAPI?
Веб-сервис
Веб-API
Это руководство стало возможным благодаря участию г-на Нарендера Редди Нукала
Веб-сервисы — Краткое руководство
Различные книги и разные организации предоставляют разные определения для веб-сервисов. Некоторые из них перечислены здесь.
Веб-сервис — это любое программное обеспечение, которое доступно через Интернет и использует стандартизированную систему обмена сообщениями XML. XML используется для кодирования всех сообщений в веб-сервис. Например, клиент вызывает веб-службу, отправляя сообщение XML, а затем ожидает соответствующего ответа XML. Поскольку вся связь осуществляется в XML, веб-сервисы не привязаны к какой-либо одной операционной системе или языку программирования — Java может общаться с Perl; Приложения Windows могут общаться с приложениями Unix.
Веб-службы — это автономные, модульные, распределенные, динамические приложения, которые можно описывать, публиковать, размещать или вызывать по сети для создания продуктов, процессов и цепочек поставок. Эти приложения могут быть локальными, распределенными или сетевыми. Веб-сервисы построены на основе открытых стандартов, таких как TCP / IP, HTTP, Java, HTML и XML.
Веб-сервисы — это системы обмена информацией на основе XML, которые используют Интернет для прямого взаимодействия между приложениями. Эти системы могут включать программы, объекты, сообщения или документы.
Веб-сервис — это набор открытых протоколов и стандартов, используемых для обмена данными между приложениями или системами. Программные приложения, написанные на разных языках программирования и работающие на разных платформах, могут использовать веб-сервисы для обмена данными по компьютерным сетям, таким как Интернет, аналогично межпроцессному взаимодействию на одном компьютере. Эта совместимость (например, между приложениями Java и Python или Windows и Linux) обусловлена использованием открытых стандартов.
Веб-сервис — это любое программное обеспечение, которое доступно через Интернет и использует стандартизированную систему обмена сообщениями XML. XML используется для кодирования всех сообщений в веб-сервис. Например, клиент вызывает веб-службу, отправляя сообщение XML, а затем ожидает соответствующего ответа XML. Поскольку вся связь осуществляется в XML, веб-сервисы не привязаны к какой-либо одной операционной системе или языку программирования — Java может общаться с Perl; Приложения Windows могут общаться с приложениями Unix.
Веб-службы — это автономные, модульные, распределенные, динамические приложения, которые можно описывать, публиковать, размещать или вызывать по сети для создания продуктов, процессов и цепочек поставок. Эти приложения могут быть локальными, распределенными или сетевыми. Веб-сервисы построены на основе открытых стандартов, таких как TCP / IP, HTTP, Java, HTML и XML.
Веб-сервисы — это системы обмена информацией на основе XML, которые используют Интернет для прямого взаимодействия между приложениями. Эти системы могут включать программы, объекты, сообщения или документы.
Веб-сервис — это набор открытых протоколов и стандартов, используемых для обмена данными между приложениями или системами. Программные приложения, написанные на разных языках программирования и работающие на разных платформах, могут использовать веб-сервисы для обмена данными по компьютерным сетям, таким как Интернет, аналогично межпроцессному взаимодействию на одном компьютере. Эта совместимость (например, между приложениями Java и Python или Windows и Linux) обусловлена использованием открытых стандартов.
Таким образом, полный веб-сервис — это любой сервис, который —
Доступен через Интернет или частные (интранет) сети
Использует стандартизированную систему обмена сообщениями XML
Не привязан ни к одной операционной системе или языку программирования
Это самоописание через общую грамматику XML
Обнаруживается с помощью простого механизма поиска
Доступен через Интернет или частные (интранет) сети
Использует стандартизированную систему обмена сообщениями XML
Не привязан ни к одной операционной системе или языку программирования
Это самоописание через общую грамматику XML
Обнаруживается с помощью простого механизма поиска
Компоненты веб-сервисов
Базовая платформа веб-сервисов — это XML + HTTP. Все стандартные веб-сервисы работают с использованием следующих компонентов:
SOAP (простой протокол доступа к объектам)
UDDI (универсальное описание, обнаружение и интеграция)
WSDL (язык описания веб-сервисов)
SOAP (простой протокол доступа к объектам)
UDDI (универсальное описание, обнаружение и интеграция)
WSDL (язык описания веб-сервисов)
Как работает веб-сервис?
Веб-сервис обеспечивает связь между различными приложениями с использованием открытых стандартов, таких как HTML, XML, WSDL и SOAP. Веб-сервис принимает помощь —
XML для пометки данных
SOAP для передачи сообщения
WSDL для описания доступности сервиса.
XML для пометки данных
SOAP для передачи сообщения
WSDL для описания доступности сервиса.
На Solaris можно создать веб-службу на основе Java, доступную из вашей программы Visual Basic, которая работает в Windows.
Вы также можете использовать C # для создания новых веб-служб в Windows, которые могут быть вызваны из вашего веб-приложения, основанного на JavaServer Pages (JSP) и работающего в Linux.
пример
Рассмотрим простую систему управления счетами и обработки заказов. Сотрудники бухгалтерии используют клиентское приложение, созданное с помощью Visual Basic или JSP, для создания новых учетных записей и ввода новых заказов клиентов.
Логика обработки для этой системы написана на Java и находится на компьютере Solaris, который также взаимодействует с базой данных для хранения информации.
Шаги для выполнения этой операции следующие:
Клиентская программа связывает информацию о регистрации учетной записи в сообщение SOAP.
Это SOAP-сообщение отправляется веб-службе как тело HTTP-запроса POST.
Веб-служба распаковывает запрос SOAP и преобразует его в команду, понятную приложению.
Приложение обрабатывает информацию по мере необходимости и отвечает новым уникальным номером учетной записи для этого клиента.
Затем веб-служба упаковывает ответ в другое сообщение SOAP, которое отправляет обратно клиентской программе в ответ на свой HTTP-запрос.
Клиентская программа распаковывает сообщение SOAP, чтобы получить результаты процесса регистрации учетной записи.
Клиентская программа связывает информацию о регистрации учетной записи в сообщение SOAP.
Это SOAP-сообщение отправляется веб-службе как тело HTTP-запроса POST.
Веб-служба распаковывает запрос SOAP и преобразует его в команду, понятную приложению.
Приложение обрабатывает информацию по мере необходимости и отвечает новым уникальным номером учетной записи для этого клиента.
Затем веб-служба упаковывает ответ в другое сообщение SOAP, которое отправляет обратно клиентской программе в ответ на свой HTTP-запрос.
Клиентская программа распаковывает сообщение SOAP, чтобы получить результаты процесса регистрации учетной записи.
Почему веб-сервисы?
Вот преимущества использования веб-сервисов —
Разоблачение существующей функции в сети
Веб-сервис — это блок управляемого кода, который можно вызывать удаленно с помощью HTTP. То есть его можно активировать с помощью HTTP-запросов. Веб-сервисы позволяют вам раскрыть функциональность существующего кода через сеть. После того, как он выставлен в сети, другие приложения могут использовать функциональные возможности вашей программы.
Interoperability
Стандартизированный протокол
Веб-сервисы используют стандартизированный протокол промышленного стандарта для связи. Все четыре уровня (уровни Service Transport, XML Messaging, Service Description и Service Discovery) используют четко определенные протоколы в стеке протоколов веб-служб. Эта стандартизация стека протоколов дает бизнесу множество преимуществ, таких как широкий выбор, снижение стоимости из-за конкуренции и повышение качества.
Низкая стоимость связи
Веб-сервисы используют протокол SOAP поверх HTTP, поэтому вы можете использовать существующий недорогой интернет для реализации веб-сервисов. Это решение намного дешевле по сравнению с запатентованными решениями, такими как EDI / B2B. Помимо SOAP через HTTP, веб-службы также могут быть реализованы на других надежных транспортных механизмах, таких как FTP.
Веб-сервисы — Характеристики
Веб-сервисы имеют следующие специальные поведенческие характеристики —
XML-Based
Веб-сервисы используют XML на уровнях представления данных и передачи данных. Использование XML устраняет любые сетевые, операционные системы или привязки платформы. Приложения на основе веб-служб обладают высокой функциональной совместимостью на уровне ядра.
Слабо связанный
Потребитель веб-сервиса не привязан к этому веб-сервису напрямую. Интерфейс веб-службы может меняться со временем, не ставя под угрозу способность клиента взаимодействовать со службой. Тесно связанная система подразумевает, что клиентская и серверная логика тесно связаны друг с другом, подразумевая, что если один интерфейс изменяется, другой должен быть обновлен. Использование слабосвязанной архитектуры делает программные системы более управляемыми и упрощает интеграцию между различными системами.
Крупнозернистый
Объектно-ориентированные технологии, такие как Java, предоставляют свои услуги с помощью отдельных методов. Отдельный метод — это слишком хорошая операция, чтобы предоставить какие-либо полезные возможности на корпоративном уровне. Создание Java-программы с нуля требует создания нескольких детализированных методов, которые затем объединяются в грубый сервис, который используется клиентом или другим сервисом.
Предприятия и интерфейсы, которые они выставляют, должны быть крупнозернистыми. Технология веб-сервисов обеспечивает естественный способ определения грубых сервисов, которые получают необходимый объем бизнес-логики.
Способность быть синхронной или асинхронной
Синхронность относится к привязке клиента к выполнению услуги. При синхронных вызовах клиент блокирует и ждет, пока служба завершит свою работу, прежде чем продолжить. Асинхронные операции позволяют клиенту вызывать службу и затем выполнять другие функции.
Асинхронные клиенты получают свой результат в более поздний момент времени, в то время как синхронные клиенты получают свой результат после завершения службы. Асинхронные возможности являются ключевым фактором в создании слабосвязанных систем.
Поддерживает удаленные вызовы процедур (RPC)
Веб-службы позволяют клиентам вызывать процедуры, функции и методы на удаленных объектах с использованием протокола на основе XML. Удаленные процедуры предоставляют входные и выходные параметры, которые должен поддерживать веб-сервис.
Поддерживает обмен документами
Одним из ключевых преимуществ XML является его общий способ представления не только данных, но и сложных документов. Эти документы могут быть такими же простыми, как представление текущего адреса, или такими же сложными, как и представление всей книги или запроса предложения (RFQ). Веб-сервисы поддерживают прозрачный обмен документами для облегчения интеграции бизнеса.
Веб-сервисы — Архитектура
Существует два способа просмотра архитектуры веб-службы:
Роли веб-сервисов
В архитектуре веб-службы есть три основные роли:
Поставщик услуг
Это поставщик веб-службы. Поставщик услуг реализует услугу и делает ее доступной в Интернете.
Запрос на обслуживание
Это любой потребитель веб-сервиса. Запрашивающая сторона использует существующую веб-службу, открывая сетевое соединение и отправляя запрос XML.
Сервисный реестр
Это логически централизованный каталог услуг. Реестр предоставляет центральное место, где разработчики могут публиковать новые сервисы или находить существующие. Поэтому он служит централизованным расчетным центром для компаний и их услуг.
Стек протоколов веб-служб
Второй вариант для просмотра архитектуры веб-службы — это проверка появляющегося стека протоколов веб-службы. Стек все еще развивается, но в настоящее время имеет четыре основных слоя.
Сервисный транспорт
Этот уровень отвечает за передачу сообщений между приложениями. В настоящее время этот уровень включает гипертекстовый транспортный протокол (HTTP), простой протокол передачи почты (SMTP), протокол передачи файлов (FTP) и более новые протоколы, такие как Blocks Extensible Exchange Protocol (BEEP).
Обмен сообщениями XML
Этот уровень отвечает за кодирование сообщений в общем формате XML, чтобы сообщения могли быть поняты с любого конца. В настоящее время этот уровень включает в себя XML-RPC и SOAP.
Описание услуг
Этот уровень отвечает за описание общедоступного интерфейса к определенному веб-сервису. В настоящее время описание службы обрабатывается с помощью языка описания веб-служб (WSDL).
Сервис Discovery
Этот уровень отвечает за централизацию сервисов в общем реестре и обеспечивает простую функциональность публикации / поиска. В настоящее время обнаружение служб обрабатывается с помощью универсального описания, обнаружения и интеграции (UDDI).
По мере развития веб-сервисов могут быть добавлены дополнительные уровни и дополнительные технологии могут быть добавлены к каждому уровню.
Следующая глава объясняет компоненты веб-сервисов.
Несколько слов о сервисном транспорте
Нижняя часть стека протоколов веб-службы — это транспортная служба. Этот уровень отвечает за фактическую передачу сообщений XML между двумя компьютерами.
Протокол передачи гипертекста (HTTP)
В настоящее время HTTP является наиболее популярным вариантом для транспорта службы. HTTP прост, стабилен и широко используется. Кроме того, большинство брандмауэров разрешают HTTP-трафик. Это позволяет сообщениям XMLRPC или SOAP маскироваться под сообщения HTTP. Это хорошо, если вы хотите интегрировать удаленные приложения, но это вызывает ряд проблем с безопасностью.
Блокирует расширяемый протокол обмена (BEEP)
Это многообещающая альтернатива HTTP. BEEP — это новая структура IETF для разработки новых протоколов. BEEP является многоуровневым протоколом TCP и включает в себя ряд встроенных функций, включая протокол первоначального рукопожатия, аутентификацию, безопасность и обработку ошибок. Используя BEEP, можно создавать новые протоколы для различных приложений, включая обмен мгновенными сообщениями, передачу файлов, распространение контента и управление сетью.
SOAP не привязан к какому-либо конкретному транспортному протоколу. Фактически, вы можете использовать SOAP через HTTP, SMTP или FTP. Поэтому одной из многообещающих идей является использование SOAP поверх BEEP.
Веб-сервисы — Компоненты
За последние несколько лет три основные технологии стали мировыми стандартами, составляющими основу современных технологий веб-сервисов. Эти технологии обсуждаются ниже.
XML-RPC
Это самый простой протокол на основе XML для обмена информацией между компьютерами.
XML-RPC — это простой протокол, который использует XML-сообщения для выполнения RPC.
Запросы кодируются в XML и отправляются через HTTP POST.
Ответы XML встраиваются в тело ответа HTTP.
XML-RPC не зависит от платформы.
XML-RPC позволяет различным приложениям общаться.
Java-клиент может передавать XML-RPC на сервер Perl.
XML-RPC — это самый простой способ начать работу с веб-сервисами.
XML-RPC — это простой протокол, который использует XML-сообщения для выполнения RPC.
Запросы кодируются в XML и отправляются через HTTP POST.
Ответы XML встраиваются в тело ответа HTTP.