Как Дон Бокс HTTP "похоронил"

Прошло уже достаточно времени для того, чтобы HTTP был причислен к "старожилам" и стал объектом для критики со стороны новой генерации специалистов. Авторитетного Дона Бокса вряд ли можно отнести к молодому поколению, однако в отличие от многих своих коллег он все еще полон решимости изменить мир к лучшему. Являясь более чем известной личностью в IT-индустрии, Дон ко всему прочему имеет для этого и вполне реальные основания. На конференции DevWeek он заявил о "смерти HTTP", что моментально вызвало бурю негодования.

Чем плох HTTP

Протокол обвиняется сразу по двум пунктам -- однонаправленность соединений и недолговечность последних. Почему же так поздно спохватились, скажете вы? Все дело в том, что подобные вещи не слишком беспокоят как создателей броузеров, так и их пользователей. Во-первых, основная масса операций в WWW действительно носит однонаправленный характер, во-вторых, длительные последовательности операций -- это не то, что требуется рядовому серферу для исследования сайтов. Наоборот, сообщение о тайм-ауте является своего рода спасательным кругом, позволяющим избежать бесконечного ожидания в нестабильной гипертекстовой среде.

Однако когда на горизонте появились Web-службы -- онлайновые сервисы, разрешающие любой программе посредством протокола SOAP использовать удаленное ПО через Internet, недостаточность функциональности HTTP стала очевидной. "Только одна сторона может инициировать обмен через HTTP, другая остается пассивной и в состоянии только отвечать. Для приложений peer-to-peer (P2P) это неприемлемо. Единственная причина, по которой такие приложения функционируют сегодня, это выдумка программистов, умудряющихся обойти ограничения протокола, и это не есть хорошо. Это хакерство, которое ведет к тотальной несовместимости", -- аргументирует Бокс. Вдобавок ко всем грехам HTTP не позволяет контролировать процесс обмена данными так, как того хотелось бы программистам. Например, даже простейшие контрольные суммы и сообщения об ошибках, произошедших в ходе передачи, могут не доходить до клиента.

Итак, Web-службы сами по себе представляют собой неплохую идею, но HTTP -- далеко не самый лучший способ реализовать подобный механизм. В этом случае сетевой обмен изначально должен носить обоюдный характер, кроме того, вполне может потребоваться поддержка неограниченных по времени транзакций. Как образно выразился Дон Бокс: "Мне необходим способ послать серверу запрос и ожидать ответ в течение 5 дней". Справедливости ради следует отметить, что в таком положении дел виновен не сам протокол, а настройки оборудования провайдеров, владеющих опорными сетями. Впрочем, об этой стороне вопроса мы поговорим чуть позже.

Незаменимых протоколов нет?

Суть предложения Дона Бокса достаточно хорошо изложил и многократно повторяет собственно сам виновник смятения в рядах "благородного семейства" Internet-программистов -- не заменить, но сделать протокол HTTP менее важным. То есть вывести его за скобки уравнения, описывающего Web-службы. Конечно, сегодня уже ни одна сила на свете не сможет изменить направление движения IT-индустрии, как невозможно незаметно для пассажиров поезда переставить мчащийся на всех парах тепловоз с обычного железнодорожного полотна на современный монорельс. Фактически идея заключается в создании нового инструмента для новых задач вместо попыток приспособить старый.

Бокс постоянно подчеркивает, что когда он говорит о несовершенстве HTTP, то выражает исключительно мнение частного лица, и Microsoft как корпорация не имеет к этому никакого отношения. И все же он слегка лукавит. Работы ведутся не только в некоторых комитетах W3C, но и внутри софтверного гиганта. Полагаю, что как только правота "повстанцев" будет доказана, фирма не преминет воспользоваться своим положением и возглавит движение. Более того, в гонке "кто первый свергнет империю HTTP", по словам Бокса, участвуют люди из IBM и прочих компаний. Но знаменитый "евангелист" не забывает откреститься от корпоративных интересов: "Если только один разработчик сделает это, игра не будет стоить свеч".

Оценивая происходящее по доступным публике фактам, замечание нашего героя можно рассматривать и как намек на архитектуру GXA (Global XML Web Services Architecture). Последняя действительно была представлена в апреле 2001 года на заседании комитета W3C совместными усилиями Microsoft и IBM. GXA должна обеспечить надежную и простую маршрутизацию сообщений и потоков данных в сети Web-сервисов. Но это отнюдь не означает единства взглядов, внутри группы единомышленников продолжается ожесточенное соперничество. Microsoft ограничилась минимальными изменениями, опубликовав наброски спецификаций WS-Routing, довеска к протоколу SOAP, поддерживающего двунаправленные коммуникации, достаточные для реализации P2P-приложений. IBM сделала ставку на "революцию" и продвигает свою версию HTTP под названием HTTP-R, которая в отличие от предшественницы должна обеспечить гарантированную доставку данных.

