Глава 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-
44 Часть I. Новый взгляд на Web-приложение
страницы к другой. Мы не можем влиять на задержку, связанную с взаимодействием по сети, но можем минимизировать ее влияние, обращаясь к удаленным методам в асинхронном режиме.
К несчастью, нам, разработчикам Web-приложений, не так-то просто следовать этим давно известным рекомендациям. Протокол HTTP действует по принципу "запрос-ответ". Клиент передает запрос на получение документа, а сервер отвечает, либо предоставляя требуемые данные, либо информируя о том, что он не может их найти, либо предлагая перейти по другому адресу, либо сообщая клиенту, что тот может использовать копию, содержащуюся в кэше. Протокол, в котором предусмотрено лишь взаимодействие "запросответ", является в некотором смысле "односторонним". Клиент может обратиться к серверу, но сервер по своей инициативе не может установить взаимодействие с клиентом. Более того, в промежутке между двумя последовательными запросами сервер даже не имеет сведений о клиенте.
Большинство разработчиков Web-приложений используют современные технологии, такие как Java, PHP или .NET, поскольку в них поддерживается сеанс взаимодействия. Мысль о том, что неплохо бы реализовать в серверах поддержку текущего состояния процесса взаимодействия с клиентами, пришла слишком поздно. Протокол HTTP очень хорошо выполняет те задачи, для которых он был изначально разработан, но адаптировать его для решения вопросов, которые не были предусмотрены создателями данного протокола, крайне сложно. Однако при асинхронном обращении к удаленному методу клиент должен быть оповещен дважды: при порождении потока и при его завершении. Для протокола HTTP и классических Web-приложений эта задача неразрешима.
Основой классической модели Web-приложения, подобной той, которая используется на сервере Amazon, является Web-страница. Документ, отображаемый в окне браузера, содержит набор гипертекстовых ссылок и формы, позволяющие переходить к другим документам и посылать серверу данные. Такой подход позволяет взаимодействовать с базами данных большого объема. Специалисты Amazon и других компаний накопили немалый опыт создания таких приложений и показали, что их вполне можно применять в серьезных проектах.
В процессе многолетней работы с Интернетом большинство из нас привыкли к описанной модели взаимодействия и не представляют себе альтернативы. Инструменты разработки с интерфейсом WYSIWYG формируют Webузел в виде набора Web-страниц. Переход от одной страницы, расположенной на сервере, к другой можно представить в виде диаграммы изменения состояния. Классическим Web-приложениям изначально присущи недостатки, связанные с получением отклика, и прибегнуть к асинхронной обработке не представляется возможным.
Однако компания Amazon, и не она одна, используя свой узел, успешно строит бизнес. Поэтому классические Web-приложения нельзя однозначно считать непрактичными. Чтобы понять, почему Web-страницы выполняют свои функции на сервере Amazon, а для других целей могут оказаться неприменимыми, рассмотрим различные образы использования.