Веб-сервисы в Java SE: Часть 1. Обзор инструментов

  1. Что такое веб-сервисы?
  2. Рисунок 1. Клиент обращается к ресурсу путем обмена сообщениями с веб-сервисом
  3. Основанные на SOAP веб-сервисы
  4. Рисунок 2. Операция веб-сервиса включает входные и выходные сообщения
  5. Рисунок 3. Интерфейсы операций доступны через их конечные точки
  6. Рисунок 4. Веб-сервис на основе SOAP включает в себя инициатор запросов, поставщик услуг и брокер услуг...
  7. RESTful веб-сервисы
  8. Поддержка веб-сервисов в Java SE
  9. API-интерфейсы

Java Standard Edition (SE) 6 включает поддержку веб-сервисов. Эта статья начинает серию из четырех частей, посвященную веб-сервисам в Java SE, с объяснения того, что такое веб-сервисы, и обзора их поддержки в Java SE. В будущих публикациях будет использоваться эта поддержка для создания веб-сервисов на основе SOAP и RESTful, а также будут рассмотрены дополнительные темы о веб-сервисах.

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

Википедия определяет веб-сервис как «программная система, разработанная для поддержки взаимодействия компьютеров между машинами по сети». Более подробное определение можно получить, предварительно определив части этого термина:

  • Интернет: огромная взаимосвязанная сеть ресурсов, где ресурсом является источник данных с именем, унифицированным идентификатором ресурса (URI), такой как документ на основе PDF, видеопоток, веб-страница или даже приложение. К этим ресурсам можно получить доступ с помощью стандартных интернет-протоколов, таких как протокол передачи гипертекста (HTTP) или простой протокол передачи почты (SMTP).
  • Сервис: серверное приложение или программный компонент, который предоставляет клиенту ресурс посредством обмена сообщениями в соответствии с шаблон обмена сообщениями (MEP) , ответ на запрос MEP является типичным.

С учетом этих определений веб-служба является серверным прикладным / программным компонентом, который предоставляет веб-ресурс клиентам посредством обмена сообщениями. Эти сообщения могут быть отформатированы в соответствии с расширяемым языком разметки (XML) или нотацией объектов JavaScript (JSON). Кроме того, эти сообщения можно рассматривать как вызов функций веб-службы и получение результатов вызова. Рисунок 1 иллюстрирует этот обмен сообщениями.

Рисунок 1. Клиент обращается к ресурсу путем обмена сообщениями с веб-сервисом

Клиент обращается к ресурсу путем обмена сообщениями с веб-сервисом

Веб-сервисы могут быть классифицированы как простые или сложные. Простые веб-службы не взаимодействуют с другими веб-службами (например, автономным серверным приложением с единственной функцией, которая возвращает текущее время для указанного часового пояса). Напротив, сложные веб-сервисы часто взаимодействуют с другими веб-сервисами. Например, обобщенная веб-служба социальной сети может взаимодействовать с веб-службами Twitter и Facebook, чтобы получать и возвращать своему клиенту всю информацию Twitter и всю информацию Facebook для конкретного человека. Сложные веб-службы также называются гибридными приложениями, поскольку они объединяют (комбинируют) данные из нескольких веб-служб.

Основанные на SOAP веб-сервисы

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

Рисунок 2. Операция веб-сервиса включает входные и выходные сообщения

Операция веб-сервиса включает входные и выходные сообщения

Связанные операции часто группируются в интерфейс , который концептуально похож на интерфейс Java. Привязка предоставляет конкретные сведения о том, как интерфейс связан с протоколом обмена сообщениями (в частности, SOAP) для передачи команд, кодов ошибок и других элементов по проводам. Привязка и сетевой адрес (IP-адрес и порт) URI известны как конечная точка , а набор конечных точек - это веб-служба . На рисунке 3 представлена ​​эта архитектура.

Рисунок 3. Интерфейсы операций доступны через их конечные точки

Интерфейсы операций доступны через их конечные точки

SOAP часто используется с языком описания веб-служб (WSDL, произносится как односторонний) , языком XML для определения операций веб-службы. Документ WSDL - это официальный договор между веб-службой на основе SOAP и его клиентами, содержащий все детали для взаимодействия с веб-службой. Этот документ позволяет группировать сообщения в операции и операции в интерфейсы. Это также позволяет вам определять привязку для каждого интерфейса, а также адрес конечной точки.

Помимо поддержки документов WSDL, веб-службы на основе SOAP имеют следующие свойства:

  • Способность решать сложные нефункциональные требования, такие как безопасность и транзакции: эти требования доступны через различные спецификации. Для обеспечения взаимодействия между этими спецификациями была создана Организация по взаимодействию веб-сервисов (WS-I) (отраслевой консорциум). WS-I создал набор профилей, где профиль - это набор спецификаций именованных веб-сервисов на определенных уровнях редакции, а также набор рекомендаций по реализации и взаимодействию, в которых рекомендуется, как спецификации могут использоваться для разработки взаимодействующих веб-сервисов. Например, самый первый профиль, WS-I Basic Profile 1.0 , состоит из следующего набора непатентованных спецификаций Web-сервиса:
  • SOAP 1.1
  • WSDL 1.1
  • Универсальное описание обнаружения и интеграции (UDDI) 2.0
  • XML 1.0 (второе издание)
  • Схема XML, часть 1: структуры
  • XML-схема. Часть 2. Типы данных.
  • RFC2246: протокол безопасности транспортного уровня версии 1.0
  • RFC2459: сертификат инфраструктуры открытого ключа Internet X.509 и профиль CRL
  • RFC2616: протокол передачи гипертекста 1.1
  • RFC2818: HTTP через TLS
  • RFC2965: Механизм управления состоянием HTTP
  • Протокол уровня защищенных сокетов версии 3.0

