Крейн Д., Паскарелло Э., Джеймс Д,. AJAX в действии / Ajax в действии / ajinact / Ajax в действии

186 Часть 11. Основные подходы к разработке приложений

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

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

Помимо рассмотрения общих вопросов, связанных с работой приложения, мы также уделим внимание деталям взаимодействия клиента и сервера. В главе 2 вы получили основные сведения об объекте XMLHttpRequest

искрытых фреймах. В данной главе мы вернемся к этому вопросу и обсудим использование различных образов разработки для передачи данных клиенту

ивыясним, есть ли альтернатива разбору XML-документов с применением методов DOM. В последнем разделе мы представим систему управления трафиком, связанным с обменом между клиентом и сервером в процессе работы приложения. На стороне клиента будет находиться очередь запросов, а на стороне сервера — процессы для их обработки.

Итак, рассмотрим роль сервера в Ajax-приложении.

5.1. Программы, выполняемые на сервере

В процессе работы Ajax-приложения сервер выполняет две основные функции, которые имеют существенное отличие. Прежде всего, он доставляет приложение браузеру. Мы считаем, что в процессе доставки данные не претерпевают изменения, поэтому реализуем средства, предназначенные для выполнения на стороне клиента, как набор файлов .html, .ess и . js. С передачей их клиенту справится даже самый простой сервер. Такое решение вполне жизнеспособно, но оно не единственное. Существуют альтернативные варианты. Средства, предназначенные для создания серверных программ, мы подробно обсудим в разделе 5.3.

Вторая задача сервера — это взаимодействие с клиентом, т.е. обработка запросов и подготовка ответов. Поскольку HTTP — единственный возможный в данной ситуации транспортный механизм, взаимодействие всегда должно начинаться по инициативе клиента. Сервер может только отвечать. В главе 4 мы говорили о том, что Ajax-приложение должно поддерживать модель предметной области как на стороне клиента (для обеспечения быстрого отклика), так и на стороне сервера (для доступа к ресурсам, например, к базе данных). Синхронизация этих моделей — сложная задача, и клиент без по-

Глава 5. Роль сервера в работе Ajax-приложения 187

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

Прочитав данную главу, вы узнаете, что доставить приложение клиенту

иорганизовать взаимодействие с ним можно различными способами. Существует ли наилучшее решение? Можно ли обеспечить взаимную поддержку? Как различные решения будут работать с уже имеющимся программным обеспечением? Чтобы ответить на эти вопросы, необходимо описать возможности, имеющиеся в нашем распоряжении. Это мы постараемся сделать в данной главе. Рассмотрим варианты участия сервера в работе Web-приложения

иособенности, связанные с применением инфраструктуры Ajax.

5.2.Создание программ на стороне сервера

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

5.2.1.Популярные языки программирования

Для создания программного обеспечения, предназначенного для выполнения на стороне сервера, могут использоваться различные языки. Несмотря на то что вся история всемирной сети очень коротка, отношение разработчиков к тем или иным языкам программирования не раз изменялись. В настоящее время чаще всего используются PHP, Java и классическая технология ASP; также становятся все более популярными ASP.NET и Ruby. Эти названия, конечно же, знакомы большинству читателей. Ajax имеет дело преимущественно с клиентским программным обеспечением, которое может взаимодействовать с серверными программами, написанными на любом из этих языков. Более того, при использовании Ajax не столь важно, какой именно язык применялся при создании серверных программ. В результате упрощается перенос Ajax-приложений с одной платформы на другую.

Часто базовые средства, используемые при написании серверной части Ajax-приложения, становятся более важными, чем язык реализации. Архитектура и базовые средства определяют структуру приложения и функции его основных компонентов. Для создания классических Web-приложений были разработаны различные архитектуры, однако поскольку жизненный цикл Ajax-приложений отличается от классического варианта программ, не все архитектуры оказываются пригодными. Вопросы разработки серверных программ и используемые при этом средства описаны далее в этой главе, а сейчас Мы рассмотрим базовые принципы Web-архитектуры.

188 Часть II. Основные подходы к разработке приложений

5.2.2. N-уровневые архитектуры

Одним из основных понятий, используемых при разработке распределенных приложений, является уровень (tier). С одной стороны, уровень определяет круг вопросов, за решение которых отвечает приложение, а с другой — описывает изолированную подсистему, работающую на отдельной машине либо оформленную в виде отдельного процесса. Этим понятие уровней отличается от понятия ролей в архитектуре MVC. Модель, представление и контроллер не являются уровнями, поскольку они реализованы в рамках одного процесса.

