Глава 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.1. В Ajax-приложении некоторые функции уровня представления переместились со стороны сервера на сторону клиента. В результате возник новый уровень — клиентский уровень представления

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

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

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

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

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