Ajax в действии

Каким должен бытъ Web-интерфейс

Вэтой главе...

•Асинхронное сетевое взаимодействие

иобразы использования

•Основные различия между Ajax

иклассическими Web-приложениями

•Основные принципы Ajax

•Ajax в реальном мире

Глава 1. Каким должен быть Web-интерфейс З5

Слово "богатый" означает обилие возможностей, заложенных в модел взаимодействия. Эта модель предполагает поддержку разнообразных спосс бов ввода данных и обеспечение своевременного и интуитивно понятного от вета. Выяснить, является ли взаимодействие богатым, можно лишь путе! сравнения интерфейсов. В качестве эталона можно выбрать некоторые хоре шо зарекомендовавшие себя приложения для настольных систем, наприме] текстовые процессоры или электронные таблицы. Рассмотрим, что делае пользователь, работая с приложением.

1.1.1. Действия пользователя при работе с приложением

Оторвитесь на минутку от книги, выберите любое приложение (только н Web-браузер) и попытайтесь оценить, какие варианты взаимодействия с поль зователем оно обеспечивает. Мы выбрали для этой цели электронные таб лицы, но вы можете использовать другое приложение, например текстовьи процессор.

Готово? Тогда давайте обсудим вновь приобретенный опыт. Попытавшие] ввести несколько простых формул, мы обнаружили, что сделать это можн< различными способами, например, редактировать текст в строке, активизиро вать пункты меню либо изменять данные, перетаскивая их с помощью мыши

Впроцессе работы осуществляется обратная связь, т.е. приложение обес печивает отклик на действия пользователя. Вид курсора мыши изменяется кнопки подсвечиваются, цвет выбранного текста изменяется, внешний вщ активизированных окон отличается от неактивных и т.д. (рис. 1.1). Именш такое поведение характерно для богатого взаимодействия. Так что же, про грамма поддержки электронных таблиц является богатым клиентом? Позво лим себе не согласиться с этим утверждением.

Вэлектронных таблицах и других подобных приложениях модель дан ных и логика их обработки функционируют в закрытой среде. Они могут бе: ограничений обращаться друг к другу, но внешний мир недоступен для них (рис. 1.2). Клиент же — это программа, которая взаимодействует с различ ными не зависящими один от другого процессами, выполняемыми обычно на стороне сервера. Традиционно сервер — это более масштабное приложение чем клиент. Обычно он обеспечивает хранение больших объемов информации

иуправление ими. Клиент позволяет конечному пользователю просматриват!

имодифицировать данные. Если с сервером одновременно взаимодействуют несколько клиентов, он обеспечивает разделение данных. На рис. 1.3 условие показана архитектура клиент/сервер.

Всовременной n-связной архитектуре сервер взаимодействует с другими серверными программами, которые ориентированы, например, на поддержку базы данных или на выполнение специальных вычислений. Таким образом можно выделить средства промежуточного уровня, которые могут работать

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

36 Часть I. Новый взгляд на Web-приложение

Рис. 1.1. Приложение, управляющее электронными таблицами, иллюстрирует различные варианты взаимодействия с пользователем. Заголовки строк и столбцов подсвечиваются, внешний вид кнопки изменяется при помещении на нее курсора мыши, на панели инструментов отображаются различные пиктограммы, а ячейки таблицы позволяют редактировать содержащиеся в них данные

Рис. 1.2. Архитектура приложения, предназначенного для выполнения в рамках настольной системы. Прикладная программа представляет собой отдельный процесс, в пределах которого модель данных и логика их обработки могут взаимодействовать друг с другом. Если на компьютере одновременно запущены два приложения, то ни одно из них не имеет доступа к модели данных другого. Взаимодействовать друг с другом они могут только посредством файловой системы. Обычно состояние программы определяется содержимым некоторого файла. На время работы этот файл блокируется, не позволяя приложениям обмениваться информацией о состоянии

Глава 1. Каким должен быть Web-интерфейс 37

Рис. 1.3. Системы клиент/сервер в составе n-связной архитектуры. Сервер предоставляет разделяемую модель данных, с которой могут взаимодействовать клиенты. Для быстрого доступа каждый клиент поддерживает собственную частичную модель данных, которая синхронизирована с моделью, находящейся на сервере. Модель на стороне клиента по сути является альтернативным представлением бизнес-объектов. С сервером могут одновременно взаимодействовать несколько клиентов, при этом осуществляется избирательная блокировка. На время работы сданными одного

