Пути развития прикладных протоколов
Количественное и качественное развитие всевозможных Internet-приложений формирует потребность в новых прикладных протоколах. В их совершенствовании видится три возможных пути.
Традиционный подход к протоколам. Этот подход и соответствующая категория протоколов названы традиционными, потому что они появились раньше других и изначально были основаны на первичных протоколах Internet, а именно TCP и UDP. Недостаток этого подхода заключается в невозможности совместного использования ими инфраструктуры. Скажем, протокол RosettaNet существенно отличается от протокола ebXML а тот, в свою очередь, — от протокла Jabber. И хотя сейчас они сближаются поскольку стали использовать XML, реальная совместимость еще не достигнута. Опасность традиционного пути состоит в том, что при появлении новых требований всякий раз возникает потребность в создании новых протоколов.
Структурный, или рамочный подход. Структурный подход родился из понимания неизбежности постоянного обновления прикладных протоколов. Как следствие, возникла мысль о рамочной конструкции (framework). Пример такого протокола являют собой SOAP,WSDL, а также менее известные протоколы BEEP/BXXP (Block Extensible Exchange Protocol). Рамочная конструкция предполагает несколько общих характеристик: тип системы; язык описания сервисов; адресную модель; связь с транспортными протоколами нижних уровней (binding); решения по безопасности; разбиение сообщений на компоненты (framing).
По сравнению с традиционной, эта стратегия позволяет создавать общую инфраструктуру. К слабостям рамочного подхода можно отнести то, что по своей логике он продолжает технологии DCOM и CORBA. Не полностью решается проблема безопасности, маршрутизации и асинхронных двунаправленных коммуникаций. Кроме того, не оправдались первые надежды на XML как на средство, которое обеспечит совместимость приложений, как только будет выбрана основная группа стандартов, например, SOAP/WSDL/UDDI. Со временем стала очевидной необходимость в дополнительных протоколах.
Начали появляться WS-Security, WS-Routing, WS-Inspect и т.д. Неопределенность всей картины в целом сильно сдерживает широкое распространение Web-сервисов и стимулирует многих занимать выжидательную позицию в надежде на W3C и другие организации, которые обеспечили бы взаимодействие.
REST и горизонтальный подход. Стратегия, опирающаяся на горизонтальный подход к протоколам, наиболее радикальна. Слово «горизонтальный» означает в данном случае сохранение существующего уровня, без выстраивания уровней поверх него. Предполагается отказаться от разработки новых протоколов, а использовать несколько хорошо проверенных, считая, что для работы с объектами вполне достаточно уметь выполнять четыре типа действий: создание (Creation), восстановление (Retrieval), изменение (Update) и уничтожение (Destruction). Из этих действий получается так называемый «шаблон проектирования» CRUD. Протокол Hypertext Transfer Protocol определяет методы GET/PUT/POST/DELETE, которые и реализуют шаблон CRUD.
Апологеты REST относят сервисы, построенные в этом стиле, ко второму поколению. Остальные Web-сервисы они объявляют сервисами первого поколения, подчеркивая при этом, что SOAP есть ни что иное, как DCOM или CORBA, но работающие через Internet. Действительно, первоначально технологии, подобные SOAP, называли Web-брокерами или объектными брокерами, построенными в Web. Как указывает Прескод [3], используемая в них модель RPC предназначена для замкнутого мира, где вы знаете каждого пользователя, где данные можно перераспределять между ними, где возможны прямые коммуникации. Для успешной работы в Web необходимо поддерживать сложный механизм, обеспечивающий взаимодействие на случай внесения системных изменений.
Требования со стороны защитников REST-сервисов выглядят иногда слишком экстремистскими. Так, Марк Бэйкер считает, что:
Разумеется, никто и никогда не выполнит подобные ультимативные условия, и потому подобная агрессивная тактика только мешает восприятию рациональных решений, существующих в REST-сервисах.
