Передача параметров при обращении к удаленным объектам

 

Статическое удаленное обращение к методам (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.

 

Серверы объектов

 

Серверы объектов (СО) – серверы, ориентированные на поддержку распределенных объектов. СО (в отличие от традиционных серверов) НЕ предоставляет конкретные службы, т.к. конкретные службы реализуются объектами, расположенными на сервере. СО предоставляет только средства обращения к объектам, основанные на запросах от удаленных клиентов.

Активизация объекта – перемещение объекта в адресное пространство сервера (например, десериализация). Правила обращения к объектам – политика активизации. Требуется механизм группировки объектов в соответствии с политикой активизации каждого из них. Этим механизмом является адаптер объектов. Чаще всего он скрыт в наборе средств построения СО. Каждый адаптер объектов контролирует 1 или несколько объектов. При получении запроса к одному из контролируемых объектов адаптер проверяет его состояние и при необходимости активизирует в соответствии с политикой активизации. После этого запрос передается к заглушке (скелетону) объекта, которая производит демаршаллинг (распаковку параметров) и осуществляет вызов метода. Адаптер ничего не знает об интерфейсах объектов.

 

 

Перенос кода в РСОИ

 

Перенос кода необходим для:

· перераспределения нагрузки между узлами для повышения производительности;

· снижения трафика клиент-серверного взаимодействия.

У задачи выделяют следующие сегменты:

· сегмент кода – команды;

· сегмент исполнения – контекст задачи;

· сегмент ресурсов – ресурсы.

Модели переноса кода:

Минимальные требования для переноса кода предъявляет модель слабой мобильности – перенос только сегмента кода. Поэтому программа всегда выполняется из своего исходного состояния. Пример: Java Applet.

В модели сильной мобильности переносится сегмент кода и сегмент исполнения. Процесс приостанавливается, переносится и запускается на другом узле. Пример: мультиагентная платформа.

Типы связи процесса с ресурсом:

Процесс передает в точности тот ресурс, на который ссылаются аргументы (наиболее сильная связь);

Более слабая связь - процессу нужно только значение;

Наиболее слабая форма связи – процесс указывает лишь на использование ресурса определенного типа.

Программный агент.

Автономный процесс, способный реагировать на среду исполнения и вызывать в ней изменения, возможно в кооперации с другими агентами (кооперативные агенты) и пользователем. Агент может функционировать автономно, в том числе проявлять инициативу. В мультиагентной системе фигурируют кооперативные агенты, решающие общую задачу.

 

Модель клиент-сервер

 

Серверы – процессы, реализующие службы и предоставляющие к ним доступ.

Клиенты – процессы, использующие эти службы.

Рассмотрим на примере доступа к БД:

При трехуровневой организации системы имеем следующие логические уровни:

· Пользовательский интерфейс (ПИ на рисунке).

· Обработки (О).

· Данных (непосредственная работа с БД).

Варианты физического разделения уровней между узлами:

 

 

На этом рисунке клиент «утолщается» слева направо.

Взаимодействие клиента с сервером происходит следующим образом:

 

2.12 Общие сведение об именовании объектов и службе именования

 

Именование – способ определения местонахождения распределенных объектов, при котором осуществляется управление пространствами имен, представляющими собой наборы связей между именами объектов и ссылками на них.

Контекст именования – последовательность простых имен, идентифицирующая объект. Например “UEFA”, “England”, “Premier”, “Chelsea”.

 

Операции:

 

Связывание – регистрация объекта-сервиса по имени и объектной ссылке. Используется при добавлении нового объекта в систему или при перемещении / копировании существующего объекта.

Разрешение – получение ссылки на объект по его имени. Используется клиентом для получения доступа к методам объекта.

Размещение мобильных сущностей.

Мобильные сущности – это те объекты, которые могут гулять по разным хостам. В этом случае пространство имен удобно разбить на 3 уровня:

· Глобальный

· Административный

· Управленческий

В 1 и 2 помещаются объекты, которые перемещаются относительно редко. Здесь эффективно кэширование путей.

В 3 объекты гуляют часто, и для них используется следующая система:

 

По имени объекта служба именования определяет его идентификатор, затем служба локализации по ид находит его физический адрес.