Исследование методов и программных средств построения распределенных информационных систем

• Автор: Лвин Маунг Со
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2013
• Место защиты: Москва
• Количество страниц: 156 с. : ил.

Содержание
Введение.

1. Архитектура распределенных информационных систем РИС

1.1. Характеристики РИС

1.1.1. Отказоустойчивость.

1.1.2. Открытость.

1.1.3. Прозрачность.

1.1.4. Масштабируемость.

1.1.5. Безопасность.

1.2. Архитектуры программного обеспечения распределнных информационных систем

1.2.1. Базовая модель клиентсервер.

1.2.2. Сервисориентированная архитектура БОА.
1.3. УеЬсервис.
Выводы по 1й главе
2. Распределенные базы данных РБД
2.1. Основные принципы, правила построения и функционирования РБД
2.2. Проблемы при проектировании распределенных баз данных
2.3. Проектирования распределенных баз данных
2.3.1. Нисходящие проектирование
2.3.2. Восходящее проектирование
2.4. Фрагментация данных.
2.5. Репликация данных.
2.6. Управление распределенными транзакциями.
Выводы по 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.4. Проектирование РИС Му еЫЬгагу на основе А.
3.4.1. Разделение подсистем.
3.4.2. Проектирование РБД.
3.4.3. Проекгироваиие сервисов
3.4.4. Реализация сервисов
3.4.5. Интеграция и обеспечение безопасности сервисов.
Выводы по 3й главе
4. Описание информационной системы Му еУЬгагу
4.1. Использованные технологии
4.1.1. . V3.
4.1.2. . i .
4.1.3. i ii i .
4.2. Структура информационной системы Му i.
4.2.1. Подсистема i .
4.2.2. Подсистема ii .
4.2.3. Подсистема i
4.2.4. Подсистема Му i
Модель информационного поиска.
4.3. Реализация сервисов
4.3.1. Создание контрактов
4.3.2. Выбор подходящей привязки
4.3.3. Определение конечных точек
4.3.4. Размещение сервисов.
4.4. Реализация приложение Му i .
4.4.1. Создание моделей
4.4.2. Создание котроллеров
4.4.3. Создание Представлений Vi
4.4.4. Подготовка к взаимодействию с сервисами
4.5. Преимущества РИС Му i .
Выводы по 4й главе
Заключение
Список литературы


Поломка (crash failure) имеет место при внезапной остановке сервера, при этом до момента остановки он работал нормально. Важная особенность поломки состоит в том, что после остановки сервера никаких признаков его работы не наблюдается. Пропуск данных (omission failure) возникает в том случае, когда сервер неправильно реагирует на запросы. Эту ошибку могут вызывать различные причины. В случае пропуска приема (receive omission) сервер может, например, не получать запросов. Отмстим, что такая ошибка может произойти, в частности, и в том случае, когда соединение между клиентом и сервером установлено правильным образом, но на сервере не запушен процесс для приема приходящих запросов. Пропуск приема обычно не влияет на текущее состояние сервера, по сервер остается в неведении о посланных ему сообщениях. Подобная ошибка может произойти, например, при переполнении буфера передачи, если сервер не готов к подобной ситуации. Отметим, что в противоположность пропуску приема в данном случае сервер может перейти в состояние, соответствующее полному выполнению услуги для клиента. Впоследствии, если обнаружи тся, что имел место пропуск передачи, сервер, вероятно, должен быть готов к тому, что клиент повторно пошлет свой последний запрос. Другие типы пропусков не имеют отношения к взаимодействию и могут быть вызваны ошибками в программе, такими как бесконечные циклы или некорректная работа с памятью, которые способны «подвесить» сервер. Следующий класс ошибок связан с синхронизацией. Ошибки синхронизации (timing failures) возникают при ожидании ответа дольше определенного временного интервала. Слишком раннее предоставление данных легко может вызвать у принимающей стороны проблемы, связанные с отсутствием места в буфере для хранения получаемых данных. Чаще, однако, сервер отвечает слишком поздно, в этом случае говорят, что произошла ошибка производительности (performance failure). Еще один важный тип ошибок — ошибки отклика (response failures), при которых ответы сервера просто неверны. Существует два типа ошибок отклика. В случае ошибки значения (value failure) сервер дает неверный ответ на запрос. Так, например, эту ошибку демонстрирует поисковая машина, систематически возвращающая адреса web-страниц, не связанных с запросом пользователя. Другой тип ошибок отклика — ошибки передачи состояния (state transition failures). Этот тип ошибок характеризуется реакцией на запрос, не соответствующей ожиданиям. В частности, сервер может неправомерно осуществить по умолчанию некие действия, производить которые в данном случае не следовало бы. Весьма серьезны произвольные ошибки (arbitrary failures), известные также под названием византийских ошибок. Когда случается произвольная ошибка, клиент должен приготовиться к самому худшему. Например, может оказаться, что сервер генерирует сообщения, которые он в принципе не должен генерировать, но система не опознает их как некорректные. Хуже того, неправильно функционирующий сервер может, участвуя в работе группы серверов, приводить к появлению заведомо неверных ответов. Эта ситуация показывает, почему для надежных систем очень важна защита. Произвольные ошибки похожи на поломки. Поломка — наиболее распространенная причина остановки сервера. Поломки известны также под названием ошибок аварийной остановки (fail-stop failures). В действительности аварийно остановленный сервер просто прекращает генерировать исходящие сообщения. По этому признаку его остановка обнаруживается другими процессами. Например, по настоящему дружественный сервер может предупредить нас о том, что находится на грани поломки. Разумеется, в реальной жизни серверы, останавливаясь но причине пропуска данных или поломок, не настолько дружественны, чтобы оповестить нас о надвигающейся остановке. Другие процессы должны сами обнаружить «безвременную кончину» сервера. Однако в подобных системах остановки без уведомления (fail-silent systems) другие процессы могут сделать неверный вывод об остановке сервера. Сервер может просто медленно работать, то есть может иметь место ошибка производительности.