Методы и средства разработки компонентного управления Web - сайтом на основе динамической объектной модели

• Автор: Быков, Михаил Юрьевич
• Шифр специальности: 05.13.01
• Научная степень: Кандидатская
• Год защиты: 2005
• Место защиты: Москва
• Количество страниц: 183 с. : ил.

1.1. Требования к платформам приложений серверной стороны.

1.2. Классификация платформ приложений серверной стороны

1.2.1. Фильтры УеЬ сервера.

1.2.2. Обработчики запросов.

1.2.3. Модель шаблонов страниц Модель 1.

1.3. Сравнительный анализ существующих платформ.

1.4. Системы создания и управления сайтами

1.4.1. Интерактивные формы

1.4.2. Системы оперативного управления сайтом.

1.4.3. Системы типа Модель Вид Управление Модель

1.5. Требования к системам создания и управления сайтами

Выводы по главе
Глава 2. Исследование и разработка компонентной модели управления сайтами, формализация процесса обработки запросов.
2.1. Компонентная модель управления сайтами.
2.2. Реализация архитектуры Модель Вид У правление
2.3. Инструмщггальные средства визуализации управления сайтом.
2.4. Задачи оптимизации кода, кластеризации, кэширования
2.5. Формализация процесса обработки запросов. Модель системы частичного
кэширования динамических страниц.
2.5.1. Формализация процесса обработки запросов системой управления
сайтами.
2.5.2. Математическая модель системы частичного кэширования динамических
страниц. Оценка эффективности частичного кэширования
Выводы по главе
Глава 3. Аспекты практической реализации программного комплекса управления сайтами ПКУС
3.1. Архитектура системы управления сайтами
3.1.1. Структура системы управления сайтами. Определение базовых
сущностей
3.1.2. Разработка динамической модели управления сайтами. Алгоритм
генерации страниц. Использование и настройка компонент.
3.1.3. Взаимодействие компонент. Общий контекст исполнения.
3.1.4. Взаимодействие страниц. Вложенные формы
3.1.5. Перенос и обновление сайтов
3.1.6. Расширения ПКУС. Встраиваемые модули.
3.2. Аспекты безопасности. Разграничение прав доступа пользователей.
3.3. Уровень абстракции по поддержке СУБД.
3.4. Подсистемы кэширования ПКУС
3.5. Визуальное редактирование страниц. Среда администрирования.
Выводы по главе 3.
Глава 4. Верификация полученных решений и практическая реализация ПКУС .
4.1. Портируемость решения
4.2. Анализ производительности системы. Тестовая конфигурация.
4.2.1. Аппаратная тестовая конфигурация.
4.2.2. Операционные системы, использованные при тестировании
4.2.3. Тестируемые платформы приложений.
4.2.4. Проведенные тесты производительности.
4.3. Результаты тестирования платформ и ПКУС
Выводы по главе
Заключение.
Список литерату


Также, у всех этих приложений одинакова архитектура высокого уровня взаимодействия сервера и клиента и общий протокол взаимодействия . Общая логика работы приложения серверной стороны представлена на Рис. Рис. Архитектура работы приложений серверной стороны. Запрос. Клиент, используя браузер, инициирует запрос к серверу. Такой запрос может быть инициирован и самим приложением, например, клиентским скриптом исполнения vi . Запрос содержит определенную информацию о клиенте и требуемом ресурсе, как то универсальный адрес ресурса iv i , данные о клиенте тип браузера, разрешение монитора, локальные файлы данных приложений i, и другие. Передача данных между клиентом и сервером происходит по протоколу , который обеспечивает платформо независимый обмен данными. Обработка запроса, подготовка ответа. Если же запрашивается динамический ресурс, запрос приложению, где и происходит дальнейшая работа. При своей работе приложение может использовать внешние ресурсы, такие как база данных, файловая система, другие сервера. Поскольку приложение действует на серверной стороне, оно не имеет ограничений по безопасности, свойственных приложениям стороны клиента, таких как запрет на работу с файловой системой, установление сетевых соединений. Следовательно, приложение серверной стороны может быть написано максимально эффективно, и привлекать все необходимые средства. После формирования данные передаются клиенту посредством протокола в качестве ответа. Ответ содержит данные обычно код, либо двоичные данные, дополнительные параметры, передаваемые в заголовках II ответа, а также может содержать данные для файлов i небольшие текстовые файлы, хранящиеся на компьютере клиента. Очевидно, что такой подход создает сложности при создании приложений, основной из которых является отсутствие состояния у приложения так называемое i, архитектура таких приложений рассматривается в . Это означает, что приложение работает исключительно в режиме запросответ, не имея непосредственных данных о предыдущих шагах пользователя или какойлибо иной постоянной информации. Для решения этой проблемы применяется понятие пользовательской сессии, которая позволяет хранить данные на сервере в течение сеанса работы пользователя. Файлы i. Сохраняются на компьютере клиента, хранят небольшие объемы информации, содержащие установки пользователя, либо идентифицирующие его, а также использующиеся для хранения идентификационного номера сессии пользователя. При отключенной поддержке i номер сессии может передаваться в строке . Приложение серверной стороны нс может существовать отдельно, поскольку необходим механизм передачи управления ему от сервера, а также механизмы обмена данными между сервером и приложениями. Эти механизмы предоставляются платформой приложений серверной стороны платформой приложений. Платформа приложений осуществляет связь между сервером и приложениями, предоставляет высокоуровневые функции работы с данными для приложений, а, зачастую, и собственный язык программирования приложений. Часто такие платформы также называются контейнерами приложений, поскольку содержат и управляют приложениями. Различные механизмы взаимодействия приложений и сервера, а также принципы и особенности построения приложений подробно рассматриваются в . Составляющие могут быть пустыми при обработке запросов, не требующих участия приложений или сторонних приложений. УеЬ сервер, несколько платформ УеЬ приложений, а также набор УеЬ приложений и используемых сторонних приложений. Таким образом мы можем определить УсЬ систему, как совокупность всех ВОЗМОЖНЫХ СОСТОЯНИЙ Як для одного сервера, а распределенную ШеЬ систему, как совокупность всех возможных состояний для всех серверов, входящих в систему. В данной диссертации рассматривается и подразумевается в дальнейшем изложении одиночная УсЬ система. Взаимодействие между клиентом и сервером может включать или не включать УсЬ приложение. СС С,С, 1. УеЬ приложение, а не УеЬ сервер, поэтому даже при одинаковом объеме данных в 1вш, хотя при достаточно сложных запросах можно считать разницу между ними пренебрежимо малой.