клиента другим запрещается доступ к некоторым объектам или записям базы данных. Сервер может быть реализован как единый процесс (такой подход преимущественно применялся до середины 1990-х годов) или включать несколько промежуточных уровней, поддерживать различные Web-службы и т.д. В любом случае с точки зрения клиента сервер предоставляет единую точку входа и может рассматриваться как "черный ящик"

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

Web-браузер несомненно является клиентом. Обращаясь к Web-серверу, браузер запрашивает у него тот или иной документ. Как правило, браузеры реализуют обширный набор функций, обеспечивающих просмотр Webстраниц. Например, пользователю доступны кнопка для возврата к предыдущему документу, список предыстории и фреймы, позволяющие отображать несколько документов. Однако мы считаем приложением набор страниц, расположенных на конкретном Web-узле, поэтому универсальные средства, предоставляемые браузером, связаны с приложением не больше, чем кнопка Start (пуск) в системе Windows, посредством которой мы раскрываем меню и запускаем программу поддержки электронных таблиц.

Рассмотрим современное Web-приложение. В качестве примера выбран узел Amazon (рис. 1.4), так как он знаком практически всем. Мы обратились к узлу Amazon посредством браузера. Поскольку сервер имеет информацию

38 Часть I. Новый взгляд на Web-приложение

Рис. 1.4. Исходная страница Amazon. com. Система имеет информацию о предыдущем визите, поэтому для навигации предложены различные ссылки: как общие для всех, так

иориентированные на конкретного пользователя

онашем прошлом визите, мы видим приветствие, список рекомендованных книг и сведения о предыдущих покупках.

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

Короче говоря, нам предоставлена разнообразная информация, элементы которой тесно связаны между собой. Чтобы получить доступ к этой информации, следует щелкать на гипертекстовых ссылках и заполнять формы. Если в процессе просмотра узла Amazon вы вздремнете за клавиатурой, то не узнаете, вышла ли новая книга о Гарри Поттере, до тех пор, пока не обновите Web-страницу в окне браузера. К сожалению, мы не можем перенести список рекомендованных книг с одной страницы на другую и изменить порядок следования текстовых фрагментов.

Вэтом нельзя обвинять специалистов Amazon, так как они проделали большую работу. Но по сравнению с электронными таблицами модель взаимодействия, на которой основаны данные документы, безусловно ограничена.

Глава 1. Каким должен быть Web-интерфейс 39

Рис. 1.5. Подробная информация о книге, предоставляемая Amazon. com. На странице имеются как универсальные ссылки, так и ссылки, предназначенные для конкретного пользователя. Здесь можно найти многие элементы, которые были показаны на рис. 1.4. Для того чтобы пользователь мог с помощью Web-браузера выполнять необходимые операции

с документом, эти элементы должны отображаться на каждой странице

Почему же подобные ограничения присущи всем современным Webприложениям? Они обусловлены техническими причинами, которые мы сейчас рассмотрим.

1.1.2. Накладные расходы при работе в сети

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

Однако вызов удаленных и локальных процедур — это не одно и то же. Взаимодействие по сети связано с накладными расходами, а порой оно оказывается медленным и ненадежным. При выполнении скомпилированной программы или при интерпретации исходного текста без обращения к сети коды методов и функций располагаются в той же локальной памяти, что и данные, которые они обрабатывают (рис. 1.6). При передаче данных методу и получении результатов трудности не возникают.

•О Часть I. Новый взгляд на Web-приложение

Рис. 1.6. Диаграмма, иллюстрирующая вызов локальной процедуры. В процессе вызова участвует небольшое число элементов, поскольку модель данных и логика их обработки хранятся в локальной памяти и могут непосредственно взаимодействовать друг с другом

Рис. 1.7. Диаграмма, иллюстрирующая вызов удаленной процедуры. Программная логика на одном компьютере обращается к модели данных на другом компьютере

При работе в сети на обоих концах соединения выполняется большой бъем работы, скрытой от пользователя (рис. 1.7). Порой эти вычисления амедляют работу программы даже больше, чем пересылка данных по лини- м связи. Процесс сетевого взаимодействия включает в себя решение самых азнообразных задач: передачу электрических сигналов по проводам (или пеесылку радиосигналов через спутник), представление этих сигналов в виде

