Содержание к диссертации
Введение
Глава 1. Обзор методов построения веб-приложений .. 13
1.1 Введение 13
1.2 Особенности веб-приложений 15
1.3 Системы создания веб-приложений 16
1.3.1 Введение 16
1.3.2 Шаблон "Модель - Представление - Контроллер" 18
1.3.3 Обзор систем создания веб-приложений 23
1.4 Модель веб-приложения 30
1.4.1 Введение 30
1.4.2 Объектно-реляционное отображение 31
1.4.3 Использование объектно-реляционного отображения 34
1.5 Представление в веб-приложениях 36
1.5.1 Введение 36
1.5.2 Шаблоны 38
1.5.3 Использование XML/XSL для публикации в веб-приложениях 41
1.5.4 Компонентное представление 43
1.6 Контроллер 44
1.7 Заключение 46
Глава 2. Методы и алгоритмы кэширования в веб-приложениях 48
2.1 Введение 48
2.2 Уровни кэширования в веб-приложениях 49
2.2.1 Клиент-кэширование 49
2.2.2 Прокси-кэширование 49
2.2.3 Реверс-прокси и форвард-прокси кэширование 51
2.2.4 Серверное кэширование 52
2.3 Фрагментарное кэширование 55
2.3.1 Введение 55
2.3.2 Модель обработки запросов пользователей с использованием серверного кэширования 58
2.3.3 Анализ изменения нагрузки на сервер при использовании полностраничного и фрагментарного кэширования 63
2.3.4 Распределенная сборка фрагментов 68
2.4 Алгоритмы замещения объектов в кэше 71
2.4.1 Введение 71
2.4.2 Традиционные алгоритмы и их прямые расширения 71
2.4.3 Функциональные и гибридные алгоритмы 74
2.4.4 Адаптивные алгоритмы 75
2.4.5 Разработка модифицированного адаптивного алгоритма, учитьшающего время получения динамического объекта 78
2.4.6 Исследование эффективности работы модифицированного алгоритма 83
2.6 Заключение 88
Глава 3. Разработка архитектуры системы создания веб-приложений 89
3.1 Введение 89
3.2. Архитектура системы создания веб-приложений 90
3.2.1 Структура системы 90
3.2.2 Компонентное представление 93
3.2.3 Модель на базе объектно-реляционного отображения 100
3.3 Интегрированная система серверного кэширования 102
3.3.1 Введение 102
3.3.2 Инвалидация устаревших запросов к БД/ фрагментов 103
3.3.3 Стратегии инвалидации записей кэша 104
3.3.4 Архитектура системы инвалидации 106
3.4. Заключение 108
Глава 4. Модульная система iPHPortal 2 ПО
4.1. Введение 110
4.2 Архитектура системы 111
4.2.1 Системные требования для работы системы 111
4.2.2 Структура системы 111
4.2.3 Модули системы 113
4.3 Реализация модели веб-приложения 115
4.3.1 Введение 115
4.3.2 Описание сущностей системы 119
4.3.2 Описание редактирования сущностей системы 121
4.4 Реализация представления веб-приложения 122
4.4.1 Введение 122
4.4.2 Описание компонентного представления 124
4.4.2 Обработка и кэширование шаблонов 125
4.5. Подсистема создания административных интерфейсов 128
4.5.1 Введение 128
4.5.2 Состав административного интерфейса 129
4.5.3 Составные элементы форм редактирования 134
4.5.4 Составные элементы форм поиска 138
4.6 Заключение 140
Заключение 141
Список используемых источников 143
Приложения 152
- Шаблон "Модель - Представление - Контроллер"
- Реверс-прокси и форвард-прокси кэширование
- Модель на базе объектно-реляционного отображения
- Системные требования для работы системы
Введение к работе
Актуальность исследования
За последние 10 лет всемирная сеть Интернет претерпела значительные изменения. Веб-серверы, ранее являвшиеся системами для распространения статического контента, стали представлять собой платформы для работы интерактивных, персонализированных, распределенных приложений уровня предприятия. Интерактивные приложения, работающие в сети Интернет в соответствии со стандартами и соглашениями всемирной паутины, получили общее название веб-приложений, в которых клиентом выступает браузер, а сервером — веб - сервер. Вся логика приложения сосредотачивается на сервере, а браузер лишь отображает информацию, загруженную по сети с сервера. Современные веб-приложения - это сложные программные комплексы, разработка и поддержание которых становится непростой задачей.
Разработка веб-приложений (порталов, информационных сайтов, образовательных сайтов и др.) является новым и наиболее перспективным направлением развития информационных и телекоммуникационных технологий, затронувшим наряду с другими сферами систему образования.
В России наблюдается повышенный спрос на получение образовательных услуг с использованием дистанционной формы обучения. При этом спрос на образовательные услуги носит распределенный характер, что подтверждается заинтересованностью регионов в доступе к ним. Современным инструментом для создания образовательных сайтов, представляющих возможности для дистанционного образования, является технология порталов, которая обеспечивает:
размещение информационных ресурсов в среде портала (в том числе метаинформации, оперативной информации, персональной и
корпоративной информации, универсальных и специализированных образовательных сервисов);
навигацию (на основе широкого спектра поисковых процедур и специализированных средств);
доступ к ресурсам (в частности, к цифровым образовательным ресурсам) и взаимодействие пользователей.
Для создания образовательных порталов необходимы программные средства, известные как веб-каркасы или системы создания веб-приложений (от англ. web-application frameworks), которые служат основой для построения специализированных решений, предоставляя повторно используемые компоненты для решения общих задач веб-приложений. Динамические веб-приложения удобны для пользователей, но они создают большую нагрузку на сервер, чем статические страницы, поэтому необходимо обеспечение высокой нагрузочной способности за счет кэширования динамических данных, распространенного подхода для увеличения быстродействия, при котором копия объекта, который доставлялся пользователю, сохранялась и использовалась для последующих запросов. Основным применением систем создания веб-приложений является создание на их основе систем управления содержанием, которые используются для управления структурой и информационного наполнения динамических сайтов.
В настоящее время создано значительное количество систем создания веб-приложений для различных платформ. Такие продукты как Zend Framework (PHP), Simfony (PHP), Limb (PHP), Ruby On Rails (Ruby), Struts (Java), Tapestry (Java) широко используются разработчиками по всему миру. По статистике наибольшее распространение получили решения на базе связки Linux- Apache - MySQL - PHP - так называемого набора "LAMP". Эти программные продукты не разрабатывались специально для работы друг с другом, однако такая связка стала весьма популярной, в первую очередь из-за своей доступности - все её составляющие являются открытыми и могут
быть бесплатно загружены из Интернета. Набор LAMP входит в состав большинства дистрибутивов GNU/Linux и предоставляется многими хостинговыми компаниями. В процессе создания системы образовательных порталов с использованием имеющихся решений были выявлены следующие их недостатки:
Интенсивное использование СУБД и сервера приложений, ведущее к повышенной нагрузке на веб-сервер и к увеличению времени отклика. Использование имеющихся средств кэширования влечет за собой дополнительные затраты времени разработчика на описание правил кэширования — времени жизни записей кэша (что ведет к возможности получения пользователем устаревших данных) или зависимостей между записями кэша и источниками данных.
В качестве политики замещения записей кэша, с учетом ограниченности размера кэша, в основном используется алгоритм LRU (удаляется наиболее давно запрашиваемая запись). В этом алгоритме не используется информация о времени, затраченном на создание кэшируемого динамического объекта, а также отсутствует способность адаптироваться под изменяющийся характер рабочей нагрузки. Учет времени получения записи позволяет сохранять в кэше трудно вычислимую запись, что в итоге позволяет снизить нагрузку на вебсервер.
В механизмах создания внешнего представления сайтов не во всех рассмотренных разработках используется фрагментарное кэширование, а методы его использования приводят к необходимости создания дополнительного программного кода.
Отсутствуют механизмы быстрого создания административных интерфейсов для редактирования данных веб-приложения. Т.к. практически каждое веб-приложение имеет свою уникальную модель данных, такие средства необходимы для снижения времени разработки.
Таким образом, актуальность темы настоящей диссертации обусловлена необходимостью разработки архитектуры веб-приложений, учитывающей вышеперечисленные недостатки и включающей в себя методы снижения нагрузки на веб-систему за счет многоуровневого кэширования динамических данных.
Цель работы и задачи исследования. Целью диссертационной работы является разработка методов и средств построения и кэширования веб-приложений, обеспечивающих снижение нагрузки на веб-систему. Для достижения указанной цели в работе решаются следующие задачи:
Обзор способов построения веб-приложений;
Анализ методов кэширования в веб-приложениях;
Разработка архитектуры веб-приложений, нацеленной на использование многоуровневого кэширования динамических данных;
Разработка модели системы кэширования;
Разработка адаптивного алгоритма политики замещения данных в кэше, учитывающей время получения динамических объектов (запросы к БД, фрагменты страниц);
Разработка системы хранения данных на основе технологии объектно-реляционного отображения;
Разработка системы создания специализированных интерфейсов для редактирования данных;
Практическая реализация полученных результатов.
Методы исследования
Для решения поставленных задач использованы методы общей теории систем, теории множеств, теории систем массового обслуживания,
сравнительного анализа, объектно-ориентированного анализа и проектирования
Научная новизна
Новыми являются следующие разработки и исследования автора:
Модель системы кэширования на базе теории массового обслуживания обеспечивающая возможность численно оценить снижение нагрузки на веб-сервер при использовании фрагментарного кэширования, по сравнению с полностраничным кэшированием.
Оригинальная архитектура веб-приложений, основанная на парадигме Модель-Вид-Контроллер, включающая в себя:
Использование компонентного представления при создании пользовательского интерфейса, позволяющее неявно описывать взаимосвязь между информацией, получаемой из БД и динамическими фрагментами веб-страниц;
Модель веб-приложения на базе технологии объектно-реляционного отображения, дающая возможность отслеживать изменения в БД для поддержания целостности записей кэша - фрагментов веб-страниц и результатов выборок из БД;
Интегрированную систему многоуровневого кэширования динамических данных, использующую модифицированный адаптивный алгоритм политики замещения записей кэша, учитывающий время получения динамических данных, хранящихся в кэше;
Систему создания специализированных интерфейсов для редактирования данных, хранящихся в системе на базе технологии объектно-реляционного отображения.
Таким образом, в диссертационной работе разработаны теоретические положения и решение задачи создания средств разработки веб-приложений и
снижения нагрузки на веб-систему за счет кэширования динамических данных.
Научные положения, выносимые на защиту
Модель системы кэширования на базе теории массового обслуживания.
Модифицированный алгоритм адаптивного кэширования динамических данных в веб-приложениях, учитывающий время получения динамических данных, хранящихся в кэше.
Архитектура веб-приложений, основанная на интеграции компонентного представления и модели веб-приложения на базе технологии объектно-реляционного отображения, включающая с целью снижения нагрузки на веб-сервер многоуровневое кэширование динамических данных
Практическая ценность
Практическая реализация методов произведена при создании свободно
распространяемой системы управления сайтом iPHPortal
, которая предназначена для создания сайтов различных типов, включая образовательные порталы и сайты дистанционного образования. Для реализации выбрано следующее, бесплатно распространяемое системное программное обеспечение с открытым исходным кодом:
Веб-сервер Apache 1.3+;
Модуль веб-сервера РНР 5+;
Сервер баз данных MySQL версии 3.2+.
Использование бесплатно распространяемого системного
программного обеспечения позволяет расширить круг организаций, которые могут использовать созданную систему управления сайтом, а использование
программного обеспечения с открытым кодом обеспечивает большую информационную безопасность.
Система использована для реализации 7 официальных сайтов и порталов:
Сайт Министерства Образования и Науки РФ
Сайт Федерального Агентства по Науке и Инновациям :
Корпоративный портал Федерального Агентства по Науке и Инновациям ;
Федеральный портал по информационным и телекоммуникационным технологиям в образовании ;
Федеральный портал по научной и инновационной деятельности ;
Система региональных хранилищ Единой Коллекции Цифровых образовательных Ресурсов ;
Система электронного хранилища новостной информации.
Апробация работы.
Основные положения диссертационной работы докладывались и обсуждались на научно-практических конференциях и семинарах, в том числе:
XI Всероссийской научно-методической конференции "Телематика'2004" (г. Санкт-Петербург, 7-Ю июня 2004 г.);
Семинарах аспирантов и научных сотрудников ФГУ ГНИЙ ИТТ "Информика" (Москва 2005 г., Москва 2006 г.);
Международной научной конференции "Информационные технологии и телекоммуникации в образовании и науке (IT&ES'2005)" (Турция, Анталия, 15-22 мая 2005г.);
XII Всероссийской научно-методической конференции "Телематика'2005" (Санкт-Петербург, 6-9 июня 2005 г.);
Международной научной конференции "Информационные технологии и телекоммуникации в образовании и науке (IT&ES'2006)" (Турция, Анталия, 19-26 мая 2006 г.);
Научно-практической конференции "Инновации в условиях развития информационно-коммуникационных технологий (Сочи, 1 -10 октября 2006 г.);
Международной научной конференции "Информационные технологии и телекоммуникации в образовании и науке (IT&ES'20O7)" (Турция, 18-25 мая 2007 г.);
XIV Всероссийской научно-методической конференции "Телематика'2007" (Санкт-Петербург, 18-21 июня 2007 г.);
Международном симпозиуме "Новые информационные технологии и менеджмент качества (NIT & MQ'2008)" (Турция, 16-23 мая
2008г.).
Публикации.
Основное содержание диссертационной работы было отражено автором в 10 печатных работах (в том числе 1 публикация в ведущем рецензируемом научном издании, рекомендованном ВАК, 1 публикация в сборнике научных статей, 7 публикаций в трудах научных конференций, 1 публикация в журнале).
Структура и объем диссертации.
Диссертация состоит из введения, четырех глав, заключения, приложений и списка литературы. Объем работы составляет 165 страниц. Работа содержит 62 рисунка, 15 таблиц, 2 приложения и список цитированной литературы из 118 наименований.
Во введении обосновывается актуальность темы диссертации, сформулированы цель и задачи исследования, показана научная новизна и практическая ценность полученных результатов.
В первой главе дается обзор известных методов построения веб-приложений. Рассматриваются основные методы реализации отдельных частей веб-приложений. В заключение главы формулируются задачи исследования.
Во второй главе описываются основные методы кэширования в веб-приложениях и, на базе предлагаемой модели, дается численная оценка снижения нагрузки на веб-сервер за счет применения фрагментарного кэширования. Рассматривается модифицированный алгоритм политики замещения записей кэша, учитывающий время получения кэшируемого объекта. Представлены результаты экспериментальных исследований модифицированного алгоритма.
В третьей главе дано описание архитектуры системы создания веб-приложений, которая помимо четкого разделения уровней бизнес-логики и представления, обеспечивает механизмы для кэширования динамических данных.
В четвертой главе рассматривается практическая реализация предлагаемой архитектуры. Приводится описание созданной системы создания веб-приложений iPHPortal.
В заключении сформулированы основные результаты диссертационной работы
В приложениях 1 и 2 представлены свидетельство о государственной регистрации программы для ЭВМ и исходный код модифицированного алгоритма замещения записей кэша CAR Мод.
Шаблон "Модель - Представление - Контроллер"
Основной задачей, которую приходится решать при разработке любой информационной системы, это проблема организации взаимодействия между логическим уровнем приложения, уровнем интерфейсов, уровнем бизнес-логики и уровнем хранения данных.
Бизнес-логика — архитектурное понятие в программировании, отражающее специфический для области применения (бизнеса) алгоритм работы с данными и их свойствами. Бизнес-логика обычно строится с использованием универсального извлечения данных (чаще всего из СУБД).
Классическое решение было предложено программистами модулей для поддержки графического интерфейса в языке Смолток (от англ. Smalltalk) в виде паттерна проектирования Модель-Вид-Контроллер (Model-View-Controller, MVC), который и стал основой для всего графического интерфейса приложений системы. Объектно-ориентированные методы приобретают все большее значение и в разработке веб-систем, по мере того, как веб-приложения становятся все сложнее и интегрируются с традиционными серверными приложениями [6, 17, 23].
Назначение большинства информационных систем - получение данных из некоторого хранилища и отображение их пользователю. Затем пользователь выполняет какие-либо действия, и система сохраняет данные либо модифицирует их. Так как основной обмен данными происходит между хранилищем данных и пользовательским интерфейсом, очень часто эту функциональность объединяют, при этом, как правило, повышается общая производительность системы и уменьшается объема кода. Однако нередко возникает необходимость независимой модификации пользовательского интерфейса или бизнес-логики. Дальнейшее усложнение приложения требует создания сложной объектной модели и постоянного ее изменения. Шаблон Модель-Вид-Контроллер позволяет разделить бизнес-логику, представление и обработку действий пользователя натри части (рис. 1.3, рис. 1.4): контроллер: принимает и интерпретирует входные данные, а затем информирует модель и представление о необходимости соответствующей реакции; модель: обрабатывает полученные данные в соответствии с задачами, которые должно выполнить приложение, предоставляет данные (для представления), а также реагирует на запросы изменить свое состояние (от контроллера). Здесь реализуются все основные алгоритмы программы; представление: выводит на экран (или другое устройство вывода) результат обработки данных.
Применение паттерна Модель-Вид-Контроллер позволяет решить следующие проблемы: код отделен от представления данных; таким образом, представление данных легко переработать, не затрагивая остальные части системы; хранилище данных может быть любым (как база данных, так и, например, XML-файл); меньше времени уходит на разработку приложения, так как сильно сокращается время, необходимое для тестирования; при разработке приложения можно параллельно вести разработку нескольких частей системы благодаря абстракциям, применяемым в контроллере.
Пользователь вступает во взаимодействие с системой (рис. 1.5), используя элементы управления на текущей странице (ссылки и формы). В некоторых случаях возможно изменение способа представления данных на стороне клиента без нового запроса к серверу. Таким образом, фактически каждое событие, генерирующееся на уровне представления, порождает изменение представления у конкретного клиента. Это обусловлено спецификой протокола HTTP, где ответ сервера порождается запросом клиента.
Реверс-прокси и форвард-прокси кэширование
В отличие от прокси-кэширования, реверс-прокси служит прокси-сервером для сервера, а не для клиента (рис. 2.2). Основные функциями реверс-прокси являются: географически распределенная репликация контента, репликация контента для балансировки нагрузки, снижение нагрузки на веб-сервер и защита от атак "Отказ в обслуживании" DoS (от англ. Denial of Service), когда на сервер обрушивается шквал запросов.
Для клиента реверс-прокси представляется как веб-сервер. Форвард-прокси используется для реализации сетей доставки контента CDN (от англ. Content Delivery Networking), в этом случае сеть прокси-серверов находится в различных узлах сети Интернет [32].
В случае использования серверного кэширования кэш находится на сервере, на котором работает веб-приложение и кэширование производится на уровне запросов к БД, фрагментов динамических веб-страниц [58, 59, 96, 97, 115]. Данный тип кэширования позволяет снизить нагрузку на сервер и снизить задержки при выдаче контента. Сложность кэширования динамических объектов заключается в том, что не всегда очевидно стоит ли кэшировать определенный объект или нет, т.к. если стоимость кэширования объекта выше стоимости генерации объекта - то кэширование не имеет смысла.
Практически все современные СУБД предоставляют встроенные механизмы для кэширования результатов запросов на получение данных. Этот метод достаточно эффективен, если система регулярно делает одни и те же выборки, но также имеет ряд недостатков, основными из которых является инвалидация записей кэша связанных с определенной таблицей БД при любом ее изменении [94]
При реализации кэширования возникает несколько вопросов относительно промежуточных данных, которые передаются между звеньями веб-приложения:
Кэш может находиться в сервере БД, сервере приложений (интегрированный кэш), прокси-сервере, веб-клиенте (например, в случае если производится генерация HTML на основе XML и XSLT на стороне клиента, используя возможности браузера). Выбор расположения кэша зависит от характеристик доступа к кэшируемым объектам и от возможностей хранилища.
Преимуществом внешнего кэша является лучшее соотношение стоимость/быстродействие. Такой кэш может работать на аппаратном обеспечении, у которого нет накладных расходов на операционную систему (управление процессами, управление памятью). Интегрированный кэш может использовать фрагментарное кэширование, имеет большую гибкость управления хранимыми данными, позволяет использовать систему авторизации для доступа к хранилищу. 4. Каким образом обновления БД будут вызывать обновления кэша?
Обновления могут производиться методами push (толкать) или pull (тянуть). При использовании push-способа обновление в БД немедленно вызывает удаление или изменение содержания устаревших сохраненных данных. Принцип pull-способа заключается в периодической проверке данных на предмет соответствия кэша и источника сохраненных данных. Только push-способ может гарантировать актуальность данных, в то время как при pull-обновлении существует возможность использования устаревших данных, что может быть неприемлемо для одних и терпимо для других сайтов. Однако push-метод реализуется только ценой использования "дорогого" в плане ресурсов механизма триггеров [42].
Первым кандидатом для кэширования являются HTML-фрагменты, т.к. они удовлетворяют следующим критериям: Требуется достаточно много ресурсов для их создания; Не требуют частого обновления; Часто запрашиваются.
Для остальных типов данных (запросов к БД, объектов доступа к данным) не очевидно, перевесит ли выгода от кэширования ресурсы, затраченные на кэширование. Ответы на эти вопросы зависят от БД, размера веб-приложения, ограничений на время отклика и степень актуальности данных, распределения запросов пользователей по разделам сайта и от среды, в которой выполняется приложение - программное обеспечения и "железо" сервера.
Модель на базе объектно-реляционного отображения
Для организации объектной модели данных веб-приложений необходима система объектно-реляционного отображения. Система должна быть способна загружать, сохранять, создавать новые данные, делать выборки по определённым критериям, удалять объекты. Все эти действия в конечном итоге сводятся к SQL запросам данных реляционных таблиц. Во время построения запроса необходимы метаданные об отображаемых в строки таблиц объектах: идентификатор, класс, имена PI типы атрибутов, средства для чтения и записи атрибутов, связи с другими объектами, их множественность, средства для чтения и установки связей. Всю эту информацию предоставляет метамодель объектных данных, набор классов для описания объектной модели веб-приложения. Любой хранимый объект предоставляет своё мета-описание для построения запросов к СУБД.
В наиболее распространенных системах объектно-реляционного отображения [116] реализованы следующие возможности модели приложения: Создание, чтение, редактирование, удаление сущностей, таких как материалы, сообщения форума и т.д.; Механизмы хранения бинарных данных, как в файловой системе, так и средствами СУБД; Создание связей между сущностями типов "Один ко многим", "Многие к одному", "Один к одному", "Многие ко многим"; Проверка введенных данных. В системе объектно-реляционного отображения, ориентированной на разработку веб-приложений с использованием технологий быстрой разработки программного обеспечения должны быть реализованы функциональности: Организация записей в списки (например, материалы) и деревья (например, рубрики каталога); Хранение информации о пользователях, создавших, сохранивших и удаливших записи, а также о времени этих операций; Средства разделения доступа к данным, обеспечивающие гибкие конфигурационные возможности; Минимизация нагрузки на СУБД за счет оптимизации запросов и кэширования данных; Встроенные механизмы для импорта-экспорта данных сущностей, например, с помощью XML. ORM-система построена на базе шаблона проектирования "Активная запись" [23] . Для каждой таблицы БД создается класс, описывающий атрибуты таблицы и действия, которые можно выполнять над сущностью.
Задача класса — предоставлять информацию об атрибутах сущности и ассоциациях с другими сущностями предметной области. Атрибуты хранимых объектов имеют в приложении конкретный тип данных, который соответствует определённому типу данных табличной колонки в СУБД. Межклассовая ассоциация указывает на наличие связи между сущностями. Связь между двумя конкретными объектами всегда является элементом соответствующей ассоциации их классов. В системе объектно-реляционного отображения должны быть реализованы типы связей: один к одному, один к нулю или одному, один ко многим, многие к одному. Система кэширования использует 2 свойства, свойственные многим веб-приложениям: В операциях с данными превалирует чтение Обновления состоят и небольшого, фиксированного набора запросов Первое делает возможным обрабатывать все обновления данных, которые производятся веб-приложением.
В этом случае не должно производиться обновлений БД другим приложением. Второе свойство дает возможность создать механизм для поддержания целостности и соответствие кэша нижележащим данным без значительной нагрузки на систему. При кэшировании фрагментов страниц и запросов БД используется материализация - термин, обозначающий трансформацию динамических веб данных в статические веб-данные [76]. В данной работе материализация это создание статического экземпляра страницы/фрагмента/запроса к БД в некоторый период времени (рис. 3.11). Пользователи сайта видят статические эквиваленты динамических веб-страниц. В идеальном случае, когда все фрагменты страницы есть в кэше, запрос пользователя обслуживается без участия сервера баз данных. Очевидно, что если частота/момент создания/обновления статической копии выбран не в соответствии с обновлениями в БД, пользователи буду получать устаревшие данные. В разработанной архитектуре при кэшировании на уровне представления используется подход реверс-прокси, который используется для фрагментарного кэширования и кэширования запросов к БД, при котором сборка страницы из фрагментов производится перед выдачей пользователю (раздел 2.1). В качестве политики замещения используется модифицированный алгорим CAR Мод, описанный в главе 2, позволяющий снизить нагрузку на веб-сервер.
Системные требования для работы системы
Для функционирования системы iPHPortal 2 необходимо выполнение следующих требований к системному программному обеспечению: Веб-сервер Apache 1.3 и старше; РНР 5.x и старше, установленный как модуль Apache MySQL 3.22 и старше Права доступа на запись (создание / чтение /изменение / удаление) файлов на сайте из скриптов РНР Возможность использование .htaccess файлов (в httpd.conf Apache должна быть установлена опция AllowOverride All) Требования к аппаратной части сильно зависят от характера использования системы и от нагрузки. Для образовательного сайта, содержащего модули каталога образовательных ресурсов, публикации материалов, форума и поиска, и обрабатывающего до 200 тыс. запросов в день рекомендуется следующая конфигурация сервера: процессор Intel ltanium2; тактовая частота процессора 1500 MHz; оперативная память 4 GB; дисковый накопитель SCSI объемом 60 GB; сетевая карта 100GBit. Сайты, использующие предлагаемую систему создания веб-приложений, состоят из 3 взаимосвязанных частей: 1. База данных; 2. Административный интерфейс (бэкофис); 3. Внешнее представление сайта (фронтофис).
В базе данных хранится структура сайта, информация модулей, и служебная информация необходимая для работы системы. Бинарные данные хранятся в файловой системе. Функции бэкофиса: 1. Изменение структуры сайта; 2. Работа с шаблонами и контроллерами; 3. Информационное наполнение и модерирование интерактивов; 4. Управление пользователями и правами пользователей. В таблице 4.1 перечислены составляющие файловой структуры системы iPHPortal 2. Файлы, которые должны быть доступны пользователю через интернет, расположены в веб-директории системы. Системные файлы лежат в директории, которая не может быть просмотрена через веб-сервер.
При анализе предметной области были выявлены сущности, которые используются в системе управления сайтом (таблица 4.2). Сущность -описание некоторого типа объектов в системе, определяется набором полей с заданной областью значений для каждого, а также набором возможных действий, которые может выполнять объект. Сущности группируются по области действия в модули. Модуль в системе iPHPortal 2 состоит из сущностей, административных и пользовательских интерфейсов для работы с сущностями. Файлы, относящиеся к модулю, располагаются в поддиректории директории system/module (рис. 4.2). В директории admin модуля хранятся скрипты административного интерфейса модуля, в директории property -специализированные классы атрибутов для данного модуля. Модель веб-приложений, построенных на основе системы iPHPortal 2 строится на базе подсистемы объектно-реляционного преобразования, что позволяет снизить стоимость модификации имеющихся и разработки новых модулей. На рис. 4.3 показана диаграмма основных классов ORM-системы, на основе которых разработчики строят специализированные решения. Класс "Сущность" является базовым классом, реализующим шаблон проектирования "Активная запись" [24]. В классе реализованы методы для создания, сохранения и удаления записи. Эти методы в свою очередь вызывают соответствующие методы entitylnsert, entityUpdate и entityDelete объекта класса ModelEntity.
