3.4 Сервер приложений
Для использования возможностей web-разработки с использованием продолжений в рамках проекта был реализован многопроцессный HTTP-сервер. Выбор в пользу многопроцессного сервера был сделан по причине того, что интерпретатор Python обладает немалым количеством ошибок, которые проявляются при работе с потоками. Это делает работу с потоками в Python не только сложной, но и опасной.
Одной из главных проблем многопотокового программирования как в Python, так и в Stackless, является GIL (от англ. Global Interpreter Lock – «глобальная блокировка интерпретатора»). При своей работе Python использует большое количество потоково-небезопасных данных. Во избежание разрушения этих данных при совместной модификации из разных потоков перед началом исполнения нескольких инструкций поток интерпретатора захватывает GIL, а по окончанию – освобождает. Вследствие этой особенности в каждый момент времени может исполняться только один поток Python кода, даже если на компьютере имеется несколько процессоров или процессорных ядер. Поэтому для параллельного исполнения нескольких потоков Python кода рекомендуется использовать процессы.
Для этих целей существует модуль processing, который имитирует семантику стандартного модуля threading, но использует процессы вместо потоков. Этот модуль поддерживает очереди, каналы (англ. pipes), блокировки, а так же разделяемые переменные. Этого набора достаточно, чтобы реализовать многопроцессный HTTP-сервер в многопотоковом стиле.
В итоге для реализации HTTP-сервера было решено помимо модуля processing воспользоваться базовым кодом HTTP-сервера из модуля BaseHTTPServer. Итак, при запуске реализованного HTTP-сервера создается экземпляр класса HTTPServer, который открывает на прослушивание сокет на указанном IP-адресе и порту, после чего процесс разветвляется на заданное количество дочерних процессов.
Для обработки запросов с выполнением продолжений необходимо было перегрузить метод process_request(), в котором происходит извлечение идентификатора продолжения и определяется функция-обработчик, необходимая для обработки запроса. Далее управление передается разработанным базовым модулям, которые выполняют свои функции.
3.5 Интеграция с Django
Реализованный HTTP-сервер позволяет воспользоваться возможностями разработки web-приложений с использованием продолжений, но не является законченным решением для создания сложных web-приложений. С целью повышения эффективности разработки сложных web-приложений было необходимо рассмотреть возможность интеграции основных фрагментов разработанной системы управления продолжениями с существующими программными решениями.
Django является высокоуровневым бесплатным программным каркасом для создания web-приложений, написанный на языке программирования Python. Он обладает прагматичным дизайном и позволяет эффективно разрабатывать сложные web-приложения. Он примерно соответствует архитектуре MVC, хотя сами создатели называют ее MTV (от англ. Model-Template-View – «Модель-Шаблон-Вид»), где в роли контроллера выступает вид (функция-обработчик).
Изначально Django использовался в рабочем режиме в World Company для управления тремя новостными сайтами. Это происхождение не могло не сказаться на архитектуре каркаса: он предоставляет ряд средств, которые помогают в быстрой разработке web-приложений информационного характера. Так, например, в Django имеется встроенная расширяемая система администрирования сайта, позволяющая управлять его содержимым[8].
Кроме того, в возможности Django входят:
Встроенный слой ORM (от англ. Object-relational mapping – «Объектно-реляционная проекция») – технология, которая связывает базу данных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную среду».
Подключаемая архитектура приложений, которыми можно компоновать целевую информационную систему.
Полноценный API доступа к базе данных с поддержкой транзакций.
Авторизация пользователей с возможностью подключения внешних модулей авторизации.
Расширяемая система шаблонов, поддерживающая наследование.
Диспетчер URL, построенный на регулярных выражениях
Система фильтров (англ. middleware) для построения дополнительных обработчиков запросов.
Интернационализация и локализация приложений
Этот список возможностей может быть продолжен. Именно благодаря выдающимся возможностям этого программного каркаса с целью расширить эти возможности было решено интегрировать Django с разработанными для поддержки web-разработки с продолжениями базовыми модулями.
Для решения поставленной задачи было решено воспользоваться системой фильтров. Django позволяет создавать легковесные низкоуровневые фильтры для обработки приходящих запросов и выходящих ответов.
Рисунок 12. Обработка запроса сервером приложений.
DFD-диаграмма верхнего уровня
Запрос программы-клиента в Django обрабатывается следующим образом. При получении запроса центральный процессор событий проверяет строку запроса на соответствие зарегистрированным в системе регулярным выражениям. При совпадении процессор выбирает соответствующую функцию-обработчик. Далее функция обработчика и параметры запроса пропускаются через систему фильтров. Если ни один из фильтров не вернул ответа, то управление передается функции-обработчику, которая после выполнения возвращает объект ответа в центральный процессор, которой вновь прогоняется через зарегистрированные фильтры. После этого ответ возвращается программе-клиенту (см. Рисунок 13).
Таким образом, было необходимо реализовать фильтр для запроса, который определял бы тип функции-обработчика, при необходимости извлекал и восстанавливал продолжение или создавал новое. Такая необходимость возникает не всегда: не следует забывать про встроенную в Django подсистему администрирования, которая должна была продолжать работать в штатном режиме. В ходе экспериментов было выявлена невозможность реализации функций-обработчиков с поддержкой продолжений идентичными оригинальным функциям-обработчикам. Это связанно с тем, что Django при передаче управления своим функциям-обработчикам передает им объект запроса в качестве параметра. А при сериализации функции-обработчика с поддержкой продолжения полученный параметр сохранится, но при восстановления продолжения система должна передать ему новый объект запроса. Чтобы избежать подобного конфликта, было предоставить доступ к объекту запроса, через глобальную переменную, которая, как было описано выше, не сохраняется вместе с продолжением.
Рисунок 13. DFD-диаграмма декомпозиции функции «Сервера приложений»
В итоге для создания функции-обработчика с поддержкой продолжения необходимо после объявления установить ей атрибут, по которому фильтр сможет определить, обрабатывать ему этот запрос или нет.
Рисунок 14. DFD-диаграмма декомпозиции функции «фильтра»,
отвечающего за управление состояниями
Django имеет встроенную поддержку FastCGI – один из наиболее производительных и безопасных способов обработки запросов внешними программами. FastCGI ликвидирует множество ограничений CGI-программ, такие как необходимость перезапуска web-сервером при каждом запросе, приводящую к понижению производительности. FastCGI убирает это ограничение, сохраняя процесс запущенным и передавая запросы этому постоянно запущенному процессу, что позволяет экономить время на создание новых процессов[9]. FastCGI поддерживается в Django как в многопотоковом, так и в многопроцессном режиме.
При реализации хранилища продолжений для Django с целью избежать лишних нагрузок на актуализацию хранимых состояний было решено использовать встроенных механизм пользовательских сессий. Пользовательские сессии Django также хранятся в базе данных, но имеют свое «время жизни». Кроме того, использование пользовательских сессий в качестве хранилища продолжений позволяет повысить безопасность приложений за счет того, что злоумышленник при перехвате идентификатора продолжения не сможет его загрузить, если соответствующее состояние не сохранено в его сессии.
Таким образом, программный каркас Django был расширен новой возможностью поддержки функций-обработчиков с продолжением, сохранив при этом все свои достоинства.
Листинг 3. Вид Django-обработчика многошаговой бизнес-функции
с использованием продолжений
На Листинге 3 представлен код примера, получившейся в результате функции обработчика Django. Объект запроса является атрибутом объекта cont, класс которого содержит в себе управляющие статические методы send() и send_and_wait(). Кроме того, во вспомогательной функции process_template(), которая генерирует ответ, основываясь на выходных параметров, используется метод current(), который возвращает идентификатор текущего состояния, по которому будет сохранено продолжение выполняющейся функции.
|