.воичных данных, проверку на наличие ошибок и организацию повторной ередачи, восстановление битовой последовательности и, наконец, интерпреацию двоичной информации.

Глава 1. Каким должен быть Web-интерфейс 41

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

На удаленном компьютере данные, полученные посредством протокола прикладного уровня, десериализуются, в результате чего формируется копия объекта запроса. Этот объект передается модели данных, которая генерирует объект ответа. Для передачи ответа вызывающей функции снова задействуются механизм сериализации и транспортные средства; в результате объект доставляется вызывающей функции.

Процесс такого взаимодействия сложен, но его можно автоматизировать. Современные инструменты программирования, например Java или Microsoft

.NET Framework, обеспечивают это. Тем не менее при удаленном вызове процедуры (RPC) реально выполняется большой объем вычислений, и если такие обращения будут производиться слишком часто, производительность системы снизится.

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

Но какое отношение это имеет к работе пользователя, которому предоставляется лишь интерфейс программы? Оказывается, очень большое.

Хороший интерфейс должен в чем-то имитировать реальный мир. А в большинстве случаев на действия в реальном мире следует немедленный отклик. Даже небольшая задержка между действием и реакцией на него сбивает с толку пользователя, отвлекает его от решаемой задачи и заставляет переключить внимание на особенности самого интерфейса.

Дополнительные вычисления, связанные с передачей по сети, часто так замедляют работу, что задержка становится заметной. Для обычных приложений, предназначенных для выполнения на настольных системах, малая практичность является следствием неправильных решений, принятых при разработке. В случае сетевого соединения мы получаем тот же результат автоматически.

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

42 Часть I. Новый взгляд на Web-приложение

Рис. 1.8. Диаграмма, поясняющая синхронный ответ на действия пользователя. В качестве примера выбрана утренняя побудка детей. Время на диаграмме откладывается по вертикальной оси. Серым цветом выделен период, в течение которого деятельность родителей приостанавливается

1.1.3. Асинхронное взаимодействие

Решить проблему задержки, связанной с передачей данных по сети, разработчик может единственным образом — предположить наихудшее развитие событий. На практике это означает, что надо создавать пользовательский интерфейс так, чтобы он не зависел от сетевого взаимодействия. К счастью, в некоторых случаях проблемы, вызванные задержкой отклика, можно сделать менее острыми. Рассмотрим пример из реального мира. Всем родителям приходится отправлять по утрам детей в школу. Можно стать над ними и дожидаться, пока они не встанут из постелей и не оденутся. На это уходит много времени (рис. 1.8).

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

Глава 1. Каким должен быть Web-интерфейс 43

Рис. 1.9. Диаграмма, иллюстрирующая асинхронный ответ на действия пользователя. Следуя асинхронной модели ввода, родитель, подав сигнал побудки, предоставляет детям просыпаться самостоятельно и оповестить его об окончании этого процесса. В это время он продолжает заниматься другими делами; при этом время, непосредственно потраченное на побудку детей, существенно сокращается

Возвращаясь к компьютерной тематике, сказанное означает выполнение действий в асинхронном режиме. Для этой цели используется отдельный поток. Снова пользуясь примером из реального мира, можно сказать, что дети будут просыпаться сами "в своем потоке", а родителю не придется синхронизировать с ними свои действия до тех пор, пока он не узнает, что дети проснулись (т.е. пока они на захотят завтракать). После этого родителю придется взаимодействовать с детьми, так как, получив уведомление, он узнает, что дети проснулись и оделись (рис. 1.9).

Любой достаточно квалифицированный разработчик пользовательского интерфейса знает, что длительные вычисления лучше производить в отдельном потоке в фоновом режиме; в это время пользователь может выполнять другие действия. Конечно, на определенное время, необходимое для запуска потока, пользовательский интерфейс будет заблокирован, но это время очень мало. Учитывая неизбежную задержку при сетевом взаимодействии, имеет смысл априори считать любой вызов удаленной процедуры длительной операцией и выполнять ее асинхронно.

Проблема четко сформулирована, и решение ее известно. Задержки, связанные с обменом по сети, играли роль в ранних приложениях клиент/сервер. Созданные неопытными разработчиками, клиенты "зависали" на неопределенное время при попытке доступа к серверу, занимавшемуся обработкой большого числа запросов. Теперь, в эпоху Интернета, те же причины заставляют браузер временно останавливаться при переходе от одной Web-