Первые распределенные системы насчитывали два уровня — клиентский

исерверный. Уровень клиента обычно располагался на настольной системе

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

Первые системы Web включали браузер, взаимодействующий с Webсервером. Сервер обычно отвечал за передачу браузеру файлов, находящихся в файловой системе серверной машины.

По мере развития и усложнения Web-приложений потребовался доступ к базам данных. Двухуровневая модель "клиент/сервер" уступила место трехуровневой модели, в которой сам Web-сервер занял место промежуточного уровня между клиентом и СУБД. Дальнейшее развитие привело к выделению на промежуточном уровне средств представления и бизнес-логики. Они реализовывались либо в виде отдельных процессов, либо как модули в составе одной программы.

Современное Web-приложение обычно имеет два основных уровня. Уровень бизнес-логики моделирует предметную область и непосредственно взаимодействует с базой данных. Уровень представления получает данные от средств бизнес-логики и представляет их пользователю. Браузер занимает

вэтой системе место низкоуровневого клиента.

Споявлением Ajax стал развиваться клиентский уровень. Если ранее средства представления полностью отвечали за поддержку работы пользователя, то сейчас их функции разделились между сервером и клиентом (рис. 5.1). Роль уровня представления на стороне сервера стала менее важной, поскольку некоторые вопросы обеспечения последовательности действий при работе пользователя полностью решаются на уровне клиента. Соответствующие программные средства создаются на языке JavaScript и работают

всреде браузера.

Этот новый уровень предоставляет новые возможности, которые мы уже обсуждали в предыдущих главах. Однако вместе с тем он создает предпосылки для усложнения программ, в результате чего при разработке могут возникать дополнительные проблемы. Нам надо знать, как справиться с ними.

Глава 5. Роль сервера в работе Ajax-приложения

189

Web-браузер

Web-сервер

Сервер баз данных

Рис. 5.1. В Ajax-приложении некоторые функции уровня представления переместились со стороны сервера на сторону клиента. В результате возник новый уровень — клиентский уровень представления

5.2.3. Управление моделью предметной области на стороне клиента и на стороне сервера

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

Добавление дополнительного уровня всегда связано с увеличением сложности и возрастанием накладных расходов при взаимодействии. К счастью, данная проблема не нова. Аналогичные трудности возникали при разработке Web-приложений средствами J2EE, где были строго разделены уровень бизнес-логики и уровень представления. Модель предметной области поддерживается средствами бизнес-логики. К ней обращается уровень представления, на котором затем генерируется содержимое Web-страниц, передаваемых браузеру. В J2EE проблема была решена путем применения объектов передачи (transfer objects), которые представляют собой обычные объекты, передаваемые между уровнями. Они представляют уровню представления ограниченный доступ к модели предметной области.

Однако Ajax ставит новые задачи. При использовании технологии J2EE оба уровня реализовывались на одном и том же языке. Более того, в распоряжении разработчика был механизм удаленных процедур. При создании приложения Ajax такие условия, как правило, обеспечить невозможно. В принципе можно применить для'написания программ на стороне сервера язык JavaScript, однако такой подход нельзя назвать общепринятым, да и к тому же остается задача взаимодействия двух JavaScript-программ.

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

190 Часть II. Основные подходы к разработке приложений

Согласно данным исследований (ссылка на соответствующий обзор приведена в конце данной главы) в настоящее время только для Java существует более 60 вариантов базовых средств разработки (по правде говоря, такое обилие предложений скорее мешает, чем помогает в работе). Большинство из них различается лишь в деталях, и, независимо от языка реализации серверных программ, мы можем выделить для уровня представления несколько основных архитектурных принципов. Рассмотрим их.

5.3. Принципы создания программ на сервере

Базовые средства, применяемые для разработки программ на стороне сервера, важны для Ajax-приложений. Если код клиента генерируется на базе модели, поддерживаемой на сервере, их значение еще более возрастает. Если мы вручную создадим код клиента и оформим его в виде статических HTMLдокументов, содержащих JavaScript-код, то базовые средства не будут участвовать в доставке приложения, но данные, требуемые приложению в процессе работы, по-прежнему должны генерироваться динамически. Как было сказано ранее, программы на стороне сервера обычно разделяются на два уровня: модель предметной области и представление. В случае Ajах-приложения средства представления выполняют роль посредника между моделью и клиентской частью. Для того чтобы приложение работало эффективно, надо правильно организовать взаимодействие клиента и сервера, а для этого необходимо знать архитектуру серверных программ и, возможно, инструменты, применявшиеся при их создании.

