2.3 Нефункциональные требования к рсои
Требования бывают: функциональные и нефункциональные.
Функциональные - поддаются локализации при реализации
Нефункциональные - относятся к качеству системы - носят глобальный характер и оказывают существенное влияние на выбор общей архитектуры системы на этапе проектирования:
Масштабируемость
Способность системы адаптироваться к будущему росту нагрузки. Проблемы: узкие места по обслуживанию (один сервер для множества клиентов), по данным (один файл с общей информацией), по алгоритмам (централизованный алгоритм и перегрузка коммуникационной сети). Свойства децентрализованных алгоритмов:
· Никто не обладает полной информацией о системе
· Решения принимаются на основе лекальной информации
· Сбой в одном месте не вызывает нарушения работы алгоритма
· существования единого времени не требуется
· Прозрачность (в следующем билете)
Открытость
Систему можно легко расширять и модифицировать (интеграция новых компонентов, отвечающих новым функциональным требованиям => компоненты должны иметь четко определенные интерфейсы) Правильный интерфейс обеспечивает возможность правильной совместной работы одного процесса с другим, представляющим интерфейс. Самодостаточность и нейтральность. Переносимость характеризует, насколько приложение, сделанное для одной системы, может работать в составе другой. Способность к взаимодействию характеризует, насколько две разные реализации системы в состоянии работать совместно.
Гибкость - легкость конфигурирования системы, состоящей из различных компонентов, и легкость подключения новых компонентов.
Неоднородность
В распределенных системах, компоненты должны объявлять о предлагаемых услугах. Заявки могут быть синхронными/асинхронными. Клиент и сервер могут быть неоднородными. Причины неоднородности:
· Компоненты могут приобретаться в готовом виде
· При создании нового компонента, на него могут накладываться требования взаимодействия с существующими компонентами
· Компоненты создаются разными разработчиками
· Используются различные технологии
Разделение ресурсов
Ресурс - аппаратура, ПО, данные. Требуется определить, кому будет разрешен доступ к ресурсу => требуется вести учет пользователей. Менеджер ресурсов - компонент, предоставляющий доступ к разделяемым ресурсам.
Модели взаимодействия:
· Клиент-серверная (сервер предоставляет доступ к ресурсам)
· Концепция распределенных объектов, предоставляющих доступ к имеющимся у них ресурсам при обращении других компонентов
Отказоустойчивость
Система может продолжать работу даже в случае неисправности => избыточность => применение репликации (при отказе компонента, начинает работать его копия и обслуживание не прекращается)
2.4 Прозрачность в РСОИ
Имеет несколько различных аспектов:
1. Прозрачность масштабируемости (обеспечивается 4, 5) - программист не должен знать, как достигается масштабируемость распределенной системы.
2. Прозрачность производительности (обеспечивается 4, 5) - пользователь и программист не знают, как поддерживается хорошая производительность.
3. Прозрачность отказа (обеспечивается 5, 6) - пользователям и программистам не требуется знать, как ВС справляется с отказами.
4. Прозрачность миграции (обеспечивается 7, 8) - перемещение компонентов незаметно для пользователей и без специальных действий со стороны разработчиков этих компонентов
5. Прозрачность репликации (обеспечивается 7, 8) - пользователям и разработчика не требуется знать, кто предоставляет услугу - реплика или основной компонент. Разработчики компоненты не должны учитывать возможность его репликации
6. Реплика - копия, которая остается синхронизированной с оригиналом
7. Прозрачность одновременного выполнения. Означает, что пользователи программы не знают, что компоненты запрашивают услуги одновременно. Несколько компонентов могут запрашивать обслуживание одновременно с сохранением его услов-ти. Пользователи и разработчики не видят, как организуется одновременно обслуживание.
8. Прозрачность доступа - одинаковость интерфейсов для локальной и удаленной связи (интерфейс заявки на обслуживание должен быть одним и тем же для связи между компонентами одного хоста и разных хостов)
9. Прозрачность местонахождения - способ вызова операции не зависит от местонахождения компонента (запрашивающему обслуживание объекту не требуется знать о физическом расположении компонента). Клиент не должен знать о местонахождении компонента или его реплики.
2.5 Удаленный вызов процедуры: общие сведения
Есть машины: A и B. A вызывает процедуру, которая выполняется на B.
count = read(fd, buf, bytes);
Стек при вызове процедуры:
bytes
buf
fd
адрес возварата
локальные переменные
Передавать параметры по значению просто, а вот по ссылке - проблема. Вызов через клонирование восстановлением. Удаленный вызов выглядит как локальный, то есть RPC обеспечивает прозрачность для клиента. Сервер тоже не подозревает, что он выполняет удаленный вызов.
На сервере есть аналогичная заглушка; сервер выполняет запрос, возвращает результат. Проблема: передача по адресу. Решение: можно предавать копию буфера.
Последовательность передачи управления при RPC: