На протяжении последних двух лет в среде разработчиков стандартов для Web-сервисов развернулась активная дискуссия на тему: «SOAP против REST». С этими двумя аббревиатурами ассоциируются два почти диаметрально противоположных подхода к организации Web-сервисов. SOAP (Simple Object Access Protocol) — хорошо известный нижний уровень в стеке протоколов. REST (Representational State Transfer) — менее известное явление, называемое его авторами «архитектурным стилем». В творческом споре против основной массы сторонников SOAP выступает небольшая, никак формально не организованная, группа инакомыслящих, которые поддерживают REST. Скорее всего, победителя в этом противостоянии не будет; как обычно бывает, большинство учтет мнение меньшинства, и вместо противопоставляющего лозунга «SOAP против REST» появится конструктивный «SOAP + REST».
Утверждение, что будущее — за сетевыми архитектурами, превратилось в банальность, сейчас только и разговоров, что Grid да SOA (Service-Oriented Architecture). Но, как говорят англичане, «ободрать кошку можно по-разному», какими именно станут в будущем сетевые архитектуры, сказать сложно, однако наступила пора выбора. Есть взгляды, которых придерживается большинство; их разделяют и крупные компании. Но есть и мнения оппонирующих им «диссидентов».
Во всех нынешних начинаниях, связанных с сетями, так или иначе, присутствует World Wide Web. Первопроходец Всемирной паутины Тим Бернерс-Ли дал своему детищу гениальное по лаконичности определение: «Web — это просто пространство (буквально, «вселенная», universe — Л.Ч.) глобальной информации с сетевым доступом». Идеи, которые заложила возглавляемая им группа энтузиастов из CERN в фундамент архитектуры Web, были настолько продуктивными, что спустя несколько лет оказались востребованными в компьютерной индустрии.
На наших глазах почти в точности повторяется история заимствования корпоративными intranet-сетями технологий из Internet, которая имела место лет пять-семь назад. Однако есть и отличия, вполне очевидно, что архитектура WWW осмыслена адаптаторами в гораздо меньшей мере, чем в свое время архитектура Internet. В той трактовке Web, которая получила распространение и усиленно эксплуатируется (особенно, когда речь идет о Web-сервисах), все сводится к представлению Web исключительно в качестве коммуникационной среды, что явно противоречит приведенному определению. Web-cервисы, построенные на основе протокола SOAP, не используют возможности Web в полной мере — в том числе, и возможности механизма адресации информационных ресурсов, основанного на универсальных идентификаторах ресурсов (URI).
Не удивительно, что в академической среде и в близком к ней инженерном сообществе, глубже понимающем идеи WWW, возникло альтернативное направление, которое, по мнению его приверженцев, полноценно, по-настоящему использует это великолепное изобретение. Такие альтернативные сервисы называют сервисами на основе REST.
За фасадом победного шествия архитектур, ориентированных на сервисы, и Web-сервисов, вне сферы внимания коммерческой прессы идет невидимое миру противоборство приверженцев различных точек зрения на устройство Web-сервисов. С одной стороны выступает вся индустрия, возглавляемая такими могучими компаниями, как IBM, Microsoft, Sun Microsystems, которые продвигают идеи Web-сервисов на основе «святой троицы» протоколов SOAP/WSDL/UDDI, с другой — крошечная группа энтузиастов идеологии Web в чистом виде. И это не просто борьба технических идей, а скорее отчаянное сопротивление «пуристов», сопротивление, как им кажется, искажению и коммерциализации принципов Всемирной паутины. Острие их нападок направлено на группы Technical Architecture Group (TAG) и особенно Web Services Architecture Working Group (WSAWG), которые действуют в составе основного координирующего органа Web, консорциума W3C. По их мнению, наиболее полно выраженному Марком Бэйкером, в конце 2004 года коммерческие подходы к Web-сервисам ожидает серьезный кризис. В TAG, напротив, считают проповедуемые альтернативные сервисы на основе архитектурного стиля REST частным случаем использования HTTP и не видят за ними серьезного будущего. Наиболее выдержанные специалисты, например, Дэвид Орчард (David Orchard), директор по технологиям компании BEA Systems, являются выразителями более умеренных взглядов.
Консолидированная точка зрения большинства на Web-сервисы представлена в статье «SOA — шаг за горизонт», публикуемой в этом номере журнала. Но двумя лицами дело не ограничивается; может быть и третье, и четвертое. В этой же статье представлена точка зрения меньшинства; знакомство с ней будет полезно хотя бы потому, что позволит лучше понять, почему название «Web-сервисы» используется в основном не вполне корректно. Название неудачное: троица протоколов не имеет по сути своей никакого отношения к Web, кроме использования механизма адресации. Однако название уже прижилось, как говорится, «термин занят». В данной статье, чтобы различить два подхода, будем временно использовать термин «SOAP-сервисы» для обозначения сервисов, построенных на основе SOAP/WSDL/UDDI, и «REST-сервисы» для альтернативного подхода.
Собственное видение проблем программного обеспечения Сети Филдинг описал в докторской диссертации «Архитектурные стили и проектирование архитектур сетевого программного обеспечение» [1]. Работа представляет собой не только фундаментальное исследование на означенную тему, но одновременно и прекрасный учебник.
В настоящее время Филдинг работает в должности научного руководителя компании Day Software, но миру профессионалов он гораздо лучше известен своими прежними достижениями и общественной деятельностью. Стоит вспомнить участие в разработке инфраструктуры World Wide Web, где именно он был главным архитектором Hypertext Transfer Protocol (HTTP/1.1), а также соавтором стандартов для HTTP и URI. Кроме того, Филдинг был в числе инициаторов нескольких проектов известных программных систем с открытым кодом (один из них — проект Apache HTTP Server, который, как признано, является основой более 60% Internet-сайтов). В сферу научных интересов Филдинга входят также архитектура программного обеспечения для сетевых приложений, сетевые протоколы прикладного уровня, средства совместной разработки программного обеспечения. За свои научные успехи, в частности, за проект Apache, в 1999 году он был удостоен ACM Software System Award. В том же году Филдинг был включен в почетный список Top100 молодых исследователей, который составляется журналом MIT Technology Review.
Стиль REST методично раскрыт в диссертации Филдинга, первые четыре главы которой посвящены определению понятия «архитектурный стиль» вообще и принципам построения сетевого программного обеспечения. В пятой главе изложены начала REST. В более сжатом виде идеи стиля REST изложены в [2]; прочтение этой статьи можно считать обязательным для того, кто хочет понять, что такое WWW и REST. В данном случае вполне можно ограничиться самым грубым приближением и сказать, что REST задуман как основа масштабируемого прикладного протокола, обеспечивающего доступ к информационным ресурсам. Подчеркнем, именно к ресурсам. Противопоставление REST остальному миру сервисов можно, в какой-то мере, сравнить с противопоставлением процессорной архитектуры RISC архитектуре CISC. В обоих случаях используется ограниченный набор операций; в случае доступа к ресурсам в стиле REST их всего четыре: GET, PUT, POST и DELETE. Этих четырех операций оказывается достаточно для оптимальных манипуляций с сетевыми ресурсами; главное, что они позволяют, — отделить размещение ресурсов на сервере от восприятия этой информации клиентом и потоковую передачу информации. Антиподом REST является подход, основанный на вызове удаленных процедур (Remote Procedure Call — RPC).
Количественное и качественное развитие всевозможных 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-сервисах.
По мнению специалистов из WSAWG, позиция оппонентов из лагеря REST не учитывает возможности более широкого взгляда на явления. Они считают, что использование Web-технологий является конкретной и частной реализацией Архитектуры, ориентированной на сервисы, и, следовательно, определенным ограничением на общую архитектуру SOA. Это ограничение заключается в том, что агенты SOA обращаются к объектам, которые в World Wide Web принято считать ресурсами, и которые идентифицируются при помощи URI. С другой стороны, Web-приложения в стиле REST строятся в предположении еще больших ограничений, которые заключаются в использовании унифицированной семантики и унифицированных средств манипулирования ресурсами. В WSAWG различают два типа сервисов.
Иначе говоря, «прямые» сервисы используют известные Web-серверы для манипуляций с данными, а «посредничающие» сервисы исполняются средствами внешних кодов, которые вызываются сообщениями и с помощью Web-серверов. Однако оба класса могут идентифицировать ресурсы общими средствами URI, использовать протоколы Web и форматы XML для обмена сообщениями.
Если обратиться к истории, то надо вспомнить, что на уровне языка ассемблера данные, и программы адресовались одинаково. Но уже тогда возникла проблема: как построить вызов к подпрограмме — подкомпилировать ее в тело кода, выполнив специальную макрокоманду, или же использовать вызов с передачей параметров. Сегодня стоит по сути дела та же самая проблема, но на другом уровне. В 70-е годы появилось структурное программирование, был предан анафеме оператор безусловного перехода goto, точнее обозначилось деление на данные и программы. В дальнейшем развитие оборудования хранения данных привело к созданию реляционных СУБД и языка SQL. Для работы с данными оказалось достаточным операторов insert, select, update и delete. В 90-е годы сети стали соединяться Internet-протоколами, подпрограммы с параметрами трансформировались в объекты с сообщениями, а хранимые процедуры стали нормой для операций, модифицирующих реляционные СУБД.
Конфликт «REST vs. SOAP» стоит рассматривать как диалектическое противоречие. Так или иначе оно будет разрешено, позволив более четко представить соотношение между кодами и данными на уровне архитектур SOA откроет путь к более продуктивному использованию Web-сервисов.
Литература