Что такое веб сервис простыми словами

17.04.202224.04.2022 admin 0 Comments

Веб-сервисы — Краткое руководство

Различные книги и разные организации предоставляют разные определения для веб-сервисов. Некоторые из них перечислены здесь.

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

Почему веб-сервисы?

Вот преимущества использования веб-сервисов —

Разоблачение существующей функции в сети

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

Источник

Белый Виталий Владимирович

Факультет компьютерных наук и технологий

Кафедра прикладной математики и информатики

Специальность «Инженерия программного обеспечения»

Использование многоядерных процессоров для параллельного решения задачи Коши

Научный руководитель: к.т.н., доцент Назарова Ирина Акоповна

Ликбез по веб-сервисам

Что такое веб-сервисы?

Прежде всего, веб-сервисы (или веб-службы) — это технология. И как и любая другая технология, они имеют довольно четко очерченную среду применения.

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

Именно с появлением веб-сервисов развилась идея SOA — сервис-ориентированной архитектуры веб-приложений (Service Oriented Architecture).

Протоколы веб-сервисов

На сегодняшний день наибольшее распространение получили следующие протоколы реализации веб-сервисов:

На самом деле, SOAP произошел от XML-RPC и является следующей ступенью его развития. В то время как REST — это концепция, в основе которой лежит скорее архитектурный стиль, нежели новая технология, основанный на теории манипуляции объектами CRUD (Create Read Update Delete) в контексте концепций WWW.

Безусловно, существуют и иные протоколы, но, поскольку они не получили широкого распространения, мы остановимся в этом кратком обзоре на двух основных — SOAP и REST. XML-RPC ввиду того, что является несколько «устаревшим», мы рассматривать подробно не будем [1].

Классический подход (SOAP)

Веб-сервис идентифицируется строкой URI. Веб-сервис имеет программный интерфейс, представленный в машинно-обрабатываемом формате WSDL. Другие системы взаимодействуют с этим веб-сервисом путем обмена сообщениями протокола SOAP. В качестве транспорта для сообщений используется протокол HTTP. Описание веб-сервисов и их API могут быть найдены средствами UDDI. Концептуальная схема технологии приведена на рис. 1., а связь между протоколами — на рис. 2.

Рисунок 1 — Концепция веб-сервиса

Рисунок 2 — Протоколы веб-сервисов

Все спецификации, используемые в технологии, основаны на XML и, соответственно, наследуют его преимущества (структурированность, гибкость и т.д.) и недостатки (громоздкость, медлительность).

SOAP (изначально Simple Object Access Protocol, а в версии 1.2 официальная расшифровка аббревиатуры отсутствует) — простой протокол доступа к объектам (компонентам распределенной вычислительной системы), основанный на обмене структурированными сообщениями. Как любой текстовый протокол, SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTPS и др., но чаще всего SOAP используется поверх HTTP.

Все сообщения SOAP оформляются в виде структуры, называемой конвертом (envelop), включающей следующие элементы:

Пример сообщения SOAP:

1 2001-06-22T14:00:00-05:00 Get up at 6:30 AM

Язык описания веб-сервисов (Web services Description Language, WSDL) предназначен для унифицированного представления внешних интерфейсов веб-службы. Текущая версия протокола WSDL 2.0 и она имеет некоторые отличия от предыдущих версий.

Таблица 1. Основные элементы протокола WSDL.

Элемент WSDL 1.1	Элемент WSDL 2.0	Краткое описание
PortType	Interface	Представляет описание интерфейса веб-сервиса (список операций и их параметров).
Service	Service	Список системных функций
Binding	Binding	Специфицирует интерфейсы и задает параметры связывания с протоколом SOAP: стиль связывания (RPC/Document) и транспорт (SOAP). Эта секция доступна и для каждой из операций
Operation	Operation	Определяет операцию, представляемую веб-сервером. WSDL-операция — это аналог традиционным функциям и процедурам.
Message	не использ.	Сообщение, связанное с определенной операцией. Содержит информацию, необходимую для выполнения данной операции. Каждое сообщение может состоять из нескольких логических частей, описывающих типы данных и имена атрибутов. В версии 2.0 было исключено, т.к. была внедрена поддержка XML Schema для всех элементов.
Types	Types	Описание данных в соответствии с XML Schema.

Рисунок 3 — Структура протокола WSDL

В спецификации WSDL 1.1 было определено 4 шаблона обмена сообщениями (типы операций):

В версии WSDL 2.0 эти шаблоны изменены и расширены в сторону поддержки сообщений об ошибках (например, шаблон Robust-in-only), но для обратной совместимости поддерживаются типы WSDL 1.1.

