Модели и алгоритмы взаимодействия приложений в распределённых системах с архитектурой публикация/подписка

• Автор: Антипов, Олег Владимирович
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2015
• Место защиты: Рязань
• Количество страниц: 255 с. : ил.

ОГЛАВЛЕНИЕ
ВВЕДЕНИЕ
ГЛАВА 1. АНАЛИЗ И ОБОСНОВАНИЕ ИНТЕГРАЦИОННЫХ РЕШЕНИЙ ДЛЯ РАСПРЕДЕЛЁННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ ОБМЕНА СООБЩЕНИЯМИ

1.1. Задачи интеграции

1.1.1. Необходимость интеграции

1.1.2. Типы интеграционных задач

1.1.3. Проблемы интеграции

1.1.4. Обеспечение слабого связывания

1.2. Способы интеграции

1.2.1. Критерии интеграции приложений

1.2.2. Передача файлов
1.2.3. Общая база данных
1.2.4. Удалённый вызов процедур
1.2.5. Обмен сообщениями
1.3. Системы обмена сообщениями
1.3.1. Построение систем обмена сообщениями
1.3.2. Архитектура Публикация/Подписка
1.4. Анализ и выбор механизма уведомления
1.4.1. Выбор на основе канала
1.4.2. Выбор на основе темы
1.4.3. Выбор на основе содержимого
1.5. Маршрутизация на основе содержимого
1.5.1. Простая маршрутизация
1.5.2. Маршрутизация на основе покрытия
1.5.3. Использование Рекламных объявлений
1.6. Задачи исследования
1.7. Выводы

ГЛАВА 2. РАЗРАБОТКА ФОРМАЛЬНОЙ СПЕЦИФИКАЦИИ СИСТЕМ ПУБЛИКАЦИЯ/ПОДПИСКА
2.1. Интерфейс системы Публикация/Подписка
2.2. Спецификация на основе следа
2.3. Поведение систем Публикация/Подписка
2.4. Модель системы Публикация/Подписка
2.5. Конфигурация маршрутизации
2.5.1. Переадресация уведомлений: таблицы маршрутизации
2.5.2. Статическая система Публикация/Подписка:
допустимая маршрутная конфигурация
2.5.3. Динамическая система Публикация/Подписка:
слабо допустимая маршрутная конфигурация
2.6. Самостабилизирующаяся система Публикация/Подписка
2.6.1. Самостабилизиругоїциеся системы
2.6.2. Самостабилизирующаяся система Публикация/Подписка
2.7. Система Публикация/Подписка с рекламными объявлениями
2.8. Выводы
ГЛАВА 3. МАРШРУТИЗАЦИЯ СООБЩЕНИЙ НА ОСНОВЕ СОДЕРЖИМОГО
3.1. Обобщённая структура алгоритмов маршрутизации
3.2. Алгоритмы маршрутизации
3.2.1. Алгоритм с "наводнением"
3.2.2. Простая маршрутизация на основе фильтров
3.2.3. Маршрутизация на основе идентичности фильтров
3.2.4. Маршрутизация на основе покрытия фильтров
3.2.5. Маршрутизация на основе объединения фильтров
3.3. Маршрутизация с рекламными объявлениями
3.4. Обеспечение самостабилизации
3.4.1. Предположения об отказах
3.4.2. Аренда записей маршрутной таблицы
3.4.3. Условия выбора и прекращения срока аренды
3.4.4. Самостабилизация алгоритмов маршрутизации
3.4.5. Время стабилизации
3.5. Выводы

ГЛАВА 4. РЕАЛИЗАЦИЯ СИСТЕМ ОБМЕНА СООБЩЕНИЯМИ
НА ОСНОВЕ АРХИТЕКТУРЫ ПУБЛИКАЦИЯ/ПОДПИСКА
4.1. Инфраструктура сервиса уведомлений Rebeca
4.1.1. Общая архитектура
4.1.2. Использование алгоритмов маршрутизации
4.1.3. Механизм воспроизведения уведомлений
4.1.4. Концепция фабрик сервисов
4.1.5. Основные классы
4.2. Использование инфраструктуры сервиса уведомлений Rebeca
4.2.1. Реализация события
4.2.2. Реализация потребителя
4.2.3. Реализация поставщика
4.2.4. Реализация журнала
4.2.5. Реализация фабрики
4.2.6. Запуск маршрутизатора
4.2.7. Процедура использования
4.3. Примеры приложений
4.3.1. Самообновляющиеся веб-страницы
4.3.2. Торговля акциями
4.3.3. Виртуальная медицинская организация
4.4. Выводы
ГЛАВА 5. АНАЛИЗ РЕАЛИЗУЕМЫХ АЛГОРИТМОВ
МАРШРУТИЗАЦИИ
5.1. Общие настройки
5.1.1. Брокерская топология
5.1.2. Характеристики потребителей
5.1.3. Характеристики производителей
5.2. Размеры таблиц маршрутизации
5.2.1. Простая маршрутизация
5.2.2. Простая маршрутизация с объявлениями
5.2.3. Маршрутизация на основе идентичности фильтров
5.2.4. Маршрутизация на основе идентичности с объявлениями

Необходимость преобразования данных обусловлена наличием у приложений различных концептуальных моделей, т. е. семантическим диссонансом. В отличие от общей базы данных, обмен сообщениями не предполагает использования специальных средств для его устранения. Это связано с тем, что семантический диссонанс неизбежно возникает при добавлении к интеграционному решению новых приложений (например, в результате слияния информационных систем взаимодействующих компаний).
Частый обмен небольшими порциями данных создает предпосылки для использования приложениями общей функциональности. Если получение сообщения о размещении нового заказа требует выполнения некоторых действий, они могут быть инициированы путем отправки специальных сообщений. Несмотря на то, что скорость подобного взаимодействия ниже, чем при использовании удаленного вызова процедуры, вызывающей стороне не приходится ждать ответа на отправленное сообщение. На самом деле обмен сообщениями не такой уж и медленный — достаточно большое число систем обмена сообщениями используются финансовыми организациями для обработки тысяч котировок акций в секунду.
Вместе с тем не стоит забывать, что обмен сообщениями далеко не идеален. Отметим некоторые из присущих ему недостатков. Несмотря на то, что высокая частота отправки сообщений существенно снижает вероятность рассогласования данных, присущего передаче файлов, она не позволяет полностью исключить задержку при доставке информации. Большинство разработчиков не привыкли к "асинхронному" способу мышления, результатом чего стало появление множества различных правил и приемов программирования. Кроме того, решения, основанные на обмене сообщениями, сложнее тестировать и отлаживать.
Возможность преобразования сообщений позволяет обеспечить гораздо более слабую связность приложений, чем этого можно было бы достичь с помощью удаленного вызова процедуры. Вместе с тем подобная независимость означает дополнительную нагрузку на разработчиков интеграционного решения, которым приходится решать новые задачи и создавать множество строк связующего программного обеспечения.