1.3 Аналоги
На данный момент существует несколько реализаций web-серверов с продолжениями. Все они реализованы на языках, изначально поддерживающие продолжения – Scheme, Lisp, SmallTalk и т.д., которые не являются на сегодняшний день основными языками разработки web-приложений. Из языков программирования, поддерживающих продолжения и ориентированных на Web, можно выделить только Ruby, который в настоящее время используется практически исключительно в связке со средой разработки Rails и обладает довольно медленным интерпретатором.
1.3.1 Seaside
Seaside является безусловным лидером по имеющейся функциональности, на него мы и будем ориентироваться. В качестве языка программирования используется SmallTalk. Он предоставляет набор абстракций от HTTP и HTML, позволяющий создавать интерактивные web-приложения, как отмечают создатели, быстро и масштабируемо. Кроме того, Seaside использует компонентную модель, дающую большие возможности для повторного использования кода.
В Seaside используется программная генерация HTML. По мнению создателей, это обусловлено тем, что разметка HTML-страниц является стереотипной. Данная среда разработки предлагает широкое API для генерации HTML. Кроме того, Seaside поддерживает и шаблоны.
Seaside позволяет абстрагироваться от GET и POST благодаря использованию «обратных вызовов» (англ. callbacks) для параметров получаемых от клиента. Таким образом, новые значения для переменных заполняются «на лету» прямо из запроса.
Seaside реализует компонентный подход для обработки и представления данных на странице. Таким образом, страница представляет собой дерево компонент, каждая из которых инкапсулирует в себе небольшую часть страницы и оригинальной логики, что позволяет использовать созданные компоненты вновь и вновь.
И, наконец, Seaside позволяет реализовывать сложные, многостраничные функции в одном методе. Использование продолжений дает возможность сохранять состояние приложения между двумя HTTP-транзакциями и отказаться от отслеживания действий пользователя, не предусмотренных интерфейсом приложения.
1.3.2 Apache Cocoon 2.1
Apache Cocoon – это среда разработки, в основу которой положена трансформация XML-документа. Эта среда разработки использует модель каналов (англ. pipelines): входной XML-документ подвергается последовательной трансформации, и в результате клиенту возвращается документ в любом формате (HTML, PDF, SVG). Кроме того, в основе Apache Cocoon лежит использование компоненты[5].
Отправной точкой канала трансформаций является Generator, отвечающий за передачу SAX-событий дальше по каналу. Transformer-ы подобны XSL-преобразованиям: получая на входе XML-документ (или набор SAX-событий), они генерируют другой XML-документ (или набор SAX-событий). Выходной точкой канала является Serializer, в обязанности которого входит представление данных в нужном виде. Таки образом достигается разделение содержания, логики и представления в Apache Cocoon.
Apache Cocoon взаимодействует с большинством источников данных: с файловой системой, RDBMS, LDAP, базами данных в формате XML и сетевыми источниками данных. Эта среда разработки предоставляет удобную функциональность для представления результата на различных устройствах в формате HTML, WML, PDF, SVG, RTF и других.
Apache Cocoon также позволяет программировать логику в обычном потоке команд, возвращая ответ клиенту и получая от него данные в любом месте приложения. Для описания потока выполнения Apache Cocoon использует интерпретатор JavaScript, модифицированный для поддержки продолжений.
2 Web-разработка, основанная на продолжениях
2.1 Базовая концепция
Разработка web-приложений на основе продолжений позволяет аккуратно обойти проблемы традиционных подходов. В отличие от MVC такие web-приложения пишутся как единая программа в традиционном для «настольных» приложений стиле. Каждый раз, когда приложение ждет данных от пользователя, система сохраняет продолжение, содержащее оставшуюся часть бизнес-логики и уже введенные данные, и возвращает пользователю страницу, содержащую форму для ввода данных и идентификатор сохраненного продолжения.
Пользователь вводит данные и отправляет запрос серверу, содержащий идентификатор продолжения. Система извлекает из запроса наряду с остальными данными этот идентификатор, извлекает по нему сохраненное продолжение и возобновляет его (т.е. логика приложения начинает исполняться со строки кода, следующей сразу за той, в которой создано продолжение). Обычно, в первых строках продолжения извлекаются остальные данные, отправленные пользователем, что означает, что объект запроса должен быть доступен в этот момент (либо возвращаться функцией, отправляющей страницу и создающей продолжение, либо быть доступным через интерфейс, предоставляемой системой (англ. API – Application Programming Interface). Затем продолжается выполнение бизнес логики с полученными данными.
После возобновления продолжения логике продолжения могут потребоваться еще данные от пользователя, что потребует дальнейшего взаимодействия. Это выполняется путем создания второго продолжения, сохранение его в системе и отправки пользователю формы, содержащей идентификатор продолжения. Сгенерированные продолжения можно представить в виде дерева, где родительский узел – это первое продолжение, дочерний – второе. Точно так же, если дальнейшая бизнес-логика реализуется в соответствии с некоторым условием, в коде могут порождаться два различных продолжения, соответствующие, возможно, различным формам, отправленным пользователю, которые станут дочерними для первого продолжения. Таким образом, весь код приложения может рассматриваться как соответствующее «дерево продолжений» (или «лес продолжений»).
Внешне для пользователя web-приложение, реализованное с подходом, основанном на продолжениях, может не иметь никаких различий с приложением, написанных с традиционным подходом. Пользователь может вернуться к предыдущей странице, изменить введенные значения и отправить ее снова. Разница существенна в коде, необходимом для того, чтобы подобные действия работали корректно. При использовании продолжений не требуется никаких других усилий, потому что идентификатор продолжения всегда присутствует в запросе – серверу необходимо лишь извлечь соответствующее продолжение и возобновить его. Это означает, что текущее состояние системы идентифицируется не программой-клиентом, конкретным представлением, содержащим идентификатор продолжения.
Предположим, пользователь просматривает страницу. С точки зрения так называемого «дерева продолжений», эта страница «помечена» определенным «узлом продолжения». Если пользователь нажмет кнопку «Назад», чтобы вернуться к предыдущей странице, «маркер» в «дереве продолжений» передвинется на уровень вверх (см. Рисунок 8). Это передвижение вверх по «дереву продолжений» будет происходить всегда, когда пользователь нажимает кнопку «Назад». Теперь предположим, что пользователь, вернувшись на несколько шагов назад, ввел данные, которые могут совпадать или не совпадать с ранее введенными на этом шагом данными, и отправил форму снова. В результате этой операции создастся новый «узел продолжения», родительским для которого будет текущий. Таким образом, происходит ответвление, и пользователь, продолжив взаимодействие с системой, которая вызовет тот же, а может и другой, набор продолжений в зависимости от данных, введенных пользователем.
Рисунок 8. Пример «дерева продолжений»
Таким же в точности образом обрабатывается клонирование хода работы приложения в новом окне: клонированная страница «помечена» тем же «узлом продолжения», что и исходная, но после отправки данных следующие продолжения (возможно содержащие различные наборы данных) будут сохранены с разными идентификаторами – получаются две ветки в «дереве продолжений».
Важным моментом при реализации системы, поддерживающей такой подход, является организация хранения и управления продолжениями. Самым простым способом является хранение в глобальном ассоциативном массиве с уникальными ключами для хранимых продолжений. Но при таком подходе не исключается тот случай, когда злоумышленник может завладеть продолжением добросовестного пользователя, подобрав соответствующий ему идентификатор. С целью избежать таких нежелательных явлений, имеет смысл хранить «дерево продолжений» в пользовательской сессии. С другой стороны появляется необходимость реплицировать хранилище продолжений при создании распределенных систем. Кроме того, необходимо учесть то, что некоторые продолжения так и не будут возобновлены (пользователь закрыл браузер) – их необходимо удалять из хранилища. Для этой цели необходимо связать с каждым продолжением параметр, определяющий «время жизни» продолжения (англ. TTL – time-to-live).
Идентификатор продолжения рекомендуется размещать прямо в коде возвращенной страницы (в скрытом поле или атрибуте «action» формы и в ссылках). Не рекомендуется сохранять идентификатор продолжения средствами браузера (cookies), потому что установленные cookie доступны и одинаковы для всех клонов приложения браузера.
|
