Алик Кириллович

«Совершенный Ajax» – новый подход к построению настоящих клиент-серверных web-приложений

17 декабря 2008 г.
«Совершенный Ajax» — новый подход к построению web-приложений, при котором web-сервер не генерирует ни строчки HTML-кода и взаимодействует с внешним миром только посредством web-служб; а клиентский интерфейс реализуется только на основе клиентских HTML, CSS, JavaScript.

 

Попробуйте угадать: к какой архитектуре относятся web-приложения?

К клиент-серверной говорите? Я ожидал, что Вы так ответите…

Что ж, давайте разберёмся. В клиент-серверной архитектуре выделяют [1]:

Реализация бизнес-логики на сервере и взаимодействие с пользователем на клиенте чётко разделены.

Преимущества клиент-серверной архитектуры очевидны; мы их все знаем:

  1. Бизнес-логика не смешивается с пользовательским интерфейсом.

  2. Можно реализовать несколько клиентов с разными пользовательскими интерфейсами: интерфейс командной строки, оконный Windows-интерфейс, Flash, web-интерфейс, мобильный интерфейс и т.д.

  3. Клиентский компьютер не требователен к ресурсам;

  4. И т.д.

 

Но, относятся ли web-приложения к клиент-серверной архитектуре? Web-сервер

Действительно, в web-приложениях есть сервер, отвечающий за бизнес логику приложения.

Но! За реализацию интерфейса отвечает не клиент, а тоже сервер. На сервере происходит обработка клиентской формы. Сервер генерирует HTML-код пользовательского интерфейса.

Браузер Клиент, т.е. браузер лишь визуализирует уже готовый HTML-код интерфейса. Это, фактически, то же самое, что прицепить к серверу монитор и объявить этот монитор клиентом…

Замечание:

Здесь, правда, есть одна тонкость. Следует различать два понятия: web-приложения и систему «браузер — web-сервер». Web-приложения работают поверх браузера и web-сервера, так же как Java-приложения работают поверх JVM, приложения на .Net работают поверх .Net Framework, а протокол HTTP работает поверх TCP/IP.

Система «браузер — web-сервер» действительно имеет клиент-серверную архитектуру: web-сервер принимает и обрабатывает запросы, а браузер визуализирует результат.

Однако, здесь мы говорим не о системе «браузер — web-сервер», а о работающих поверх неё web-приложениях.

Вряд ли такой подход можно назвать полноценной клиент-серверной архитектурой. Он имеет много недостатков:

  1. Смешивание бизнес-логики и пользовательского интерфейса;

  2. Сложно реализовать несколько пользовательских интерфейсов;

  3. Сторонни программы не могут обращаться к серверу (если не написан специальный api);

  4. Большая часть нагрузки по обработке интерфейса ложится на сервер.

  5. И т.д.

Мейнфрейм Впрочем, мы знаем в истории пример подобной архитектуры. В 70-годы были распространены мейнфреймы. Мейнфрейм — такой огромный железный сундук (сервер), к которому подключались рабочие станции (клиенты). Причём, рабочая станция представляла собой просто монитор с клавиатурой. И любые действия клиента на рабочей станции обрабатывалось на сервере, порой даже такие как обработка нажатия на клавишу и обрисовка экрана [2]. Ну, мы знаем, насколько популярны мейнфреймы сегодня…

 

Конечно, в современных web-приложениях часть интерфейсной логики реализуется на клиенте с помощью JavaScript. Ajax Часть данных загружается с помощью Ajax и визуализируется именно на клиенте.

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

Так вот, я предлагаю подход «Совершенный Ajax», который призывает развить идею Ajax до логического конца и полностью отказаться от использования сервера для реализации пользовательского интерфейса web-приложений.

Подход «Совершенный Ajax» построен на следующих принципах:

«Совершенный Ajax» в нашем проекте

Опишу эту архитектуру на примере нашего проекта «Система Интерактивного Тестирования Знаний „Синтез“».

Сервер

В концепции «Севершенный Ajax» сервер должен удовлетворять одному-единственному условию: не генерировать ни строчки HTML-кода и осуществлять связь с внешним миром посредством web-служб. Во всём остальном его реализация ничем не ограничена.

Здесь я опишу структуру сервера в нашем проекте, т.к. она имеет ряд интересных особенностей: использование серверного JavaScript на платформе Mozilla Rhino, прототипно-ориентированная ORM и возможность использования SPARQL — языка запросов к Semantic Web.

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

Архитектура сервера
СУБД
СУБД
Объектное ядро бизнес-логики
Ядро бизнес-логики
Прототипно-ориентированная ORM
ORM
Web-сервер
Web-сервер

Клиент

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

Однако, оно всегда имеет в комплекте «родной» web-интерфейс.

Здесь я опишу его структуру.

Архитектура клиента
Интерфейсное ядро
Интерфейсное ядро

Интерфейсное ядро — объектно-ориентированная JavaScript-библиотека, управляющая всем клиентским web-интерфейсом:

Библиотека обёртка
Объектно-ориентированная библиотека-обёртка над web-службами
Семантическая вёрстка
Семантическая вёрстка
Библиотека контролов
Библиотека контролов

 

Подробности технической реализации подхода «Совершенный Ajax» — во второй части.

Примечания

  1. Речь идёт о клиент-серверных приложениях с конечным пользователем. В клиент-серверных приложениях вроде «клиент — сервер базы данных», пользовательский интерфейс, разумеется, отсутствует.

  2. Позже, у мейнфреймов появились так называемые «умные клиенты», которые обладали собственным процессором и памятью, а наиболее продвинутые могли даже проверить форму перед отправкой на сервер. Это очень напоминает нынешнюю робкую попытку передать часть интерфейсной логики web-приложения на клиент с помощью Ajax.

Библиотека подсветки синтаксиса в этой статье основана на «highlight.js» от Ивана Сагалаева.

См. также

Статьи

About

Подписка

  • RSS
Valid XHTML 1.0 Strict © Алик Кириллович, 2008—2015