Некоторые всерьез считают сервер в составе Web-приложения игрушкой в руках разработчика. Проблема поддержки работы пользователя посредством набора Web-страниц и обращения к другим системам на сервере, например СУБД, еще не решена по-настоящему. Web буквально наводнена неудачными системами и утилитами, а новые проекты появляются каждый месяц,

ато и каждую неделю.

Ксчастью, среди этих разнообразных проектов можно выделить группы со сходными характеристиками. Анализируя основные подходы, можно описать четыре основных способа решения задач, поставленных перед сервером. ] Рассмотрим их и выясним, подходят ли они для нашей Ajax-модели.

5.3.1. Серверные программы, не соответствующие основным принципам разработки

Самая простая архитектура — это отсутствие таковой. Создание приложения без учета основных принципов разработки не обязательно означает отсутствие порядка. Возможно, в приложении будут удачно определены основные этапы работы пользователя и организовано обращение к ресурсам. Многие Web-узлы созданы именно таким образом. Каждая страница генерирует свое собственное представление и по-своему обращается к базе данных и другим системам. Во многих случаях при создании подобных приложений применяются библиотеки и вспомогательные функции. Приложение, созданное подобным образом, условно показано на рис. 5.2.

Глава 5. Роль сервера в работе Ajax-приложения 191

Web-браузер

Сервер баз данных

Рис. 5.2. Web-программа, созданная без учета основных принципов разработки. Каждая страница, сервлет или CGI-сценарий поддерживает собственную логику и особенности представления данных. Вспомогательные методы и объекты могут инкапсулировать низкоуровневые функции общего назначения, например обращение к базе данных

Применить данный подход для Ajax-приложения достаточно просто, при условии, что код клиента создается вручную. Генерация клиентской программы сервером — сложная задача, и ее рассмотрение выходит за рамки данной книги. Для доставки клиента надо определить основную страницу, содержащую JavaScript-код, таблицы стилей и другие ресурсы. Для доставки данных нам надо лишь заменить HTML-документы, генерируемые сервером, XMLданными или информацию в другом формате.

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

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

192 Часть II. Основные подходы к разработке приложений

Web-браузер

Представление/ Web-страницы

Сервер баз данных

Рис. 5.3. Архитектура Model2. Единственная страница контроллера или единственный сервлет получает все запросы и распределяет их в соответствии со схемой работы пользователя. Запрос может быть передан для обработки

вспомогательным классам или функциям и перед пересылкой браузеру передается компоненту, выполняющему роль представления (например, JSPили РНР-документу)

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

5.3.2. Использование архитектуры Model!

Образ разработки Model2 является разновидностью MVC. Отличается он тем, что контроллер имеет единственную точку входа и единственное определение последовательности действий пользователя. В применении к Webприложению это означает, что одна страница контроллера или один сервлет отвечает за маршрутизацию большинства запросов, передавая их различным службам и пересылая полученные данные представлению. Среди базовых наборов средств, поддерживающих Model2, наиболее известным является Apache Struts. Данной архитектуре также соответствует ряд других инструментов для Java и РНР. На рис. 5.3 условно показано Web-приложение, соответствующее архитектуре Model2

Как же применить данный принцип разработки к серверному приложению, взаимодействующему с клиентом Ajax? Model2 практически никак не определяет доставку клиентского приложения, потому что обычно она производится в начале работы и выполняется практически одинаково для всех пользователей. Централизованный контроллер может участвовать в процессе аутентификации, однако этот факт не влияет на доставку.

Глава 5. Роль сервера в работе Ajax-приложения 193

Данная архитектура хорошо подходит для доставки данных. Представление, созданное в рамках архитектуры Model2, практически не зависит от базовых средств, и мы можем без труда заменить HTML на XML или другой формат. Часть функций контроллера передается уровню клиента, но другие функции реализуются на стороне сервера посредством отображения.

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

5.3.3. Использование архитектуры на базе компонентов

