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

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

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

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

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

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

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

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


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



Cookies make it easier for us to provide you with our services. With the usage of our services you permit us to use cookies.
Ok