Дополнительные примеры профиля включают базовый профиль безопасности WS-I и простой профиль привязки SOAP. Для получения дополнительной информации об этих и других профилях посетите WS-I Веб-сайт. Java SE поддерживает Базовый профиль WS-I.

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

Веб-службы на основе SOAP выполняются в среде, которая включает в себя инициатор запросов (клиент), поставщик услуг и брокер служб. Эта среда показана на рисунке 4.

Рисунок 4. Веб-сервис на основе SOAP включает в себя инициатор запросов, поставщик услуг и брокер услуг (например, UDDI)

Веб-сервис на основе SOAP включает в себя инициатор запросов, поставщик услуг и брокер услуг (например, UDDI)

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

Поставщики услуг должны быть опубликованы, чтобы другие могли их найти и использовать. В августе 2000 года была запущена открытая отраслевая инициатива, известная как универсальное описание, обнаружение и интеграция (UDDI), которая позволяет предприятиям публиковать списки услуг, обнаруживать друг друга и определять, как сервисы или программные приложения взаимодействуют через Интернет. Однако этот независимый от платформы реестр на основе XML не получил широкого распространения и в настоящее время не используется. Многие разработчики обнаружили, что UDDI слишком сложен и лишен функциональности, и выбрали альтернативы, такие как публикация информации на веб-сайте. Например, Google однажды сделал свои общедоступные веб-службы (например, Google Maps) доступными на http://code.google.com/more/ ,

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

RESTful веб-сервисы

Веб-службы на основе SOAP могут доставляться по таким протоколам, как HTTP, SMTP, FTP и Блокирует расширяемый протокол обмена (BEEP) , Доставка сообщений SOAP через HTTP может рассматриваться как особый вид веб-службы RESTful.

Веб-служба RESTful - это широко используемая категория веб-служб, основанная на передаче представления состояния (REST) , стиле архитектуры программного обеспечения для распределенных гипермедиа-систем (систем, в которых изображения, текст и другие ресурсы расположены вокруг сетей и доступны через гиперссылки). , Интересной гипермедиа системой в контексте веб-сервисов является World Wide Web.

Центральной частью REST является URI-идентифицируемый ресурс. REST идентифицирует ресурсы по их типам MIME (например, text / xml). Кроме того, у ресурсов есть состояния, которые фиксируются их представлениями. Когда клиент запрашивает ресурс у веб-службы RESTful, служба отправляет MIME-типизированное представление ресурса клиенту.

Клиенты используют HTTP-команды POST, GET, PUT и DELETE для извлечения представлений ресурсов и управления ресурсами. REST отображает эти глаголы в базу данных Создать, прочитать, обновить и удалить (CRUD) операции, как следует:

  • POST: создание нового ресурса на основе данных запроса.
  • GET: чтение существующего ресурса без создания побочных эффектов (не изменяйте ресурс).
  • PUT: обновить существующий ресурс данными запроса.
  • УДАЛИТЬ: Удалить существующий ресурс.

За каждым глаголом следует URI, который идентифицирует ресурс. (Этот чрезвычайно простой подход принципиально несовместим с подходом SOAP по отправке закодированных сообщений на один ресурс.) URI может ссылаться на коллекцию, например http://javajeff.ca/library, или на элемент коллекции, например как http://javajeff.ca/library/9781484219157 - эти URI являются только иллюстрациями.

Для запросов POST и PUT данные о ресурсах на основе XML передаются как тело запроса. Например, вы можете интерпретировать POST http://javajeff.ca/library HTTP / 1.1 (где HTTP / 1.1 описывает версию HTTP запрашивающей стороны) как запрос на вставку XML-данных POST в коллекцию http://javajeff.ca/library ресурс.

Для запросов GET и DELETE данные обычно передаются в виде строк запроса, где строка запроса - это та часть URI, которая начинается с? персонаж. Например, где GET http://javajeff.ca/library может вернуть список идентификаторов для всех книг в библиотечном ресурсе, GET http://javajeff.ca/library?isbn=9781484219157, вероятно, вернет представление книги ресурс, строка запроса которого идентифицирует международный стандартный номер книги (ISBN) 9781484219157.

REST также полагается на стандартные коды ответов HTTP, такие как 404 (запрошенный ресурс не найден) и 200 (операция с ресурсом выполнена успешно), а также типы MIME (когда извлекаются представления ресурсов).

Поддержка веб-сервисов в Java SE

До Java SE 6 веб-службы на основе Java разрабатывались исключительно с использованием Java Enterprise Edition (EE) SDK. Хотя Java EE предпочтительнее для разработки веб-служб с точки зрения производства, поскольку серверы на основе Java EE обеспечивают очень высокую степень масштабируемости, инфраструктуру безопасности, средства мониторинга и т. Д., Повторное развертывание веб-службы в Java EE Контейнер часто занимал много времени, замедляя развитие. Java SE 6 упростила и ускорила разработку веб-служб, добавив в свое ядро ​​API, аннотации, инструменты и облегченный HTTP-сервер (для развертывания веб-служб на простом веб-сервере и тестирования их в этой среде).

API-интерфейсы

Java SE предоставляет несколько API, которые поддерживают веб-сервисы. Наряду с различными API-интерфейсами JAXP (SAX, DOM, StAX и т. Д.), Которые я обсуждаю в Java XML и JSON , Java SE предоставляет API-интерфейсы JAX-WS, JAXB и SAAJ:

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