Веб-сервисы — это стандарты, определенные для обмена данными через Интернет. Это не значит, что веб-сервисы будут доступны в Интернете, просто существует согласованный набор «веб-стандартов», которые поддерживаются многими продуктами. При принятии решения о том, какой стандарт принять, наиболее важным моментом часто является совет технического персонала.
Они могут порекомендовать вам стандарт, который проще всего внедрить, который имеет самую широкую техническую поддержку продукта и который, скорее всего, будет хорошо работать в вашей среде. Для успешной реализации SOA, которая выдержит испытание временем и продолжит масштабироваться в будущем, все три фактора чрезвычайно важны. Функциональная совместимость чрезвычайно важна.
WS-I
Организация по совместимости веб-сервисов (WS-I) специализируется на разработке передового опыта для веб-стандартов, обеспечивающего совместимость между различными операционными системами, платформами или языками программирования. WS-I отвечает за определение документов с передовым опытом, таких как безопасность веб-сервисов и технические спецификации обработки веб-сервисов. Эта документация помогает разработчикам и предприятиям соответствовать практикам, которые другие используют для обеспечения удобства работы пользователей.
WS-I также публикует технические спецификации, наборы тестов и примеры развертывания этих протоколов. Фактически, WS-I — это руководящий орган, созданный многими организациями, такими как Microsoft и IBM, и его миссия — продвигать совместимые веб-сервисы.
Соглашение об использовании
Веб-сервисы полагаются на протоколы, гарантирующие осмысленность связи. Содержимое данных, передаваемых между службами, должно быть предварительно согласовано, чтобы обе стороны знали, какой контент получен. SOAP — пример наиболее широко используемого протокола при обмене данными. SOAP использует язык программирования XML, что позволяет обеим сторонам декодировать отправляемые данные и форматировать передаваемую информацию.
иллюстрировать
Вскоре мы рассмотрим некоторые архитектуры, а также обратимся к некоторым протоколам веб-сервисов. Важно не путать эти две вещи. Итак, давайте кратко представим это ниже.
Архитектуры программного обеспечения, такие как REST и RPC, не являются протоколами. Это методы, которые определяют, как соглашение должно быть реализовано.
WSDL (язык описания веб-служб) — это язык, используемый для описания конкретной веб-службы в форматированном виде, чтобы приложения могли анализировать службу. Сам WSDL не предоставляет никаких функций в форме взаимодействия с веб-службами.
Сами протоколы, такие как SOAP, XML-RPC или DCOM, точно определяют, как доставляются сообщения и как программа понимает полученные данные.
В SOA существует два основных типа архитектур: семейство протоколов RPC и подход передачи репрезентативного состояния (REST).
ПКП
Метод удаленного вызова процедур (RPC) позволяет программистам вызывать ресурсы удаленной системы точно так же, как «вызов» локальных ресурсов при программировании в системе. Недостаток сервисов в стиле RPC заключается в том, что люди склонны использовать их так, как если бы они были знакомы с языком программирования на конкретной платформе. Вызвать удаленную процедуру даже легко, если она совпадает с локальной процедурой.
Эта логика нарушает концепцию «слабой связи». Концепция слабой связи фактически означает, что удаленный процесс не должен зависеть от какой-либо конкретной операционной системы или языка программирования.
SOAP является протоколом, пришедшим на смену XML-RPC, и представляет собой всего лишь удаленный вызов процедуры, содержащий информацию в XML. SOAP использует протокол HTTP для отправки данных, что удобно и просто, однако у него есть некоторые недостатки. Несмотря на это, большинство веб-сервисов в наши дни по-прежнему используют протокол HTTP для связи, поскольку они созданы с использованием протокола SOAP.
ОТДЫХ
Подход Representational State Transfer (REST) принципиально отличается от удаленных вызовов процедур, поскольку работает на другом уровне. Вызов REST выглядит как любой другой веб-запрос по протоколу HTTP, а вызов RPC выглядит как вызов стандартной функции. Целью REST является работа со стабильными ресурсами, а не с отдельными сообщениями, что приводит к более стандартному и широко понятному способу взаимодействия, во многом похожему на сам протокол HTTP. REST обрабатывает передачу фрагментов простых данных, а RPC передает сложные процессы.
Следует ли использовать REST или RPC?
Вопрос о том, использовать ли REST, безусловно, хороший. Это похоже на путь будущего. Однако ваша SOA должна быть интегрирована в каждую часть программного обеспечения, которое вы используете в настоящее время. Внедрение REST происходит медленно, в основном из-за поддержки веб-сервисов. Хотя система REST может использовать WSDL для описания сообщения SOAP через HTTP, для его фактического использования недостаточно поддержки. Например, Apache даже не поддерживает методы, необходимые для использования REST без установки подключаемого модуля.
Существуют и другие стандарты, не входящие в семейство веб-сервисов. Но, как и следовало ожидать, эти стандарты не имеют широкой поддержки. Jini, WCF и CORBA — вот некоторые примеры. Когда поставщик предлагает вам продукт, поддерживающий только одну из вышеперечисленных технологий, вам хочется убежать, а не уйти. Веб-сервисы теперь широко поддерживаются. Использование веб-сервисов будет только расти. Сама SOA считается новой, нестабильной и рискованной. Однако эти риски можно в значительной степени снизить, если выбрать соответствующий стандарт веб-сервисов, имеющий широкую техническую поддержку.
Наконец, использование SOAP старой школы в некоторых системах типа RPC в настоящее время является жизнеспособным механизмом построения SOA с использованием веб-сервисов. Если вы сделаете это, вы значительно уменьшите свои шансы на привязку к поставщику.