SOA и WOA, две стороны одной медали

Появление еще одной трехбуквенной аббревиатуры вызывает естественное сомнение, не стоит ли за ней лишь очередная уловка аналитиков и маркетологов. Новизну идей WOA подтверждает тот факт, что в Wikipedia соответствующая статья появилась всего несколько месяцев назад, причем до сих пор она остается предельно краткой, ограниченной буквально двумя фразами. В первой говорится, что WOA — это архитектурный стиль программного обеспечения, сближающий SOA с приложениями, размещенными в Web, во второй — что Web-ориентированные архитектуры направлены на повышение качества взаимодействия между браузером и сервером с использованием технологий REST (REpresentational State Transfer) и POX1.

Кто сказал WOA?

Не стоит удивляться, что новый акроним изобрел, конечно же, аналитик. Вице-президент компании Gartner Ник Галл предложил его осенью 2005 года. Сам Галл объясняет необходимость во введении термина WOA тем, что при анализе целого ряда Web-сайтов, предоставляющих сервисы, он обнаружил методы оформления сервисов, заметно отличающиеся от сложившихся к тому моменту представлений о сервис-ориентированных технологиях. За несколько лет существования SOA уже успел сформироваться канонический стиль, предполагающий использование, как минимум, протокола SOAP, а, как правило, еще и WSDL, а также многочисленных протоколов линейки WS-*. Стиль же WOA построен на подходе REST. Систему отношений между сервером и клиентом в REST называют «репрезентационным переносом состояния» — это такое обращение за представлением данных, выполненное клиентом, которое меняет состояние этого клиента. Иначе говоря, каждое новое полученное представление каким-то образом трансформирует клиентское приложение.

REST в первом приближении

В самом общем смысле REST можно рассматривать как одну из первых реализаций или, скорее, как, предвестник нового направления развития компьютерных систем — ресурсно-ориентированного (Resource Oriented Computing, ROC). Это совершенно новая и, возможно, многообещающая перспектива. Если еще раз обратиться к Wikipedia, то мы обнаружим, что здесь есть только проект статьи на тему ROC, в котором это понятие определяется как абстрактная модель, используемая для описания, проектирования и реализации аппаратных и программных систем. Центром исследований в области ROC является компания-стартап 1060 Research, созданная при поддержке HP Labs.

Перечислим основные понятия REST.

Ресурс (Resource). Нечто, что может быть идентифицировано в Web с помощью универсального идентификатора ресурсов (Uniform Resource Identifier, URI), в форме имени ресурса (Uniform Resource Name, URN) или локатора (Uniform Resource Locator, URL). Имя идентифицирует ресурс, а локатор указывает метод доступа к нему. Важно, что в Web при обращении к ресурсу выбирается не он сам, а его представление.

Представление (Representation). Текстовый документ, изображение, аудио- или видеозапись, нечто материальное или нематериальное, существующее вне Web, скажем, новостная лента. Представление может быть и самим ресурсом, но это частный случай.

Состояние (State). Текущее состояние взаимодействия между объектами по протоколу HTTP, которое поддерживает клиент, а потому каждый запрос от клиента к серверу должен содержать необходимую информацию, чтобы он был «понят» самим клиентом.

Передача (Transfer). Совместно URI и HTTP образуют интерфейс между клиентом и сервером, посредством которого происходит передача представления. Как и в любой объектно-ориентированной системе, передача выполняется с использованием методов вызовов. В HTTP всего восемь методов; если перевести в языковую терминологию, можно сказать, что в HTTP восемь глаголов и бесконечное число существительных (URI). Наиболее часто используемые методы — GET, POST, PUT и DELETE — позволяют выполнять основные действия с данными на сервере: «выбирать» (Retrieve), «создавать» (Create), «изменять» (Update) и «удалять» (Delete), образуя так называемую систему CRUD, обеспечивающую сохранение данных без потерь. В HTTP есть еще четыре дополнительных метода — OPTIONS, HEAD, TRACE и CONNECT.

