CC BY
95
2. Колчин А.Ф., Овсяников М.В., Стрекалов А.Ф., Сумароков С.В. Управление жизненным циклом продукции. - М.: Анахарсис, 2002. - 304 с.
3. Судов Е.В. Интегрированная информационная поддержка жизненного цикла машиностроительной продукции. Принципы. Технологии. Методы. Модели. - М.: Изд. дом «МВМ», 2003. - 264 с.
4. IMS Digital Repositories Specification [Электронный ресурс] / IMS. - Versión 1.0. - Электрон. текстовые дан. - [UK]: IMS, 2002. - Режим доступа: http://www.imsproject.org/digitalrepositories/index.cfm. -Англ.
5. IMS Learning Resource Meta-data Specification [Электронный ресурс] / IMS. - Version 1.2.1. -Электрон. текстовые дан. - [UK]: IMS, 2001. - Режим доступа: http://www. imspro-ject.org/metadata/index.cfm. - Англ.
6. IEEE 1484.12.1-2002. Learning Object Metadata standard. - New York: IEEE, 2002.
7. Башмаков А.И. Систематизация информационных ресурсов для сферы образования: классификация и метаданные / А.И.Башмаков, В.А.Старых. - М., 2003. - 212 с.
8. СТП 3.4 Система вузовской учебной документации. - Красноярск.: СибГТУ, 2002.
9. Государственный образовательный стандарт высшего профессионального образования. Р.н. 224 тех. дс. [Электронный ресурс]: Режим доступа: http://www.informika.ru
10. Башмаков А.И. Креативная педагогика: методология, теория, практика / И.А. Башмаков, А.И. Владимиров и др.; под ред. Ю.Г. Круглова. - М.: МГОПУ им. М.А. Шолохова: Изд. центр «Альфа», 2002. - 240 с.
11. Башмаков А.И. Разработка компьютерных учебников и обучающих систем / А.И. Башмаков, И.А. Башмаков. - М.: Инф.-изд. дом «Филинъ», 2003. - 616 с.
12. ГОСТ Р ИСО 9000-2001. Системы менеджмента качества. Основные положения и словарь. - М.: Изд-во стандартов, 2001. - 26 с.
13. ГОСТ Р ИСО 9001-2001. Системы менеджмента качества. Требования. - М.: Изд-во стандартов, 2001. - 21 с.
14. ГОСТ Р ИСО 9004-2001. Системы менеджмента качества. Рекомендации по улучшению деятельности. - М.: Изд-во стандартов, 2001. - 45 с.
ИССЛЕДОВАНИЕ И РАЗРАБОТКА МЕТОДОВ ПОСТРОЕНИЯ И КЭШИРОВАНИЯ ВЕБ-ПРИЛОЖЕНИЙ
М.В. Булгаков, зам. директора Тел.: (495) 237-56-13; E-mail: [email protected]
В.П. Носов, вед. программист Тел. (495) 237-56-13; E-mail: [email protected] ФГУ ГНИИ ИТТ «Информика» http://www.informika.ru
Article is devoted to methods for building web-applications, in particular educational sites and portals, and also caching methods, increases web-application 's operating speed.
Введение
За последние 10 лет всемирная сеть Интернет претерпела значительные изменения. Веб-серверы, ранее являвшиеся системами для распространения статического контента, стали представлять собой платформы для работы интерактивных, персонализированных, распределенных приложений уровня предприятия. Интерактивные приложения, работающие в сети Ин-
тернет в соответствии со стандартами и соглашениями всемирной паутины, получили общее название веб-приложений. Современные веб-приложения - это сложные программные комплексы, разработка и поддержание которых становится непростой задачей.
Разработка веб-приложений является новым и наиболее перспективным направлением развития информационных и телекоммуникационных технологий, затронувшим наряду с другими сферами систему образования.
В России наблюдается повышенный спрос на получение образовательных услуг с использованием дистанционной формы обучения. При этом спрос на образовательные
услуги носит распределенный характер, что подтверждается заинтересованностью регионов в доступе к ним. Современным инструментом для создания образовательных сайтов, предоставляющих возможности для дистанционного образования, является технология порталов [1], которая обеспечивает:
• размещение информационных ресурсов в среде портала (в том числе метаин-формации, оперативной информации, персональной и корпоративной информации, универсальных и специализированных образовательных сервисов);
• навигацию (на основе широкого спектра поисковых процедур и специализированных средств);
• доступ к ресурсам (в частности, к цифровым образовательным ресурсам) и взаимодействие пользователей.
Для создания образовательных порталов необходимы программные средства, которые служат основой построения специализированных решений. В данной статье описываются методы и средства построения и кэширования веб-приложений, использующиеся в свободно распространяемой системе управления динамическим сайтом iPHPortal [2], ориентированной на создание публикационных образовательных сайтов и порталов. На основе этой системы разработаны и продолжают развиваться порталы:
• информационно-коммуникационные технологии в образовании www.ict.edu.ru ;
• научная и инновационная деятельность www.sci-innov.ru ;
• система региональных хранилищ Единой коллекции цифровых образовательных ресурсов http://school-collection.edu.ru и др.
Каркасы веб-приложений
Важными условиями создания веб-приложений являются: быстрота разработки, надежность работы и эффективное использование ресурсов сервера. Базой для построения веб-приложений являются так называемые каркасы приложений, которые обеспечивают основу для создания новых приложений, предоставляя повторно используемые компоненты для решения общих задач веб-приложений. Каркасы, в свою очередь, разработаны на базе сервера приложений и сервера баз данных. Наибольшую популярность имеют такие технологии, как Java, Microsoft.Net, PHP,Perl (создание приложений) и Oracle, Microsoft SQL Server, MySQL (серверы баз данных).
С технической точки зрения, веб-каркас (web-framework) - это базовое веб-приложение, которое контролирует выполнение модулей и закладывает общий стандарт кодирования. Логически система разделена на ядро, загрузчик ядра, библиотеку общих функций и хранилище конфигура- ^^^^ ции. Главная осо- "
бенность веб-каркасов - это максимально возможное повторное использование кода, позволяющее в короткие сроки создавать новые веб-приложения.
Веб-каркасы отличаются от традиционных библиотек классов следующим:
1. Веб-каркасы - это «наполовину завершенные» приложения, в которых заложен набор архитектурных стандартов, которые система накладывает на веб-приложения. Это снимает с разработчиков необходимость придумывать все с нуля и позволяет более эффективно использовать код повторно;
2. Веб-каркасы предназначены для создания определенных типов приложений;
3. Веб-каркасы обеспечивают инверсию управления. Концепция, лежащая в основе инверсии управления, часто выражается «голливудским принципом»: «Не звоните мне, я вам сам позвоню». Инверсия управления переносит ответственность за выполнение действий с кода приложения на фреймворк (рис.1).
Логика приложения
I События
Сеть
Интерфейс пользователя
Математ. — Модель
класс
БД
Библиотека классов
Фреймворк
Рис. 1. Отличия между библиотеками классов и веб-каркасами
Требования к веб-каркасам
1. Инфраструктура должна быть предназначена для использования различных модулей с возможностью их замены.
2. При использовании каркасной системы приложения должны сохранять высокий уровень индивидуальности, несмотря на централизацию, которая характерна для системы.
3. Приложения, написанные без использования веб-каркаса, должны легко интегрироваться с ней.
Шаблон проектрования «Модель -Представление - Контроллер»
Основная задача, которую приходится решать при разработке любой информационной системы, - это организация взаимодействия между логическим уровнем приложения, уровнем интерфейсов, уровнем бизнес-логики и уровнем хранения данных.
Бизнес-логика - архитектурное понятие в программировании, отражающее специфический для области применения (бизнеса) алгоритм работы с данными и их свойствами. Обычно строится с использованием универсального извлечения данных (чаще всего из СУБД), занимается обработкой, отображением пользователю, а также изменением/добавлением данных в зависимости от действий пользователя.
Классическое решение было предложено программистами модулей для поддержки графического интерфейса в языке Smalltalk в виде шаблона проектирования Модель-Вид-Контроллер (Model-View-Controller, MVC), который и стал основой для всего графического интерфейса приложений системы [3].
Назначение большинства информационных систем - получение данных из некоторого хранилища и отображение их пользователю. Затем пользователь выполняет какие-либо действия, и система сохраняет данные либо модифицирует их. Так как основной обмен данными происходит между хранилищем данных и пользовательским интерфейсом, очень часто эту функциональность объединяют, при этом, как правило, повышается общая производительность системы и уменьшается объем кода. Однако нередко возникает необходимость в независимой модификации пользовательского интерфейса или бизнес-логики. Дальнейшее усложнение приложения требует создания сложной объектной модели и постоянного ее изменения. Шаблон MVC позволяет разделить бизнес-логику, представление и обра-
ботку действий пользователя на три части (рис.2):
• контроллер - принимает и интерпретирует входные данные, а затем информирует модель и представление о необходимости соответствующей реакции;
• модель - обрабатывает полученные данные в соответствии с задачами, которые должно выполнить приложение, предоставляет данные (для представления), а также реагирует на запросы изменить свое состояние (от контроллера). Здесь реализуются все основные алгоритмы программы;
• представление - выводит на экран (или другое устройство вывода) результат обработки данных.
Рис. 2. Схема работы архитектуры «Модель - Вид - Контроллер»
Модель веб-приложений
Под моделью понимается схема организации данных в системе, формат представления данных (структурная составляющая модели) и средства манипулирования данными (манипуляционная составляющая).
Во многих случаях структура данных веб-приложений не является постоянной. При моделировании структуры веб-сайта мы не имеем какой-либо фиксированной схемы, которая была бы задана заранее.
В настоящее время становится популярным применение объектно-реляционного отображения (Object Relational Mapping -ORM) для реализации модели веб-приложений [4]. ORM в широком смысле -это правило или метод, связывающий объекты языка программирования с отношениями реляционной базы данных и трансформирующий операции над объектами в соответствующие операции над отношениями. В этом смысле в любом проекте, разработка которого ведется на объектно-ориентированном языке, а данные хранятся в реляционной СУБД, эта трансформация каким-либо образом уже осуществляется.
Чаще всего под ORM понимают методику разработки проектов, в основе которой лежит использование некоторого универсального программного интерфейса, значи-
тельно упрощающего эту трансформацию, в идеале осуществляющего эту трансформацию «максимально просто» с точки зрения разработчика (рис. 3).
Таблица 1 Соответствие понятий в реляционной и объектной моделях
Реляционная модель Объектная модель
Отношение Класс
Строка Экземпляр
Атрибут Атрибут
Команда-SQL Метод
Терминология эта весьма условна, поэтому проще всего проиллюстрировать эту методику конкретными примерами. Например, отображение может осуществляться следующим образом: разработчик оперирует не SQL-запросами, а предопределенными методами сохраняемых объектов, таких как «достать», «вставить», «сохранить», «удалить» (CRUD operations, create/read/update/delete), причем эти методы универсальны (наследуются от базовых классов или предоставляются особым посредником - главное, что нет нужды их определять для каждого конкретного сохраняемого класса, по крайней мере, для большей части запросов).
Другим примером может служить использование для операций чтения объектно-реляционного драйвера, который трансформирует запрос на особом языке (языке объектных запросов OQL, Object Query Language) в SQL-запросы и возвращает уже приготовленный пользовательский объект, а не набор строк. В этом случае код очень похож на код приложения, в котором используется объектная база данных, поэтому можно говорить о реализации «виртуальной объектной базы».
Код Схема
проекта таблиц
U И
слой абстракции
Н
Рис. 3. Архитектура системы ОКМ
В обоих примерах отображение реализуется некоторым «ядром», которое лишь
используется конкретным проектом. Поэтому основная привлекательность данного подхода (вернее, самая поверхностная) состоит в том, что подобное ядро выполняет значительную часть рутинной работы программиста.
Представление в веб-приложениях
Усложнение веб-приложений привело к необходимости разделить уровень представления информации пользователю и уровень бизнес-логики. Для реализации уровня представления используются различные механизмы, которым можно дать общее название «шаблоны». Шаблон - это документ для вывода со встроенными действиями, которые шаблонная система выполняет, когда обрабатывает шаблон. Основные методы реализации представления:
• представление по шаблону;
• представление с преобразованием;
• двухэтапное представление - комбинирование представления с преобразованием и представления по шаблону.
Основная идея, лежащая в основе представления по шаблону, - это вставка маркеров в текст готовой статической HTML-страницы. При вызове страницы для обслуживания запроса эти маркеры будут заменены результатами некоторых вычислений (например, результатами выполнения запросов к базе данных). Подобная схема позволяет создавать статическую часть страницы с помощью обычных средств, например, текстовых редакторов, работающих по принципу WYSIWYG, и не требует знания языков программирования. Для получения динамической информации маркеры обращаются к различным программам.
Одной из наиболее популярных форм представления по шаблону являются скрип-товые языки - ASP, JSP или PHP. Скрипто-вый язык - это нечто большее, чем представление по шаблону, поскольку они позволяют внедрять в представление элементы программной логики, называемые скриптле-тами (scriptlets).
В основе представления с преобразованием лежит идея написания программы, которая просматривает данные домена и преобразовывает их в код HTML. В процессе выполнения такая программа последовательно проходит по структуре данных домена и, обнаруживая новый фрагмент информации, создает ее описание в терминах HTML.
Основное отличие представления с
преобразованием от представления по шаблону заключается в способе организации представления. Представление по шаблону организовано с учетом размещения на экране выходных данных. Представление с преобразованием ориентировано на использование отдельных преобразований для каждого вида входных данных. Преобразованиями управляет нечто наподобие простого цикла, который поочередно просматривает каждый входной элемент, подбирает для него подходящее действие и применяет его.
Представление с преобразованием может быть написано на любом языке, но на данный момент наиболее популярным языком для написания преобразования является Х8ЬТ[5].
В последнее время, в связи с необходимостью быстрой разработки веб-приложений, развивается компонентный подход [5], который позволяет создавать новые веб-приложения путем комбинации готовых серверных компонентов. Этот путь уже прошли «традиционные» приложения; раз столько функционала переносится в веб, неудивительно, что этим же путем могут пойти (и уже идут) веб-приложения. Каждый компонент отвечает за формирование своего элемента интерфейса и его обслужи-
вание при работе системы с пользователем. Например, этот элемент интерфейса может быть блоком голосований, может быть рамкой вокруг блока голосований или строчкой с вариантом выбора в блоке голосований. Главное, что компонент сосредоточивает в себе строго определенную переносимую часть интерфейса веб-приложения («разделяй и властвуй»). Компонент - это «черный ящик», экземпляр которого хранит информацию о состоянии (т.е. связанные с ним данные) и способен реагировать на события в зависимости от своего «состояния».
Методы кэширования веб-приложений
Содержание современных сайтов с каждым днем становится все более динамичным, интерактивным и персонализированным. Такие веб-приложения более удобны для пользователей, но они создают большую нагрузку на сервер, чем статические страницы. Кэширование в веб - это распространенный подход для увеличения быстродействия, при котором копия объекта, который доставлялся пользователю, сохранялась и использовалась для последующих запросов [7] (рис.4).
вании нет смысла
Рис. 4. Общая схема кэширования в Интернете (прокси-кэширование и бэк-енд-кэширование)
Серверное кэширование в веб-приложениях
При использовании серверного кэширования кэш находится на стороне сервера, на котором работает веб-приложение, и кэширование производится на уровне запросов к БД, фрагментов динамических веб-страниц (рис.5). Такое кэширование позволяет снизить нагрузку на сервер и снизить задержки при выдаче контента.
Сложность кэширования динамических объектов заключается в том, что необходимость в нем не всегда очевидна, поскольку если стоимость кэширования объекта выше стоимости генерации объекта, то в кэширо-
СУБД Данные
Доступ к данным Бизнес-логмка
Лотка обраб. данных
Генерация фрагментов Представление
Сборка фрагментов
Рис. 5. Звенья веб-приложения
Таблица 2
Типы кэшируемых объектов
Звено Объекты для кэширования
Данные Запросы к БД, таблиц БД
Бизнес логика Объекты, хш1-фрагменты
Представление Фрагменты страниц, страницы
При реализации кэширования возникает несколько вопросов относительно промежуточных данных, которые передаются между звеньями веб-приложения:
1. Какие данные должны кэшироваться?
В табл. 2 перечислены этапы, которые проходят данные от источника (СУБД) до потребителя (представление данных), поэтому кэшироваться могут разные типы объектов: результаты запросов к БД, объекты доступа к данным, xml-фрагменты (если используются) или HTML-фрагменты.
2. Когда должно производиться кэширование?
Возможные ответы:
a. Данные кэшируются до того, как к ним произошло обращение
b. Данные кэшируются при первом обращении
c. Предвыборка данных для кэширования производится на основе вероятности запроса этих данных.
3. Какое хранилище кэшированных данных обеспечит максимальный прирост производительности?
Кэш может находиться в сервере БД, сервере приложений (интегрированный кэш), прокси-сервере, веб-клиенте - в случае если используется генерация html на основе xml и xslt на стороне клиента - (внешний кэш). Выбор расположения кэша зависит от характеристик доступа к кэшируемым объектам и от возможностей хранилища.
Преимуществом внешнего кэша является лучшее соотношение стоимость/быстродействие. Такой кэш может быть реализован на аппаратном обеспечении, у которого нет накладных расходов на операционную систему (управление процессами, управление памятью). Интегрированный кэш может использовать фрагментарное кэширование, имеет большую гибкость управления хранимыми данными, позволяет использовать систему авторизации для доступа к хранилищу.
4. Каким образом обновления БД будут вызывать обновления кэша?
Обновления могут производиться методами push (толкать) или pull (тянуть). При использовании push-способа обновление в БД немедленно вызывает удаление или изменение содержания устаревших сохраненных данных. Принцип pull-способа заключается в периодической проверке данных на предмет соответствия кэша и источника сохраненных данных. Только push-способ может гарантировать актуальность данных, в то время как при pull-обновлении существует возможность использования устаревших данных, что может быть неприемлемо для одних и терпимо для других сайтов. Однако push-метод реализуется только ценой использования «дорогого» в плане ресурсов механизма триггеров.
5. Какие данные стоит кэшировать, а какие нет?
Первым кандидатом для кэширования являются html-фрагменты, так как они удовлетворяют следующим критериям:
a. Требуется достаточно много ресурсов для их создания
b. Не требуют частого обновления
c. Часто запрашиваются
Для остальных типов данных (запросов к БД, объектов доступа к данным) не очевидно, перевесит ли выгода от кэширования ресурсы, затраченные на него.
Ответы на эти вопросы зависят от БД, размера веб-приложения, ограничений на время отклика и степени актуальности данных, распределения запросов пользователей по разделам сайта и от среды, в которой выполняется приложение, - программное обеспечение и «железо» сервера.
Фрагментарное кэширование
Запрос к динамической странице обрабатывает скрипт, который, в сущности, является набором блоков кода. Каждый блок производит некоторые вычисления для генерации части страницы, выдавая фрагмент
ИТЫЬ-кода. После того как все блоки в скрипте были выполнены, результаты работы блоков объединяются и выдаются пользователю в виде единой страницы. Если известно, что вывод блока не изменяется достаточно долгое время, то этот блок можно сделать кэшируемым. Когда скрипт выполняется, веб-приложение, в первую очередь, проверяет наличие фрагмента блока в кэше. Если он есть, то выполнение кода блока не производится и контент блока берется из кэша. Если нет, то код блока производит вычисления и вывод блока помещается в кэш для дальнейших запросов. Содержание кэша управляется политикой замещения и механизмом инвалидации. Объект в кэше аннулируется в случае обновления нижележащего источника данных.
В веб-страницах несложно выделить фрагменты, имеющие разную частоту обновления (рис. 6). Простейший подход - это разделение страницы на хидер (шапку -верхнюю часть страницы, на которой расположен логотип сайта), тело страницы и футер (подвал). Хидер и футер меняются редко, тогда как тело страницы отличается в разных рубриках сайта. Подход к построению веб-страниц путем сборки из фрагментов облегчает работу по поддержанию сайта и позволяет кэшировать фрагменты по отдельности.
Рассмотрим произвольную страницу сайта ЖР. Пусть страница состоит из N фрагментов {F1....FN}, каждый из которых имеет различные временные характеристики. Это означает, что фрагменты остаются «свежими» разное количество времени, после чего должны быть перегенерированы. Предполагаем, что создание каждого фрагмента возлагает единичную нагрузку на сервер. Мы моделируем инвалидацию (устаревание фрагментов) каждого фрагмента как пуассоновский процесс [8].
Пусть фрагмент Fi обновляется с частотой ¡¿. Время между двумя инвалидация-ми фрагмента распределено экспоненцио-нально. Так как фрагменты имеют различные временные характеристики, процесс обновления фрагмента рассматривается как независимый от других фрагментов. Создание одного фрагмента накладывает единицу нагрузки на сервер, следовательно, полная генерация страницы (при полностраничном кэшировании) накладывает N единиц нагрузки на сервер.
Пусть кэш получает запросы страницы ЖР в соответствии с пуассоновским процес-
сом с частотой Хм>р запросов в единицу времени. Рассмотрим случай, когда поддерживается только полностраничное кэширование. В этом случае страница ЖР становится устаревшей, когда устаревает один из ее фрагментов. Так как инвалидация каждого фрагмента - это пуассоновский процесс со скоростью {л | 1 < i < N}, инвалидация страницы тоже является пуассоновским процессом. В соответствии с теорией пуас-соновских процессов частота инвалидации страницы ЖР будет:
N
№ .
¿=1
Так как мы допустили, что запросы страницы ЖР производятся в соответствии с пуассоновским процессом с частотой Хм>р, мы можем показать, что запросы, выполняемые кэшем к серверу (в момент устаревания страницы в кэше), следуют пуассо-новскому процессу с частотой
А\ур * имр Вмр = —-—<—1— .
кмр + и^р
Теперь, каждый раз, когда запрос страницы ЖР приходит на сервер, страница должна быть перегенерирована. Следовательно, загрузка сервера в единицу времени при полностраничном кэшировании равна
N * Ям>р.
С'№р = ■
¿=1_
N
¿=1
Для упрощения примем, что все фрагменты обновляются с одинаковой скоростью следовательно:
N2*р*2мр
С^р =
N * и +
Рассмотрим случай фрагментарного кэширования, когда кэш хранит фрагменты отдельно и объединяет их во время выдачи страницы пользователю. Когда фрагмент удаляется из кэша, при следующем запросе кэш запрашивает у сервера последнюю версию удаленного из кэша фрагмента. Как и в предыдущем случае, допустим, что фрагмент Fk обновляется в соответствии с пуассоновским процессом с частотой ¡к и частота запросов страницы ЖР равна Хм>р. Частота запросов к каждому фрагменту страницы ЖР такая же, как и у родительского фрагмента Хм>р. Частота запросов от фрагмента к к серверу равна:
ЯЕк =
/к * кмр /к + кмр
Поэтому общее количество запросов, поступающих на сервер от всех фрагментов страницы ЖР, тоже является пуассоновским процессом со скоростью
RWpfrag = У .
к=1 /ик + Лм>р
Как и в предыдущем случае, для упрощения анализа примем, что скорость обновления всех фрагментов одинакова и равна N * / * Л\ур
Rwpfrag =
/и + Амр
Рис. 6. Разбиение веб-страницы на фрагменты
Однако при фрагментарном кэшировании серверу нужно перегенерировать только обновившийся фрагмент. Следовательно, общая загрузка сервера в единицу времени от запросов на все фрагменты страницы ЖР
CR(Аwp = и) =
2* N N +1
. Если Хм>р = £х /л, то
Cwpfrag =
N * / * Аwp
/ + Аwp
Для сравнения загрузки сервера при фрагментарном и полностраничном кэшировании рассмотрим отношение
Cwp N *(ц + Аwp)
CR =-=- .
Cwpfrag (N * / + Аwp)
Рассмотрим, как изменяется CR в зависимости от Xwp/л. Если Xwp = /л, то
(I +1)* N
CR(Аwp = I * /) = ----. Если Xwp >>
N +1
тогда CR(Аwp = да) = N . Это выражение показывает, что в случае, если частота запросов веб-страницы гораздо больше частоты обновлений, нагрузка, возлагаемая при фрагментарном кэшировании, в N раз меньше нагрузки при полностраничном кэшировании. На рис. 7 показаны графики зависимости отношения CR и количества фрагментов на странице.
Рис. 7. Отношение загрузки сервера при полностраничном и фрагментарном кэшировании
Серверное кэширование динамических данных
Как было отмечено, применение кэширования позволяет снизить нагрузку на сервер и увеличить скорость работы веб-приложений. Материализация - это термин, обозначающий трансформацию динамических веб-данных (страниц, фрагментов, запросов к БД) в статические веб-данные. В данной работе материализация - это создание статического экземпляра страницы/фрагмента/запроса к БД в некоторый период времени. Пользователи сайта видят статические эквиваленты динамических вебстраниц. Очевидно, что если частота/момент создания/обновления статической копии выбрана (выбран) не в соответствии с обновлениями в БД, пользователи будут получать устаревшие данные.
Невозможно проводить материализацию всех фрагментов/запросов к БД, т.е. хотя сохранение копии веб-данных на диск занимает небольшое количество ресурсов, проведение инвалидации большого числа записей кэша будет создавать большую нагрузку на сервер. В силу непредсказуемости и частой изменяемости потока запросов к сайту и потока обновлений для отбора веб-данных (для выбора данных для кэширования) требуется адаптивный онлайн алгоритм.
Целью данной работы служит создание каркаса веб-приложений с интегрированной системой серверного кэширования, объединяющей кэшированние запросов к БД (уровень данных) и кэширование фрагментов Ь1ш1-страниц (уровень представления), ис-
пользующей для построения модели данных ОКМ-технологии.
Описываемый подход использует две особенности, свойственные многим веб-приложениям:
• в операциях с данными превалирует чтение;
• обновления состоят из небольшого фиксированного набора запросов.
Первое свойство позволяет обрабатывать все обновления данных, которые производятся веб-приложением. В этом случае не должно производиться обновлений БД другим приложением. Второе свойство дает возможность создать механизм для поддержания целостности и соответствия кэша нижележащим данным без значительной нагрузки на систему. Соответствие реализуется посредством инвалидации устаревших данных - нахождения и удаления устаревших объектов после обновления БД.
Использование ОКМ-технологий позволяет, помимо увеличения скорости разработки и стандартизации интерфейсов доступа к данным, неявно описывать взаимосвязи между запросами к БД и нижележащими данными, что делает возможным автоматическое построение зависимостей между ними и решает проблему обнаружения устаревших данных в кэше. Так как большинство фрагментов страниц напрямую зависит от запросов к БД, система инвалида-ции позволяет своевременно удалять из кэша как сохраненные результаты запросов к БД, так и фрагменты.
Блочная система фрагментарного кэширования
В предлагаемой схеме веб-приложение состоит из страниц, определяющих структуру расположения информации. Структура страницы может быть статической (определяться шаблоном) и динамической (определяться шаблоном и настройками пользователя). Содержание страницы компонуется из динамически создаваемых фрагментов («блоков») и статических фрагментов («включений»).
Кэш веб-приложения состоит из трех частей (рис. 8):
- кэш веб-страниц, в котором находится предкомпилированный шаблон со «скелетом» страницы, определяющим местоположение фрагментов на странице;
- кэш фрагментов страниц;
- кэш результатов запросов к БД.
Шаблон индекса включает в себя директиву включения «базового» шаблона (layout.html), в котором описаны общие для всех страниц сайта элементы. Также в шаблоне индекса описаны вызовы блоков «ММе-па^ЫБЪ) (список материалов) и «Ро1Шогт» (форма голосования) (рис. 9).
Рис. 8. Кэш веб-приложения
Блок - это компонент, который пользователи видят на странице сайта. Содержание блока (фрагмент страницы) генерируется с помощью специального класса и шаблона. Так как входные параметры и контекст выполнения блока могут меняться, один блок в
одном шаблоне может генерировать несколько фрагментов. Например, блок «Меню» будет отличаться для разных рубрик сайта (изменяется контекст выполнения блока).
Шаблон индекса сайта {редко изменяемый каркас для динамических фрагментов):
<core:wrap file="layout.html" placeholder='fContent"/>
ctable width="100%" boEder=,rl"> <tr> <td>
<phpp: block. name="Haterialsbi3t" highlightGroup=,rtop_highlights"> <phpp:block name="PollFoEm" profИе="Индекс сайта">
</td> <td>
<phpp:block name="IlaterialsList'r temp 1 ate=,rshort" rubric="/news/" show="5">
</td> </tr> </table>
Базовый шаблон (обертка для шаблонов страниц сайта):
<phpp:include name="heade г.html"/>
Ctable width="100%" border="l"> <tr>
<td width='r200"Xphpp: block name="Henu'7></td> <td><core:placeholder id="Content"/> </td> </tr> </table>
<phpp:include name="footer.html"/>
Хидер
<!D0CTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html> <head>
<title> </title> </head>
<body>
рчЗ>|<ИДЕР</ЬЗ>
С! — Блок в инклуде —> <phpp:block name="Navigation"/>
Рис. 9. Примеры шаблонов сайта
Предлагаемая схема построения приложений использует синтез компонентного и портального построения приложений. Отличия «портального» подхода:
1. Предлагается единая схема разделения бизнес-логики от представления. В спецификации портлетов нет единого подхода к такому разделению, существует только распространенный подход использования системы Struts для создания портлетов.
2. Блоки имеют параметры.
3. С помощью специального блока могут создаваться портальные страницы, как в классическом портальном сервере.
Сущности организуются в списки или деревья (рис.10). Например, блок «Новости» считывает список данных сущностей «Новость» и генерирует на базе шаблона фрагмент. А блок «Меню» считывает дерево рубрик сайта и генерирует фрагмент с меню для текущей рубрики.
Рис. 10. Организация сущностей в списки и деревья
Класс блока, генерирующий содержание фрагментов, и другой код, взаимодействующий с БД, получает данные посредством «сущностей» (Entity), предоставляющих возможность управлять данными, используя объектно-ориентированный подход (ORM) (рис. 11).
Выбор уровня и данных для кэширования
Использование описанной схемы построения приложений позволяет организовать кэширование на уровне представления, уровне данных и уровне кода. Оценка выгоды от кэширования производится на основе вычисления времени, затрачиваемого на получение результатов запроса к БД или содержания блока при динамическом выполнении и при получении этих данных из кэша. Если выгоды от кэширования запроса к БД нет (кэширование производится на уровне фрагментов), то этот запрос кэшироваться не будет, и будет производиться кэширование только на уровне фрагментов. Выгода оценивается на основе частоты обращений к запросу, размера результата запроса и времени выполнения запроса. Так же разработаны алгоритмы «допуска»/замещения запросов к БД/фрагментов в кэш/из кэша.
Рис. 11. Алгоритм генерации фрагментов
Цель алгоритмов - минимизировать общее время выполнения запросов к БД/фрагментарной системе. Алгоритм замещения использует следующие параметры для каждого запроса/генерации фрагмента Я5Г:
Xi - средняя частота доступа к запросу (кол./ ед. времени);
Si - средний размер данных, получаемых по запросу;
Т - время выполнения запроса / генерации фрагмента;
Т = Tdbquery - Тиоув (для запроса к
БД);
Tdbquery - время выполнения запроса к
БД;
Тиоув - время сохранения запроса БД в
кэш;
Т = Tgenerоte - Тиоув (для фрагмента); Tgenerоte - время генерации фрагмента; Tsоve - время сохранения запроса БД в
кэш.
Алгоритм замещения ставит своей целью максимизировать отношение
' ПШ
^ TiRi '
i
где Hi - число раз, когда обращение к i-му динамическому объекту обработано из кэша;
Ri - общее количество обращений к объекту i.
Для достижения этой цели статистика собирается вместе в одну метрику, называемую Profit «Выгода»)
Profit (RSi) = (Xi * Ti) / Si .
Допустим, что динамический объект RSi с размером Si должен быть помещен в кэш и общая сумма свободного места в кэше меньше, чем Si.
Алгоритм замещения сортирует все записи в кэше в порядке возрастания выгоды от кэширования и выбирает кандидатов на выселение. Xi * Ti обозначает разницу во времени выполнения из-за кэширования RSi. Однако результат большего размера с одинаковым Ti должен быть выселен из кэша для того, чтобы в кэше могло поместиться больше записей.
Главная цель алгоритма допуска в кэш - предотвратить кэширование запросов / фрагментов, которые могут стать причиной увеличения времени отклика. Например, кэширование большого набора данных может выселить все остальное содержание кэша. Это может послужить причиной повторного выполнения запросов, которые занимали небольшое место в кэше.
В идеальном случае система должна кэшировать только те запросы к БД / фраг-
менты, которые увеличат общую выгоду от Хотя критерий допуска весьма прост,
кэширования. реализация может быть не столь проста.
rj, по. Например, не совсем ясно, как подсчиты-
То есть набор данных RSi кэшируется г г■>
вать среднюю частоту доступа Xi для новых
только в случае
записеи. Для этого в системе кэширования Profit (RSi) > Profit (С) , предусмотрено хранение статистики доступа
где С - множество кандидатов за заме- к ранее уДаленным записям. Пшт°му если щение (записей кэша). RSi был ранее кэширован, система кэшир°
вания может подсчитать Xi на основе остав-
У jj * Tj шейся информации. В случае, если запрос не
Profit (C) = —=-——. был ранее кэширован, система кэширования
Ущ&с S подсчитывает Xi на основе имеющихся дан-
ных Ti и Si.
Е-Profit (RSi) = Ti / Si
Алгоркшх «Д>схуп-1ФЕ1де1ое»
Вход: запрашиваемый набор данных /фрагмент RSi Si - размер RSi
Ti - время выполнения запроса / генерации фраггента Qi,
Соответствующего RSi Savail - доступюе место е кэще
Перетленные: Rli- статистика использование хранящая Еремя последних В обращении к RSi.
Xi -оценочное среднее время между обращениями к RSi подсчитанная га Rli
Выбор RSi е кэше: обновить Rli
RSi не в кэше и Savail > Si: Помеспггь RSi в кэш ОбюЕить Rli
RSi не в кэше и Savail < Si Доступ (RSi)
Алгоритм «Доступ»
Вход: запрашиваемый набор данных /фрагмент RSi С = Замещение (Si)
Если (имеется ранее сохраненная статистика доступа Rli) тогда Обновить Rli
Если (Profit (RSi) > Profit (С)) тогда Удалить га кэша все записи С, сохранив статистику доступа Поместить RSi в кэш Конец если Иначе
Разместить статистику доступа Rli Обновить Rli
Если (E-Profit (RSi) > E-Profit (С)) тогда Удалить га кэша все записи С, оохраниЕ статистику доступа Поместить RSi е кэш Конец если Конец если
Алгоритм «Замещение»
Вход: S- размер кэша, который должен быть освобожден
Выход: С - множество записей кэша, кандидатоЕ на удаление га кэша
Для i=l до К делать Ri - список записей кэша с i обращениями,
упорядоченные в порядке возрастания выгоды от кэширования Конец цикла
R - список всех записей кэша, упорядоченный е порядке Rl<R2<...<RJt
С = минимальное подмножество R, тагое что .. PSVc f ^J ~ ^ Вернуть С
Представленные в настоящей работе методы построения и кэширования веб-приложений показали целесообразность и эффективность своего использования. Система управления контентом, созданная на базе этих методов, успешно применяется
при создании различных сайтов в среде веб, ориентированных, в первую очередь, на интеграцию информационных ресурсов сферы образования, и имеет все предпосылки для дальнейшего развития.
Литература
1. Иванников А. Д., Тихонов А.Н. Основные положения концепции создания системы образовательных порталов //«Интернет-порталы: содержание и технологии». - Вып. 1 /Редколл..: А.Н. Тихонов (пред.) и др.; ГНИИ ИТТ «Информика». - М.: Просвещение, 2003. - С. 8-18.
2. Булгаков М.В., Носов В.П. Создание образовательных Интернет-порталов с использованием системы управления динамическим сайтом iPHPortal // Интернет-порталы: содержание и технологии. -Вып. 2 / Редколл.: А.Н. Тихонов (пред.) и др.; ГНИИ ИТТ «Информика». - М.: Просвещение, 2004. - С. 320345.
3. Фаулер М. Архитектура корпоративных программных приложений. - М.: Изд. дом «Вильямс», 2006. - 540 с.
4. Методы оптимизации хранения и обработки объектов в реляционных базах данных. Электронный Интернет-журнал «Инженерное образование»,10/2007.
5. Валиков А. Технология XSLT. - СПб.: БХВ, 2002. - 544 с.
6. Компонентная система Tapestry [http://tapestry.apache.org/].
7. Rabinovich М., Spatscheck О. Web Caching and Replication. Addison Wesley, 2001.
8. Таха Х. А. Введение в исследование операций. - М.: Изд. дом «Вильямс», 2001. - 910 с.
ФОРМИРОВАНИЕ И КОНТРОЛЬ ПРОФЕССИОНАЛЬНЫХ КОМПЕТЕНТНОСТЕЙ СТУДЕНТОВ ПО НАПРАВЛЕНИЮ ПОДГОТОВКИ «ЭКОНОМИКА»
М.В. Воронов, д.т.н., проф., руководитель специализации Департамент качества образования Тел.: (495) 737-88-49, доб. 41-24; E-mail: [email protected] Г.В. Рябова, к.э.н., проф. каф. Тел.:(495) 737-88-49, доб. 41-58; E-mail: [email protected] В.Н. Фокина, к.социол. н., доц., проректор Тел.: (495) 737- 88-49, E-mail: [email protected] Негосударственное образовательное учреждение «Современная гуманитарная академия» http://www.muh.ru
The article deals with the transition of the higher education to ad hoc approach. The author offers special methods and tools for training and developing of the special aptitude heavily involved in distance education.
«Концепция модернизации российского образования на период до 2010 года» в качестве приоритетного формулирует подход, направленный на развитие всех аспектов компетентности выпускника вуза.
Под компетентностью (в данном случае профессиональной) мы понимаем способность применения своих личных возможностей в процессе профессиональной деятельности, готовность к исполнению своей профессиональной роли. При этом следует осо-
бо подчеркнуть, речь идет о деятельности в реальных постоянно изменяющихся условиях.
В настоящее время интенсивная деятельность образовательного сообщества по проблеме компетентностно-ориентирован-ного подхода обусловлена, главным образом, стремлением подготовить выпускника, способного сразу же после окончания вуза приступить к исполнению своих профессио-
