Существует два способа просмотра архитектуры веб-сервиса:

  • Первое - изучить отдельные роли каждого веб-сервисного актера.
  • Второе - необходимо изучить стек протоколов новых веб-сервисов.

Роли веб-сервисов

В архитектуре веб-сервисов есть три основные роли:

Поставщик услуг

Это поставщик веб-сервиса. Поставщик услуг реализует услугу и делает ее доступной в Интернете.

Провайдер услуг

Это любой потребитель веб-службы. Запросчик использует существующий веб-сервис, открывая сетевое соединение и отправляя XML-запрос.

Реестр служб

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

Стек протокола веб-службы

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

Сервисный транспорт

Этот уровень отвечает за передачу сообщений между приложениями. В настоящее время этот уровень включает в себя протокол передачи гипертекста (HTTP), протокол простой передачи почты (SMTP), протокол передачи файлов (FTP) и более новые протоколы, такие как Blocks Extensible Exchange Protocol (BEEP).

XML-сообщения

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

Описание услуг

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

Обнаружение службы

Этот уровень отвечает за централизацию служб в общий реестр и обеспечивает легкую публикацию / поиск функциональности. В настоящее время обнаружение сервисов осуществляется через Universal Description, Discovery и Integration (UDDI).

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

Несколько слов об обслуживании транспорта

Нижняя часть стека протоколов веб-службы - это транспорт службы. Этот уровень отвечает за фактическую транспортировку XML-сообщений между двумя компьютерами.

Протокол передачи гипертекста (HTTP)

В настоящее время HTTP является самым популярным вариантом для обслуживания транспорта. HTTP прост, стабилен и широко развернут. Кроме того, большинство брандмауэров разрешают HTTP-трафик. Это позволяет XML-RPC или SOAP-сообщениям маскироваться как HTTP-сообщения. Это хорошо, если вы хотите интегрировать удаленные приложения, но это вызывает ряд проблем безопасности.

Блокирует расширяемый протокол обмена (BEEP)

Это многообещающая альтернатива HTTP. BEEP - это новая инфраструктура Целевой группы Internet Engineering (IETF) для создания новых протоколов. BEEP накладывается непосредственно на TCP и включает в себя ряд встроенных функций, включая исходный протокол установления связи, аутентификацию, безопасность и обработку ошибок. Используя BEEP, можно создавать новые протоколы для различных приложений, включая обмен мгновенными сообщениями, передачу файлов, синдицирование контента и управление сетью.

SOAP не привязан к какому-либо конкретному транспортному протоколу. Фактически, вы можете использовать SOAP через HTTP, SMTP или FTP. Поэтому одной из перспективных идей является использование SOAP над BEEP.


Понравилась статья? Поделитесь ею с друзьями и напишите отзыв в комментариях!



We use cookies on our website. Some of them are essential for the operation of the site, while others help us to improve this site and the user experience (tracking cookies).

You can decide for yourself whether you want to allow cookies or not. Please note that if you reject them, you may not be able to use all the functionalities of the site.

Ok