Ликбез по веб-сервисам
Что такое веб-сервисы?
Прежде всего, веб-сервисы (или веб-службы) — это технология. И как и любая другая технология, они имеют довольно четко очерченную среду применения.
Если посмотреть на веб-сервисы в разрезе стека сетевых протококолов, мы увидим, что это, в классическом случае, не что иное, как еще одна надстройка поверх протокола HTTP. С другой стороны, если гипотетически разделить Интернет на несколько слоев, мы сможем выделить, как минимум, два концептуальных типа приложений — вычислительные узлы, которые реализуют нетривиальные функции и прикладные веб-ресурсы. При этом вторые, зачастую заинтересованы в услугах первых. Но и сам Интернет — разнороден, т. е. различные приложения на различных узлах сети функционируют на разных аппаратно-программных платформах, и используют различные технологии и языки. Чтобы связать все это и предоставить возможность одним приложениям обмениваться данными с другими, и были придуманы веб-сервисы. По сути, веб-сервисы — это реализация абсолютно четких интерфейсов обмена данными между различными приложениями, которые написаны не только на разных языках, но и распределены на разных узлах сети.
Именно с появлением веб-сервисов развилась идея SOA — сервис-ориентированной архитектуры веб-приложений (Service Oriented Architecture).
Протоколы веб-сервисов
На сегодняшний день наибольшее распространение получили следующие протоколы реализации веб-сервисов:
- SOAP (Simple Object Access Protocol) — на самом деле это тройка стандартов SOAP/WSDL/UDDI
- REST (Representational State Transfer)
- XML-RPC (XML Remote Procedure Call)
На самом деле, 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 — Концепция веб-сервиса
- SOAP (Simple Object Access Protocol) — протокол обмена сообщениями между потребителем и поставщиком веб-сервиса;
- WSDL (Web Services Description Language) — язык описания внешних интерфейсов веб-службы;
- UDDI (Universal Discovery, Description and Integration) — универсальный интерфейс распознавания, описания и интеграции, используемый для формирования каталога веб-сервисов и доступа к нему.
Рисунок 2 — Протоколы веб-сервисов
Все спецификации, используемые в технологии, основаны на XML и, соответственно, наследуют его преимущества (структурированность, гибкость и т.д.) и недостатки (громоздкость, медлительность).
SOAP
SOAP (изначально Simple Object Access Protocol, а в версии 1.2 официальная расшифровка аббревиатуры отсутствует) — простой протокол доступа к объектам (компонентам распределенной вычислительной системы), основанный на обмене структурированными сообщениями. Как любой текстовый протокол, SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTPS и др., но чаще всего SOAP используется поверх HTTP.
Все сообщения SOAP оформляются в виде структуры, называемой конвертом (envelop), включающей следующие элементы:
- Идентификатор сообщения (локальное имя).
- Опциональный элемент Header (заголовок):
- Ноль или более ссылок на используемые пространства имен;
- Ноль или более свойств, доступных в этом пространстве имен.
- Обязательный элемент Body (тело сообщения)
- Ноль или более ссылок на используемые пространства имен;
- Дочерние элементы тела сообщения
Пример сообщения SOAP:
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<n:alertcontrol xmlns:n="http://example.org/alertcontrol">
<n:priority>1</n:priority>
<n:expires>2001-06-22T14:00:00-05:00</n:expires>
</n:alertcontrol>
</env:Header>
<env:Body>
<m:alert xmlns:m="http://example.org/alert">
<m:msg>Get up at 6:30 AM</m:msg>
</m:alert>
</env:Body>
</env:Envelope>
WSDL
Язык описания веб-сервисов (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 шаблона обмена сообщениями (типы операций):
- Однонаправленные операции (One-way): операция может принимать сообщение, но не будет возвращать ответ.
- Запрос-ответ (Request-response): операция может принять запрос и должна вернуть ответ.
- Вопрос-ответ (Solicit-response): операция может послать запрос и будет ждать ответ на него.
- Извещение (Notification): операция может послать сообщение, но не будет ожидать ответ.
В версии WSDL 2.0 эти шаблоны изменены и расширены в сторону поддержки сообщений об ошибках (например, шаблон Robust-in-only), но для обратной совместимости поддерживаются типы WSDL 1.1.
UDDI
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.
Вот как это будет выглядеть на примере:
- GET /book/ — получить список всех книг
- GET /book/3/ — получить книгу номер 3
- PUT /book/ — добавить книгу (данные в теле запроса)
- POST /book/3 — изменить книгу (данные в теле запроса)
- DELETE /book/3 — удалить книгу
ВАЖНОЕ ДОПОЛНЕНИЕ: Существуют так называемые 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/{id} (View) — получает полную информацию о объекте.
PUT /info/ или POST /info/ (Create) — создает новый объект. Данные передаются в теле запроса без применения кодирования, даже urlencode.
POST /info/{id} или PUT /info/{id} (Edit) — изменяет данные с идентификатором {id}, возможно заменяет их. Данные так же передаются в теле запроса, но в отличие от PUT здесь есть некоторый нюанс. Дело в том, что POST-запрос подразумевает наличие urldecoded-post-data. Т.е. если не применять кодирования — это нарушение стандарта. Тут кто как хочет – некоторые не обращают внимания на стандарт, некоторые используют какую-нибудь post-переменную.
DELETE /info/{id} (Delete) — удаляет данные с идентификатором {id}.
В данном примере /info/ — может и базироваться на какой-то другой информации, что может быть (и должно) быть отражено в URL: /data/4/otherdata/6/info/3/ , например.
Как видно, в архитектура REST очень проста в плане использования. По виду пришедшего запроса сразу можно определить, что он делает, не разбираясь в форматах (в отличие от SOAP, XML-RPC). Данные передаются без применения дополнительных слоев, поэтому REST считается менее ресурсоемким, поскольку не надо парсить запрос чтоб понять что он должен сделать и не надо переводить данные из одного формата в другой [3].
Немного кода
Далее представлен пример использования классического подхода построения веб-сервисов на основе JAX-WS.
Класс сервиса
package com.horstmann.corejava;
import java.util.*;
import javax.jws.*;
/**
* This class is the implementation for a Warehouse web service
* @version 1.0 2007-10-09
* @author Cay Horstmann
*/
@WebService
public class Warehouse
{
public Warehouse()
{
prices = new HashMap<String, Double>();
prices.put("Blackwell Toaster", 24.95);
prices.put("ZapXpress Microwave Oven", 49.95);
}
public double getPrice(@WebParam(name="description") String description)
{
Double price = prices.get(description);
return price == null ? 0 : price;
}
private Map<String, Double> prices;
}
Класс сервера
package com.horstmann.corejava;
import javax.xml.ws.*;
public class WarehouseServer
{
public static void main(String[] args)
{
Endpoint.publish("http://localhost:8080/WebServices/warehouse", new Warehouse());
}
}
Класс клиента
import java.rmi.*;
import javax.naming.*;
import com.horstmann.corejava.server.*;
/**
* The client for the warehouse program.
* @version 1.0 2007-10-09
* @author Cay Horstmann
*/
public class WarehouseClient
{
public static void main(String[] args) throws NamingException, RemoteException
{
WarehouseService service = new WarehouseService();
Warehouse port = service.getPort(Warehouse.class);
String descr = "Blackwell Toaster";
double price = port.getPrice(descr);
System.out.println(descr + ": " + price);
}
}
Список источников
- Веб-сервисы в теории и на практике для начинающих [Электронный ресурс]. Режим доступа: http://habrahabr.ru/post/46374/
- Веб-сервисы как средство интеграции приложений в WWW [Электронный ресурс]. Режим доступа: http://www.4stud.info/networking/web-services.html
- Архитектура REST [Электронный ресурс]. Режим доступа: http://habrahabr.ru/post/38730/