Universal Description, Discovery and Integration (UDDI, универсальный интерфейс распознавания, описания и интеграции) — открытый стандарт, утвержденный OASIS, определяющий методы публикации и обнаружения сетевых программных компонентов сервис-ориентированной архитектуры (SOA). В практической реализации UDDI представляет собой сетевой реестр (службу каталогов), представляющий данные и метаданные о веб-сервисах.

UDDI опирается на отраслевые стандарты HTTP, XML, XML Schema (XSD), SOAP и WSDL. Концептуальная связь между UDDI и другими протоколами стека веб-сервисов показана на рис. 4.

Рисунок 4 — Место UDDI в стеке протоколов веб-служб

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

Ключевыми функциями UDDI являются публикация информации о службе в реестре и поиск этой информации сторонними приложениями. Наряду с этими, реализованы и типовые для службы каталогов функции: представление модели хранимых данных и структуры информационной базы, отношения между объектами реестра, репликация, обеспечение безопасности и т.д. Все основные функции реестра представлены в виде веб-сервисов и доступны через API UDDI [2].

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

REST (Representational state transfer) — это стиль архитектуры программного обеспечения для распределенных систем, таких как World Wide Web, который, как правило, используется для построения веб-служб. Термин REST был введен в 2000 году Роем Филдингом, одним из авторов HTTP-протокола. Системы, поддерживающие REST, называются RESTful-системами.

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

А теперь тоже самое более наглядно:

Отсутствие дополнительных внутренних прослоек означает передачу данных в том же виде, что и сами данные. Т.е. мы не заворачиваем данные в XML, как это делает SOAP и XML-RPC, не используем AMF, как это делает Flash и т.д. Просто отдаем сами данные.

Каждая единица информации однозначно определяется URL — это значит, что URL по сути является первичным ключом для единицы данных. Т.е. например третья книга с книжной полки будет иметь вид /book/3, а 35 страница в этой книге — /book/3/page/35. Отсюда и получается строго заданный формат. Причем совершенно не имеет значения, в каком формате находятся данные по адресу /book/3/page/35 — это может быть и HTML, и отсканированная копия в виде jpeg-файла, и документ Microsoft Word.

Как происходит управление информацией сервиса — это целиком и полностью основывается на протоколе передачи данных. Наиболее распространенный протокол конечно же HTTP. Так вот, для HTTP действие над данными задается с помощью методов: GET (получить), PUT (добавить, заменить), POST (добавить, изменить, удалить), DELETE (удалить). Таким образом, действия CRUD (Create-Read-Updtae-Delete) могут выполняться как со всеми 4-мя методами, так и только с помощью GET и POST.

Вот как это будет выглядеть на примере:

ВАЖНОЕ ДОПОЛНЕНИЕ: Существуют так называемые REST-Patterns, которые различаются связыванием HTTP-методов с тем, что они делают. В частности, разные паттерны по-разному рассматривают POST и PUT. Однако, PUT предназначен для создания, реплейса или апдейта, для POST это не определено (The POST operation is very generic and no specific meaning can be attached to it). Поэтому данный пример будет правильным и в таком виде, и в виде если поменять местами POST и PUT.

Использование REST для построения Web-сервисов.

Как известно, web-сервис — это приложение работающее в World Wide Web и доступ к которому предоставляется по HTTP-протоколу, а обмен информации идет с помощью формата XML. Следовательно, формат данных передаваемых в теле запроса будет всегда XML.

Для каждой единицы информации (info) определяется 5 действий. А именно:

GET /info/ (Index) — получает список всех объектов. Как правило, это упрощенный список, т.е. содержащий только поля идентификатора и названия объекта, без остальных данных.

GET /info/ (View) — получает полную информацию о объекте.

PUT /info/ или POST /info/ (Create) — создает новый объект. Данные передаются в теле запроса без применения кодирования, даже urlencode.

POST /info/ или PUT /info/ (Edit) — изменяет данные с идентификатором , возможно заменяет их. Данные так же передаются в теле запроса, но в отличие от PUT здесь есть некоторый нюанс. Дело в том, что POST-запрос подразумевает наличие urldecoded-post-data. Т.е. если не применять кодирования — это нарушение стандарта. Тут кто как хочет – некоторые не обращают внимания на стандарт, некоторые используют какую-нибудь post-переменную.

DELETE /info/ (Delete) — удаляет данные с идентификатором .

Как видно, в архитектура REST очень проста в плане использования. По виду пришедшего запроса сразу можно определить, что он делает, не разбираясь в форматах (в отличие от SOAP, XML-RPC). Данные передаются без применения дополнительных слоев, поэтому REST считается менее ресурсоемким, поскольку не надо парсить запрос чтоб понять что он должен сделать и не надо переводить данные из одного формата в другой [3].

Немного кода

Далее представлен пример использования классического подхода построения веб-сервисов на основе JAX-WS.