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