При создании HTML-страницы для классического Web-приложения в распоряжении автора имеется ограниченный набор компонентов пользовательского интерфейса — обычно этот набор исчерпывается элементами HTMLформы. Их возможности остаются неизменными уже около десяти лет, и они существенно проигрывают современным инструментам, предназначенным для создания интерфейсов. Если автор захочет реализовать нечто вроде древовидной структуры или таблицы с редактируемыми ячейками, он вынужден будет заняться низкоуровневым программированием. Это не идет ни в какое сравнение с уровнем абстракции, доступным разработчику, создающему программы для настольной системы и имеющему в своем распоряжении такие инструменты как MFC, GTK+, Cocoa, Swing или Qt.

Компоненты для Web

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

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

194 Часть II. Основные подходы к разработке приложений

Web-браузер

Рис. 5.4. Архитектура, основанная на использовании компонентов. Приложение описывается как набор компонентов, для воспроизведения которых браузеру передается поток HTML-данных и JavaScript-программ Каждый компонент содержит собственные "микрореализации" модели, представления и контроллера. Контроллер более высокого уровня обрабатывает запросы браузера к отдельным компонентам и модели предметной области

в ответ на действие пользователя. В "интеллектуальных" архитектурах обработка событий осуществляется незаметно для пользователя, а в других при возникновении каждого события обновляется вся страница. Как правило, в приложениях, созданных в виде набора компонентов, взаимодействие с сервером осуществляется более эффективно по сравнению, например, с приложениями Model2.

Одна из целей, преследуемых архитектурой, о которой идет речь, — это формирование различных типов пользовательского интерфейса на базе единого описания. Некоторые наборы базовых средств, например Windows Forms для .NET или JSF (JavaServer Faces), обеспечивают такую возможность.

Глава 5. Роль сервера в работе Ajax-приложения

195

Применимость архитектуры на базе компонентов для Ajax-приложений

Как же сочетается архитектура на базе компонентов с Ajax? На первый згляд, взаимодействие должно быть органичным, поскольку оба подхода предполагают переход от интерфейса на основе документов к использованию компонентов. Может показаться, что данную архитектуру целесообразно применять для Ajax-приложений, в особенности тогда, когда клиентские средства генерируются программой и существуют включаемые средства воспроизведения, поддерживающие Ajax. Такой подход выглядит весьма привлекательным, поскольку в этом случае исчезает необходимость специального изучения разработчиками особенностей языка JavaScript и существует возможность реализовать систему воспроизведения на базе обычного HTML-кода.

Подобное решение хорошо подходит для тех приложений, для которых требуются лишь стандартные типы компонентов. Тем не менее некоторая степень гибкости все же теряется. Успех Google Maps (см. главу 1) в значительной степени обусловлен тем, что для данной системы определен собственный набор компонентов, от прокручиваемой карты до элементов масштабирования и всплывающей подсказки. Реализовать ту лее систему, используя стандартный набор компонентов, типичных для настольной системы, было бы гораздо сложнее, и конечный результат наверняка получился бы гораздо худшим.

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

Для того чтобы архитектура была пригодной для Ajax-приложения, она должна обеспечивать эффективную передачу данных в процессе работы. Здесь проблемы могут оказаться более серьезными, так как контроллер жестко "привязан" к уровню сервера и определен с помощью выразительных средств, типичных для настольных систем. Для Ajax-приложения, способного обеспечивать требуемый отклик на действия пользователя, необходимо иметь возможность определять собственные обработчики событий, которую сервер не всегда может предоставить. Однако данная архитектура имеет серьезные потенциальные возможности, и по мере возрастания популярности Ajax несомненно будут появляться новые решения. Система CommandQueue, которую мы рассмотрим в разделе 5.5.3, может стать существенным шагом по пути применения JSF и других подобных технологий, однако на сегодняшний день она еще не готова. Имеющиеся же в наличии базовые средства не предоставляют клиентам той свободы, которую хотелось бы видеть.

Будущее покажет, насколько хорошо удастся адаптировать системы на базе компонентов для Ajax. В настоящее время наблюдается рост интереса со стороны корпорации Sun и некоторых поставщиков JSF к инструментам, созданным с учетом Ajax. Поддержка некоторых функций, применимых для Ajax, уже реализована в .NET Forms; они также будут доступны в наборе инструментальных средств Atlas. (Ссылки на эти системы приведены в конЦе главы.)