На рубеже XX и XXI веков разработка прикладного ПО разделилась на два направления: создание классических настольных приложений и Web-приложений. Поначалу, несмотря на рост популярности Web, создавалось впечатление, что "новичкам" никогда не догнать "классиков" по насыщенности функционала, гибкости и производительности. Однако сейчас, похоже, наступил момент, когда разрыв будет преодолен. В качестве примера можно посмотреть, как реализован широко известный проект Google Maps ("Географические карты Google", http://maps.google.com). Все его основные операции - изменение масштаба карты, смещение изображения, прокрутка - выполняются достаточно быстро, не требуя особого времени на перезагрузку Web-страниц.

Google Maps - это пример новых возможностей создания Web-приложений с помощью технологии AJAX - Asynchronous JavaScript + XML (по-русски произносится "аякс"). Еще в начале нынешнего года эта аббревиатура воспринималась как последняя новинка, знакомая лишь узкому кругу специалистов в области разработки Web-приложений, а сейчас она, кажется, превратилась в повседневный термин компьютерных СМИ (правда, пока лишь западных). И самое интересное, что вокруг этой - в общем-то не очень сложной, хотя и оригинальной - технологии разворачивается нешуточная борьба, в которую втягиваются не только ведущие поставщики ПО, но и многочисленные небольшие специализированные компании - разработчики инструментария. Причем основная борьба сегодня (что стало уже традицией для мира ИТ) идет вокруг стандартов для этой технологии.

Сама идея асинхронной модели Web-взаимодействия сервер-клиент известна достаточно давно, первой эту технологию в Web-браузере реализовала еще в конце 90-х годов корпорация Microsoft (http://www.microsoft.com) в своем Internet Explorer 5.0. Тогда это было сделано с помощью дополнительного объекта ActiveX, который получил название XMLHttpRequest. Но все же родоначальником собственно AJAX скорее следует считать компанию Google, которая на практике продемонстрировала эффективность ее применения на примере ряда своих Интернет-проектов - Google Groups, Google Suggest и Google Maps.

Google приложила значительные усилия для реализации данной технологии и показала возможности ее применения. Ее успехи, которые развили и другие поставщики Web-услуг (например, Amazon), привели к тому, что перспективным методом Web-разработки заинтересовались "профессиональные" поставщики платформенного ПО и средств разработки. Именно тогда встал вопрос о необходимости стандартизации AJAX. И, как ни парадоксально, лучшим показателем жизнеспособности и перспективности AJAX стал тот факт, что в этой сфере мы наблюдаем нарастание борьбы между двумя основными противоборствующими группировками софтверных технологий: Open Source & Java и Microsoft .NET.

Конечно, в растущем интересе публики к технологиям AJAX немалую роль играет отточенное за последние десятилетия маркетинговое мастерство ИТ-отрасли, умело "разогревающей" нужные ей темы. Но есть, безусловно, и объективные причины. В истории вычислительной техники легко просматривается периодичность смещения вычислительных мощностей от центра к периферии и обратно. Так вот сейчас течение, много лет направленное в сторону серверной части систем, меняется на обратное движение в сторону клиентских станций. Но поскольку усиления позиций толстого клиента на базе Windows никто (Microsoft не в счет!) не хочет, то возникают такие концепции, как Rich Client Platform (или, в терминологии IBM, Workplace Client Technology) на базе Eclipse и AJAX для Web-браузеров.

Асинхронная программная модель

AJAX в принципе не содержит никаких принципиально новых средств, ее главное новшество состоит в том, что в ней увязаны воедино несколько достаточно хорошо известных технологий:

  • презентационный уровень, основанный на стандартах XHTML и Cascading Style Sheets (CSS);
  • динамический интерактивный пользовательский интерфейс с использованием Document Object Model (DOM);
  • преобразование данных с помощью XML и XSLT;
  • асинхронный доступ к данным с применением XMLHttpRequest;
  • связывание всего этого на базе JavaScript.

Таким образом, полная "формула" AJAX должна выглядеть следующим образом: HTTP + XML + HTML + XMLHttpRequest + JavaScript + CSS.

Классическая модель построения Web-приложения (рис. 1) такова. Пользователь выполняет какие-то действия на клиентской машине, в результате которых на Web-сервер отправляется HTTP-запрос. Сервер выполняет нужные операции - получает данные из базы данных, связывается с другими системами, проводит некую обработку информации и т. п. - и возвращает новую сформированную HTML-страницу на клиентский компьютер. Все это работает в рамках традиционной модели гипертекстовой Web-среды, но такая схема не всегда хороша для создания прикладных программных решений. Фактически пользователь лишается возможности выполнять какие-либо действия на время обращения к серверу, при том что интерфейс уже загружен.

Главная идея AJAX - исключить старт-стопный режим взаимодействия за счет введения специального промежуточного слоя - механизма AJAX (рис. 1). Вместо Web-страницы браузер загружает написанный на JavaScript специальный движок AJAX, который отвечает как за перерисовку внешнего визуального интерфейса, так и за связь с сервером. Этот промежуточный слой позволяет управлять взаимодействием с пользователем асинхронно, независимо от обмена данными с сервером (рис. 2). Теперь каждое действие пользователя вместо отправки HTTP-запроса на сервер формирует JavaScript-вызов к AJAX-движку, который сам управляет интерфейсными операциями, не требующими обращения к серверу. Решающая роль в реализации такой логики работы принадлежит объекту XMLHttpRequest, который позволяет выполнять на JavaScript HTTP-запросы к удаленному серверу без перезагрузки HTML-страниц.

Fig.1Fig.2
Рис. 1. Модели для создания Web-приложений - традиционная и AJAX.
Рис. 2. Синхронная и асинхронная модель работы Web-приложений - традиционного (вверху) и AJAX.

Логику применения AJAX с точки зрения пользователя можно проиллюстрировать на примере проекта Virtual Earth (http://local.live.com) корпорации Microsoft (рис. 3). При работе с медленным Интернет-каналом (по телефонному модему) видно, что карта состоит из отдельных фрагментов. При этом сначала программа загружает те куски, которые должны выводиться на экран в первую очередь, а потом в фоновом режиме начинает закачивать окружающие их области. Таким образом, система заранее готовится к возможным действиям пользователя, например, к смещению кадра карты в любом направлении.

Fig.3
Рис. 3. Промежуточный экран проекта Microsoft Virtual Earth демонстрирует логику применения AJAX с точки зрения пользователя.

"Стандартная" проблема роста

Позитивная идея AJAX в целом достаточно очевидна, но проблема дальнейшего развития этой технологии традиционна для мира Web. Это выработка стандартов, которая сделала AJAX на деле платформенно независимой.

Проблема массового внедрения технологий AJAX упирается в то, что в их изначальном виде они пока слишком сложны для широкого круга разработчиков. Отсюда вытекают две задачи в плане их модернизации и развития. Первая - расширить функциональность и увеличить скорость (это противоречивые требования!) исполнения AJAX-приложений на клиентской стороне; вторая - повысить эффективность процесса разработки AJAX-приложений за счет перехода с низкоуровневого JavaScript-программирования на применение универсальных языков, в частности, Java или .NET.

Однако движение к решению этих задач сразу же ставит под угрозу главное достоинство AJAX - ее платформенную независимость. При этом вопрос совместимости, конечно же, связан не с инструментами для создания AJAX-приложений, а в первую очередь со средой их исполнения - браузерами.

Первый подводный камень - это JavaScript. Хотя в его названии есть составляющая Java, нужно иметь в виду, что этот скриптовый язык, в общем-то, не имеет никакого отношения к Java Platform и похож на Java-язык только с точки зрения синтаксиса (JavaScript был разработан в свое время компанией Netscape для исполнения в среде браузера Netscape Navigator и первоначально носил название LiveScript). JavaScript - явный лидер среди скриптовых Web-языков, но все же, несмотря на наличие рекомендаций комитета W3C, производители браузеров постоянно идут на отклонение от имеющихся стандартов.

Вторая проблема - это объект XMLHttpRequest (или XHR), которому принадлежит решающая роль в реализации AJAX-технологии. Он позволяет выполнять HTTP-запросы к удаленному серверу на языке JavaScript без перезагрузки HTML-страниц (рис. 4). Однако в разных браузерах этот объект реализован по-разному.

Fig.4 Рис. 4. Ключевая роль в AJAX принадлежит объекту XMLHttpRequest.

Как уже говорилось, впервые поддержка XMLHttpRequest появилась в Microsoft Internet Explorer 5.0, причем на уровне отдельного компонента ActiveX. В других популярных браузерах (сначала в Mozilla, потом в FireFox, относительно недавно - в Opera и Safari) эта функция была реализована позднее, но уже на уровне встроенного объекта и в более совершенном виде. А в результате для создания XMLHttpRequest в них применяются разные способы. Так, в Internet Explorer для этого нужно написать следующий код:

var req = new ActiveXObject("Microsoft.XMLHTTP");

а в других браузерах используется более простой синтаксис:

var req = new XMLHttpRequest();

Соответственно, чтобы обеспечить работу AJAX-приложения в разных браузерах, только для создания объекта нужно написать вот такой замысловатый код:

var req;
function loadXMLDoc(url) 
{
  // branch for native XMLHttpRequest object
  if (window.XMLHttpRequest) {
    req = new XMLHttpRequest();
    req.onreadystatechange = processReqChange;
    req.open("GET", url, true);
    req.send(null);
  // branch for IE/Windows ActiveX version
  } else if (window.ActiveXObject) {
    req = new ActiveXObject("Microsoft.XMLHTTP");
    if (req) {
      req.onreadystatechange = processReqChange;
      req.open("GET", url, true);
      req.send();
    }
  }
}

Причина расхождений во многом в том, что до недавнего времени вопросы стандартизации динамических Web-приложений были сосредоточены в основном на серверной стороне, а клиентской части уделялось явно недостаточно внимания. В апреле этого года консорциум W3C опубликовал предварительный вариант новых спецификаций XMLHttpRequest. Это создает хорошую основу для совместимости AJAX-приложений, но все же на этом пути придется решить еще довольно много вопросов. Тем более, что с ростом сферы применения AJAX встал вопрос о расширении функционала и спецификаций XMLHttpRequest. И делать это нужно оперативно, так как разработчики ПО, не ожидая рекомендаций W3C, начинают использовать собственные расширения, что довольно часто приводит к несовместимости приложений.

Дело тут в следующем. Фактически AJAX-приложение состоит из двух частей: прикладного кода (в основном реализующего пользовательский интерфейс) и AJAX-движка, исполняющего этот код. Сегодня каждый такой движок делается разными разработчиками и соответственно уникален. Таким образом, при вызове AJAX-приложения на клиентский компьютер в браузер всякий раз должны передаваться через Интернет оба компонента - прикладной код и движок. Ясно, что это, в свою очередь, накладывает определенные ограничения на размеры, а значит, и функциональность движка.

Идея развития AJAX состоит в том, чтобы унифицировать движки и создать единую среду исполнения AJAX с набором базовых функций (Framework, каркас), которую можно было бы встраивать во все Web-браузеры (чтобы не перекачивать движки по Интернету). Иначе говоря, речь идет о создании нового высокоуровневого слоя поверх нынешних базовых технологий браузеров. Но проблема тут заключается в том, что оптимальная реализация такого нового функционала требует не только более высокого уровня стандартизации уже существующих средств, но и некоторой их модификации с учетом новых требований. И если говорить о XMLHttpRequest как о ключевом объекте AJAX, то его модификация, в свою очередь, влечет за собой необходимость определенной коррекции ряда других, более "глубинных" функций браузера.

Борьба за место под солнцем

Первый сигнал грядущего наступления "промышленной" эксплуатации AJAX-технологий прозвучал в июне 2005 г., когда Microsoft объявила о намерении создать базовую среду разработки и исполнения клиентских AJAX-приложений (инструмент получил кодовое название Atlas), интегрированную с Visual Studio 2005 и ASP.NET 2.0. И уже в сентябре на конференции PDC'2005 корпорация представила прототип этого инструмента.

Ответные шаги со стороны Java-сообщества последовали незамедлительно. Уже в октябре Sun Microsystems (http://www.sun.com) сообщила о намерении реализовать поддержку AJAX в своих средствах разработки, в том числе в Java Studio Creator. В декабре фонд Apache Software (http://www.apache.org) объявил о реализации собственного набора Kabuki AJAX Toolkit Project. IBM (http://www.ibm.com) осенью сообщила о намерении использовать технологию AJAX в своих продуктах Lotus, WebSphere и Rational, а в январе 2006 г. анонсировала новый проект - AJAX Toolkit Framework (ATF). Он будет выполняться на базе open source в рамках концепции Eclipse, в его рамках предполагается создание интегрированной среды разработки AJAX-приложений (включая инструменты отладки и развертывания ПО), поддерживающей AJAX-движки от различных поставщиков (в том числе Dojo и Zimbra). Предполагается, что ATF будет поддерживать обширный круг браузеров, но особый акцент будет сделан на браузере Mozilla, имеющем самые широкие кросс-платформенные возможности.

Этап развития AJAX, который можно назвать периодом "деклараций о намерениях", завершился в феврале. Сначала Microsoft опубликовала первую публичную предварительную версию своего Atlas, причем сразу три компании - Infragistics, FarPoint Technologies и Syncfusion - в тот же момент представили свои AJAX-инструменты в виде модулей расширения Visual Studio 2005. Почти одновременно с этим, 1 февраля, группа ведущих ИТ-компаний (в числе которых BEA Systems, Borland, Eclipse Foundation, Google, Mozilla, Novell, Oracle, Red Hat, Yahoo - при явной лидирующей роли IBM) объявила о новой индустриальной инициативе Open AJAX с целью поддержки данной технологии на принципах открытых стандартов.

Как раз с этого момента термин AJAX прочно обосновался в СМИ и материалах ИТ-компаний. В компьютерных новостях почти каждую неделю стали появляться сообщения о выходе различного AJAX-инструментария от больших и малых компаний и даже индивидуальных разработчиков ПО. Прочие софтверные лидеры (например, Oracle и Software AG) в анонсах своих новых продуктов также не забывают в последние полгода упоминать о возможности AJAX-доступа. Да и поставщики оборудования считают необходимым продемонстрировать свою принципиальную поддержку идей AJAX.

Иллюстрируя спектр поставщиков AJAX-инструментария, приведем два характерных примера. Так, еще осенью прошлого года был представлен частный немецкий проект Ajax.NET Framework (http://www.schwarz-interactive.de), включающий необходимые библиотеки функций для создания AJAX-приложений в среде .NET Framework. А в начале нынешнего мая свою лепту в это направление внесли два лидера ИТ-отрасли: компания Adobe Systems (http://www.adobe.com) представила предварительный вариант своего набора Spry Framework for AJAX (расширения платформы Adobe Engagement), а Google объявила о выпуске бесплатного набора Google Web Toolkit для создания AJAX-программ на Java.

За последние месяцы возник, кажется, не один десяток "сообществ" и "инициатив" по развитию и продвижению AJAX*. Пример тому - проект OpenAJAX (http://www.openajax.ca), реализуемый тремя разработчиками из Калифорнии. На своем сайте они сообщают, что не надо путать их работу с инициативой Open AJAX от IBM, тем более что они объявили о себе раньше "Голубого гиганта". И они совершенно правы, так как сегодня корпоративное сообщество обозначается обоими способами, и с пробелом в названии, и без него. В общем, есть от чего запутаться…


* Собственно, обилие AJAX-инструментария отражает тот факт, что сейчас идет соревнование идей и концепций для реализации как раз таких движков. Большинство частных инициатив в этой области - типичные проекты start-up, которые должны привлечь внимание ведущих ИТ-игроков для последующей реализации идей на промышленном уровне.

И Microsoft против всех…

Ну, конечно, не "всех", а главное, совсем не в одиночестве. Во-первых, корпорация опирается на огромную армию своих партнеров. Во-вторых, ее особая позиция на поле AJAX определяется тем, что компания выступает в одном лице как поставщик самого популярного браузера, клиентской ОС Windows (занимающей практически монопольное положение) и одного из ведущих инструментариев Visual Studio/.NET Framework. Соответственно свою реализацию AJAX-движка в виде Atlas Client Script Framework (ACSF) она пытается максимально привязать к Visual Studio и Windows. Разумеется, новые Atlas-приложения смогут работать в любом не-Microsoft браузере, но только для этого им потребуется каждый раз загружать ACSF, размер которого уже совсем не мал. А ее собственный Internet Explorer наверняка будет использовать встроенный вариант ACSF и, соответственно, работать с Atlas-программами существенно быстрее. Короче говоря, мы столкнемся с типичной для стратегии Microsoft ситуацией, когда Visual Studio и Internet Explorer будут продвигать не только самих себя, но и друг друга.

Впрочем, вполне вероятно, что ACSF станет стандартным компонентом будущей Windows Vista (уже идет речь о его включении в состав Windows Presentation Foundation). Но какой смысл пользователю ставить на Windows еще один браузер, когда в ней уже есть знакомый IE?

Отметим, что, хотя в окончательном варианте Atlas появится лишь в начале 2007 г. в виде дополнительного компонента следующей версии Visual Studio для Windows Vista (кодовое название Orcas), этот инструмент уже сейчас имеет высокую степень готовности. Так, мартовская версия CTP (Community Technology Preview) Atlas распространяется с лицензией Go-Live, что позволит разработчикам ПО уже сейчас создавать на базе этой версии приложения и распространять их на коммерческой основе. Обычно такой тип лицензирования применяется для последних бета-версий, с достаточным уровнем стабильности работы.

Объединятся ли OpenAJAX и Atlas?

Несмотря на все обилие предложений и идей, касающихся AJAX, вполне очевидно, что на этом рынке они будут поляризоваться вокруг двух центров - Microsoft и сообщества OpenAJAX. Учитывая сильные позиции Microsoft в этой области, IBM традиционно сделала ставку на формирование единой отраслевой коалиции.

В начале мая стало известно, что к инициативе IBM присоединились еще 13 компаний, в том числе Adobe, Intel, Opera, SAP и Software AG, в результате чего число ее участников достигло 28. Конечно, это очень серьезная группировка (теперь она получила официальное название OpenAJAX Alliance), которую Microsoft вряд ли может игнорировать. Неудивительно, что почти одновременно с этой информацией в СМИ появились данные о том, что Microsoft получила от OpenAJAX приглашение присоединиться к сообществу. Представители Microsoft, в свою очередь, пока ограничились уклончивым комментарием о готовности к открытому сотрудничеству.

Конференция независимых аяксовцев

В начале мая в Сан-Франциско прошла трехдневная конференция AJAX Experience, организованная независимым фондом Ajaxian.com (его основали два частных эксперта в области Web-разработки). По сути дела это было одно из первых масштабных мероприятий, посвященных вопросам развития AJAX-технологий; правда, в его работе приняли участие в основном представители "индивидуальных" компаний, хотя были там и крупные игроки, в том числе Microsoft и IBM.

В одном из докладов был сделан общий обзор предложений в области AJAX. Так, если в декабре прошлого года насчитывалось 90 проектов, то сейчас их число выросло до 134. Из них 58 реализовано непосредственно на базе JavaScript, остальные на основе других языков (в том числе по 22 - на Java и PHP, 13 - на платформе .NET).

Интересно также, какие новые возможности в ходе обсуждения на конференции предлагалось включить в браузер следующего поколения. Это:

  • ускоритель 2D-графики (Canvas), который должен работать поверх нынешних технологий DirectX, Quartz и Cairo/xgl;
  • оперативный JIT-компилятор (Just-in-Time) для JavaScript;
  • применение прозрачной модели памяти в сочетании с набором инструментов самоанализа и отладки;
  • набор функций API для работы с внешней памятью.

Любопытно и то, что в одном из выступлений прозвучала едкая критика в адрес будущего Internet Explorer 7.0 в том плане, что Microsoft совсем не спешит включать в свой продукт новейшие технологии (назывались Scalable Vector Graphics, Canvas, Vector Markup Language), которые уже применяются в других браузерах. С другой стороны, собравшиеся одобрили намерение Microsoft выпустить набор Windows Presentation Foundation Everywhere - портируемый вариант Windows Presentation Foundation, который сможет работать на разных платформах.

Отметим, что тематика конференции вышла далеко за рамки круга проблем AJAX. В связи с этим в ряде выступлений прозвучало пожелание как-то изменить название мероприятия - на что организаторы резонно ответили: "Кто же на нас обратит внимание, если в названии не будет слова AJAX?".