HTTP-R делает для HTTP то же, что TCP -- для IP. Фактически новый протокол инкапсулируется в HTTP, но при этом существенно расширяет функциональность последнего. С помощью HTTP-R становится возможной отсылка наборов пакетов, которые будут гарантированно доставлены по назначению (в противном случае возвращается предупреждение об ошибке) строго в том порядке, в котором они отосланы. Контроль над передачей выполняется путем размещения внутри сообщений идентификаторов и кэширования на стороне HTTP-R-клиента. Для разрешения конфликтов введены команды Resolve и Report. Первая отсылается клиентом и содержит номер последнего успешно принятого пакета сообщений. Сервер сравнивает текущий номер с полученным и высылает все недостающие пакеты повторно. Команда Report генерируется в случае возникновения ошибок в ходе передачи и позволяет приостановить поток данных, чтобы разобраться в ситуации. Вместе с Report узел получает номер последнего принятого клиентом пакета, в ответ необходимо передать номер последнего отосланного. В целом, описание особенностей HTTP-R требует подготовки отдельного материала. Подробности можно почерпнуть из 60-страничной черновой спецификации по адресу www-106.ibm.com/developerworks/webservices/library/ws-phtt/httprspecV2.pdf.

Так ли уж плох HTTP...

...Как об этом говорят Дон Бокс и его единомышленники? Многие относятся к данной идее весьма скептически. По их мнению, затея с протоколами -- лишь очередная попытка Microsoft и иже с ней "завладеть всем миром". Звучит банально, однако многие, менее агрессивно настроенные специалисты, столь же прохладно высказываются о попытке "чинить то, что не сломано". "Лично я не нахожу ничего в Web-сервисах, -- пишет Лий Додз (Leigh Dodds), один из постоянных участников Web-конференции xml-dev, -- что требовало бы новых технологий, за исключением возможности кому-то заработать кучу денег". Любой вердикт требует аргументации, и ее не придется долго искать.

Вам нужно получить ответ через сутки после запроса? Решение -- инициализация обратного вызова (callback) на обрабатывающем запрос сервере. Вместе с информацией о запрашиваемых данных клиент оставляет на сервере свой адрес. "Кинопалац" и украинские Web-магазины со своим неизменным правилом "оставьте телефон и мы перезвоним вам, чтобы получить подтверждение заказа" уже освоили эту нехитрую технику длинных транзакций. Иная вариация на ту же тему, предложенная Томасом Пэссином (Thomas Passin), достигает поставленной цели еще элегантнее: сервер в ответ на запрос клиента генерирует уникальный URL, по которому и будет опубликован ответ. Теперь о готовности данных можно узнать, просто загрузив указанный ресурс.

Есть потребность в равноправном диалоге между двумя системами? Реализуйте сервер и клиент HTTP в каждой точке соединения, и любая сторона сможет "слушать и говорить" по своему желанию. Другое дело, что сетевая инфраструктура не готова сегодня к таким двунаправленным соединениям: сетевые экраны обычно настроены так, что из локальной сети в Internet и мышь не проскользнет. Сколько не изобретай протоколы, без разговора "по душам" с системным администратором вашего предприятия или провайдера ничего сделать не удастся. Кроме того, трансляция адресов на границе локальных и глобальных сетей является еще одним препятствием для полноценных онлайновых P2P-приложений. И здесь тоже ничего не надо изобретать -- переход к IPv6 решит проблему.

Недостатки как достоинства

Честно говоря, желание Дона Бокса и К° всенепременно расширить функциональность HTTP вызывает некоторое недоумение, учитывая тот факт, что "другое существенное преимущество, которым обладает концепция XML Web-сервисов перед всеми аналогами, заключается в способности работать посредством стандартных Web-протоколов -- XML, HTTP и TCP/IP" (Роджер Уолтер, Microsoft). Здесь же читаем: "Привязка к HTTP важна, поскольку HTTP поддерживается практически всеми современными ОС. Хотя это свойство является опциональным, почти все реализации SOAP обеспечивают его, потому что пока это единственный стандартизированный протокол для SOAP. В этом кроется источник основного заблуждения -- многие ошибочно полагают, что SOAP требует HTTP. На самом деле некоторые реализации поддерживают протоколы MSMQ, MQ Series, SMTP или TCP/IP, но практически все ныне существующие Web-сервисы используют HTTP только потому, что он повсеместно распространен".

С другой стороны, далеко не все "встречные" предложения так уж просты и заманчивы. Каждое из них имеет свои побочные явления: попытка упаковать Web-сервер и клиент в одно целое таит в себе угрозу безопасности корпоративным сетям. Любое ПО, содержащее Web-сервер, автоматически становится потенциальным объектом атаки, а его администрирование, как правило, требует недюжинной квалификации от пользователя. Другой вариант реализации длительных транзакций подразумевает создание очередей сообщений и регулярный опрос клиентами Web-службы на предмет получения результатов. С точки зрения производительности это неэффективно.

Итак, что мы имеем на сегодняшний день? Индустрия разделилась на два неравных лагеря: большинство, считающее HTTP вполне достаточным для реализации всех современных технологий протоколом, и группу "бунтарей", призывающих к "уничтожению Рима". Каждая сторона имеет массу аргументов: первые, несомненно, правы в ближайшей перспективе, в то время как вторые, возможно, -- в отдаленной. Пока не будут предложены и рассмотрены реальные альтернативы, идею замены HTTP стоит обдумать на досуге, но усматривать в ней угрозу или спасение -- извольте.

Як RPA-платформа допомогла SkyUр автоматизувати оплату рахунків