Подняв волну WOA, Галл, не ведая того, вторично «открыл Америку». Правда, сделал он это куда громче, чем его предшественник Рой Филдинг, ныне главный ученый швейцарско-американской компании Day Software, специализирующейся на управлении контентом. Наиболее полное описание идей, относящихся к REST, можно найти в диссертации Филдинга (www.ics.uci.edu/~fielding/pubs/dissertation/top.htm) и в написанной им с соавторами статье «Еще один метод проектирования Web-архитектур» (www.ics.uci.edu/~taylor/documents/2002-REST-TOIT.pdf). По статистике, диссертация Филдинга загружается читателями намного чаще других, что не случайно. Как обладатель уникальных знаний, Филдинг смог предложить идею REST и сервисов, называемых RESTfull, на основании опыта, полученного им при разработке протокола HTTP. Он не изобрел REST, а скорее «открыл» эту идею в ранее созданном пространстве World Wide Web — очень интересный феномен открытия, сделанного в искусственно созданной среде. С 1994 года он участвовал в разработке версии HTTP 1.0, а позже стал главным архитектором действующего стандарта Hypertext Transfer Protocol (HTTP/1.1) и соавтором стандарта Uniform Resource Identifiers. В 1999 году за работу по проекту Apache HTTP Server он был награжден ACM Software System Award, а журнал MIT Technology Review включал его в список ста наиболее ярких молодых ученых. Именно глубокое понимание сути взаимодействия в Web позволило ему отобразить в REST концепции, лежащие в основе Всемирной Паутины.

В двух словах можно сказать, что REST описывает архитектурные ограничения, призванные обеспечить гипермедийной среде необходимые производительность, масштабируемость и абстрагирование в представлении ресурсов. Сейчас REST чаще всего связывают с реализацией сервисного взаимодействия в системах. Но это частный случай, а диапазон использования соответствующих идей шире — в конечном итоге, Web в целом строится на принципах REST. Первый постулат, лежащий в основе REST, предполагает наличие строгих и единообразных ограничений на интерфейс между ресурсом и клиентом. Ресурсы предоставляются клиентам только в рамках этих ограничений. Второй постулат предполагает полное отсутствие собственного состояния в ресурсе: ресурс не воспринимает состояние клиента, запрос к нему должен содержать всю необходимую для сессии взаимодействия информацию. Заметим, что задолго до Галла в журнале «Открытые системы» была опубликована статья, посвященная сервисам, построенным на основе REST.

REST — да, SOA — нет?

Таким образом, еще до 2005 года, когда был предложен термин WOA, идея REST как форма для реализации альтернативного подхода к сервисной архитектура уже была известна. Правда, на момент дебюта WOA твердой убежденности в том, какую именно роль играет стиль REST, еще не было, а потому Галл и предложил осторожную формулу WOA:

WOA = SOA + REST + WWW

Он дает следующий комментарий: «Мы не можем назвать WOA на 100% RESTful, поскольку возможности технологии REST велики, но все же ограничены». Вместе с SOA пришло понимание роли сервисов, а затем возникло еще и осознание того, что в этом стиле может быть несколько разных архитектурных решений. Поэтому SOA удобно рассматривать как некий зонтичный термин; в таком случае WOA можно считать одним из стилей.

До середины 2007 года ни WOA, ни REST не привлекали к себе внимания, но к 2008-му появились публикации, явно страдающие безапелляционностью, которые отвергают SOA на основе SOAP и предрекают будущее SOA на основе REST.

Примерно год назад стало ясно, что данная формула WOA весьма упрощенно представляет отношения между парами WOA и REST, с одной стороны, и SOA и SOAP — с другой. Есть разные точки зрения. Одни аналитики утверждают, что WOA — это лишь подмножество SOA; другие считают WOA и SOA двумя разными подходами к сервисам, с разными областями действия; наконец, третьи попросту хоронят SOA на основе стека протоколов SOAP, UDDI и WSDL, предрекая полную и окончательную победу WOA+REST. В роли могильщика SOA особенно преуспела аналитик из Burton Group Энн Томас Манес, которая еще пять-шесть лет назад с не меньшим пафосом воспевала SOAP, а сегодня утверждает, что уже через три года начнутся первые реальные внедрения REST, а лет через пять на REST перейдет большинство разработчиков.

На изменение отношения к «классическому» подходу повлияли два обстоятельства. Первое и главное — в существующем виде SOA не оправдывает ожиданий. Аналитики, которые еще недавно воспевали сервис-ориентированные архитектуры, сегодня обрушивают на головы читателей ворох негативной статистики. Количество внедренных решений SOA существенно меньше планируемого, сроки слишком велики, сложность протоколов превышает все мыслимые представления и т.д. Отношение авторов к SOA так круто меняется, что приходит на ум пассаж из «Записных книжек» Ильи Ильфа: «Раньше десять лет хвалили, теперь десять лет будут ругать. Ругать будут за то, за что раньше хвалили».

Второе обстоятельство — мощная экспансия технологий Web 2.0. В отличие от Web 1.0 совокупность технологий нового поколения можно рассматривать в качестве платформы для обеспечения интегрированных сервисов. Появление этих сервисов стало толчком к разговорам о коэволюции SOA и Web 2.0. В биологии под «коэволюцией» понимают такого рода совместную эволюцию видов, взаимодействующих в экосистеме, когда изменения, затрагивающие какие-либо признаки особей одного вида, приводят к изменениям у другого или других видов. В данном случае обе парадигмы основываются на предоставлении программных сервисов, и каждая из них использует Web-технологии. Отличие в том, что в классической архитектуре SOA в качестве механизма доставки требуется сервисная шина предприятия (Enterprise Service Bus, ESB), которая передает Web-сервисы. В WOA «облегченные» сервисы RESTful не требуют специальной схемы — для них достаточно возможностей протокола HTTP.

SOAP против REST

За короткий срок существования WOA ее соотношение с классической архитектурой SOA более или менее уточнилось (см. рисунок), но очень часто можно встретить противопоставление SOAP и REST — или, напротив, неточную трактовку в различии двух подходов. В том и другом случае для поддержки сервисов используются Web-технологии, но в одном случае — в качестве интерфейса между приложениями, а в другом — для передачи данных. Сложилось два различных представления о Web-сервисах — одно, идущее от SOAP, WS-* и других стандартов, а другое, заимствованное непосредственно из популярных Internet-сервисов, которое сводится к API таких сайтов, как Flickr, Google, Amazon и Yahoo, и от источников данных наподобие RSS, основанных на взаимодействии в стиле RESTful. Успех и простота Web-сервисов на основе RESTful побудили некоторых разработчиков пересмотреть свое отношение к более сложным сервисам на базе WS-* и SOAP. Разработчики стали рассматривать REST и SOA как альтернативы, предполагая, что проблему сложности сервис-ориентированной архитектуры удастся решить, отказавшись от SOAP и WS-*. В результате возникли дебаты «SOAP против REST».

Одни аналитики — особенно в этом отношении активна компания Burton Group — утверждают, что будущее только лишь за Web-сервисами на основе REST, предрекая кончину другим. Своей безапелляционностью они заметно напугали представителей лагеря приверженцев SOAP, которые оказались обеспокоены тем, что по недоразумению сервисами RESTful могут попытаться заменить проверенные программные решения, что, в конечном итоге, приведет к подрыву сервисной идеи как таковой. По мнению представителей этого лагеря, на основе REST удается создать лишь упрощенные и незрелые решения, что из-за невозможности создания повторно используемых компонентов — а это одно из важнейших достоинств SOA — приведет к возврату к монолитным архитектурам, но уже на другом уровне.

Как всегда в подобных случаях, ошибочны любые крайности. Истина посередине, право на существование имеют оба типа Web-сервисов — и на SOAP, и на REST. Все определяется областью применения. Для примера можно сравнить использование маршрутизаторов и коммутаторов. Два близких по функциональности типа сетевых устройств не противоречат друг другу, а взаимно дополняют. Точно так же обстоит дело с WOA и SOA — для каждой из этих архитектур с неизбежностью найдется своя ниша.