Распределенные системы обработки информации (стр. 5 из 7)
9. Прозрачность местонахождения – способ вызова операции не зависит от местонахождения компонента (запрашивающему обслуживание объекту не требуется знать о физическом расположении компонента). Клиент не должен знать о местонахождении компонента или его реплики.
2.5 Удаленный вызов процедуры: общие сведения
Есть машины: A и B. A вызывает процедуру, которая выполняется на B.
count = read(fd, buf, bytes);
Стек при вызове процедуры:
| bytes |
| buf |
| fd |
| адрес возварата |
| локальные переменные |
Передавать параметры по значению просто, а вот по ссылке – проблема. Вызов через клонирование восстановлением. Удаленный вызов выглядит как локальный, то есть RPC обеспечивает прозрачность для клиента. Сервер тоже не подозревает, что он выполняет удаленный вызов.
На сервере есть аналогичная заглушка; сервер выполняет запрос, возвращает результат. Проблема: передача по адресу. Решение: можно предавать копию буфера.
Последовательность передачи управления при RPC:
2.6 Передача параметров при удаленном вызове процедур
При удаленном вызове процедур процесс на 1 узле вызывает процедуру процесса на 2 узле. Сложность заключается в том, что процессы работают в разных адресных пространствах (АП). При передаче параметров по значению это неважно, т.к. значение не зависит от АП, а при передаче по ссылке возникает проблема. Здесь можно использовать другой вариант передачи параметров (отсутствует в С) – копирование-восстановление.
Передача параметров по значению.
· Формируется пакет, содержащий имя процедуры и ее параметры;
· Сообщение принимается заглушкой-сервером;
· Заглушка на сервере формирует вызов процедуры (как локальной).
Клиентский процесс приостанавливает свою работу и ждет возвращение результата. При получении результата он продолжает работу.
Передача параметров по ссылке (копирование-восстановление).
Пример: чтение удаленного файла в массив.
Передать копию ссылки не представляется возможным, так как ссылка – это указатель в АП клиента, бессмысленно передавать ее копию. Вариант решения: можно поступить так: взять массив, на который показывает указатель, и передать копию этого массива. Все это помещается в сообщение, передаваемое на сервер. На сервере выделяется место под массив, ссылка на массив в АП сервера. Заглушка передает параметры серверному процессу, и он по всем правилам обращается к ОС и помещает результат в массив в своем АП. Заглушка упаковывает массив в сообщение и передает его на клиентскую заглушку с помощью ОС. Клиентская заглушка распаковывает это сообщение и помещает значения в тот массив, который находится в АП клиента. Клиентский процесс получает результат, как будто он обратился локально. Эта удаленность прозрачна для обоих.
Заглушки должны использовать один протокол, по которому они будут представлять встроенные типы. Если заглушки работают по одному и тому же протоколу, они будут различаться только интерфейсами на машинах.
Чтобы облегчить работу по созданию заглушек, используется язык определения интерфейсов. IDL – Interface Definition Language.
2.7 Организация распределенных объектов
Распределенный объект (РО) – такой объект, реализация которого располагается на сервере, а взаимодействие клиентов с ним происходит через определенный интерфейс.
В адресное пространство клиента загружается реализация этого интерфейса – заместитель (proxy). Клиент непосредственно взаимодействует именно с заместителем.
Процесс формирования интерфейса и заместителя – привязка клиента к РО. Системы с РО предоставляют ссылки на объекты, уникальные в пределах системы. Такие ссылки могут передаваться между процессами, запущенными на разных машинах. Виды привязки:
Неявная (автоматическая) – клиент прозрачно связывается с объектом в момент разрешения ссылки (это когда по имени объекта получаем ссылку на него).
Явная – клиент должен вызвать специальную функцию для привязки к объекту.
Адаптер объектов – механизм группирования объектов в соответствии с политикой их активизации. Контролирует один или несколько объектов.
Скелетон – образ клиента на сервере (заглушка сервера).
Клиент через заместителя вызывает определенный метод объекта и задает параметры этого метода. Заместитель формирует и упаковывает сообщение (маршалинг) и отправляет его на сервер. В этом сообщении содержится ссылка на объект, метод и значения параметров. Сервер получает сообщение, и передает его соответствующему скелетону. Скелетон распаковывает сообщение (демаршалинг) и непосредственно вызывает определенный метод объекта с заданными клиентом параметрами. Если предполагается, что метод что-нибудь возвращает, то скелетон упаковывает результат и отправляет его заместителю.
Сохранные и нерезидентные объекты
Сохранный – объект продолжает существовать, даже не находясь постоянно в адресном пространстве серверного процесса. То есть, объект всегда можно воссоздать из памяти независимо от наличия процесса.
Нерезидентный – существует, пока им управляет сервер. Когда сервер завершает работу, это объект прекращает существование.
Способы определения местонахождения РО
Именование – управление пространствами имен, представляющими собой наборы связей между именами объектов и ссылками на них.
Трейдинг – определение местонахождения объектов исходя из предоставляемых ими функций и качества обслуживания.
2.8 Передача параметров при обращении к удаленным объектам
Статическое удаленное обращение к методам (RMI).
При статическом обращении интерфейс удаленного объекта описывается с помощью IDL, т.е. интерфейс известен на этапе компиляции.
Пример: Описание интерфейса футболиста.
interface Player: Object {
typedef struct Date {
short day; short month; short year;
}
attribute string name;
readonly attribute Date Dob;
};
interface PlayerStore: Object {
exception IDNotFound();
short save (in Player);
Player load(in short id) raises (IDNotFound);
void print(in Player p);
}
При использовании статического обращения интерфейсы должны быть уже известны и при изменении интерфейса нужна перекомпиляция.
Динамическое удаленное обращение к методам.
При динамическом обращении интерфейс удаленного объекта заранее не известен. Параметры обращения к методу собираются в процессе выполнения. Заранее неизвестно, к какому методу будет обращение.
invoke (object, method, input inparam, out outparam);
Передача параметров.
Используются ссылки на объекты как параметры, которые передаются при обращении к удаленному объекту. Объект, ссылка на который передается:
· находится в адресном пространстве клиента;
· находится удаленно.
Они реализуются по-разному. Ссылка передается только для удаленных объектов. Если объект локальный, то передается копия самого объекта.
При удаленном вызове клиентом на машине А сервера на машине С осуществляется копирование объекта O1 и передача ссылки на объект O2.
2.9 Серверы объектов
Серверы объектов (СО) – серверы, ориентированные на поддержку распределенных объектов. СО (в отличие от традиционных серверов) НЕ предоставляет конкретные службы, т.к. конкретные службы реализуются объектами, расположенными на сервере. СО предоставляет только средства обращения к объектам, основанные на запросах от удаленных клиентов.
Активизация объекта – перемещение объекта в адресное пространство сервера (например, десериализация). Правила обращения к объектам – политика активизации. Требуется механизм группировки объектов в соответствии с политикой активизации каждого из них. Этим механизмом является адаптер объектов. Чаще всего он скрыт в наборе средств построения СО. Каждый адаптер объектов контролирует 1 или несколько объектов. При получении запроса к одному из контролируемых объектов адаптер проверяет его состояние и при необходимости активизирует в соответствии с политикой активизации. После этого запрос передается к заглушке (скелетону) объекта, которая производит демаршаллинг (распаковку параметров) и осуществляет вызов метода. Адаптер ничего не знает об интерфейсах объектов.
2.10 Перенос кода в РСОИ
Перенос кода необходим для:
· перераспределения нагрузки между узлами для повышения производительности;
· снижения трафика клиент-серверного взаимодействия.
У задачи выделяют следующие сегменты:
· сегмент кода – команды;
· сегмент исполнения – контекст задачи;
· сегмент ресурсов – ресурсы.
Модели переноса кода:
Минимальные требования для переноса кода предъявляет модель слабой мобильности – перенос только сегмента кода. Поэтому программа всегда выполняется из своего исходного состояния. Пример: Java Applet.
В модели сильной мобильности переносится сегмент кода и сегмент исполнения. Процесс приостанавливается, переносится и запускается на другом узле. Пример: мультиагентная платформа.
Типы связи процесса с ресурсом:
Процесс передает в точности тот ресурс, на который ссылаются аргументы (наиболее сильная связь);