3.5.2Динамическое обращение
Иногда удобнее собрать параметры обращения к методу в процессе исполнения. Этот процесс – динамическое обращение. Когда неизвестно, к какому методу будет обращение.
invoke (object, method, input inparam, out outparam);
Передача параметров
Используются ссылки на объекты, как параметры, которые передаются при обращении к удаленному объекту: по значению. Если ссылка возвращается: клиент получил ссылку, прежде чем обратится, он осуществляет привязку. Есть нюанс. Объект, ссылка на который передается:
находится в адресном пространстве клиента
находится удаленно
Они реализуются по-разному. Ссылка передается только для удаленных объектов. А если объект локальный, то передается копия объекта.
Передача объектов.
Рис. 3.12.
При удаленном вызове фигурирует ссылки O1, O2 и при этом осуществляется копирование O1 и передачи ссылки на O2. Это все спрятано.
3.5.3Сервер объектов
~ - это сервер, ориентированный на поддержку распределенных объектов. Он предоставляет конкретной службы. Конкретные службы реализуются на сервере, реализуемые объектами. Сервер предоставляет только средства обращения к локальным объектам на основе запросов от удаленных клиентов. Фактически сервер выступает как место для хранения объектов. Как следствие, то легко добавлять новые службы: добавляется новый объект.
3.5.4Адаптер объекта
Правила обращения к объекту называют политикой активизации. Прежде чем обратится к объекту, часто его надо поместить в адресное пространство сервера, то есть активизирован. Удаленный клиент не знает, что делается на сервере. И здесь возникает проблема: объект нужно подготовить перед обращением.
Эта предварительная подготовка для разных объектов разная. Необходимо как-то сгруппировать объекты в соответствии с политикой активизации. Это механизм группирования – адаптер объекта. Адаптер объекта готовит объект, чтобы к нему можно было обратится. Нельзя сказать, что эту кусок сервера объекта, это функциональность.
Адаптер объектов является общедоступным для разработчиков распределенных объектов.
Если несколько объектов с разной политикой активизации, то на каждую группу с одинаковой политикой активизации надо иметь адаптер активизации. И у сервера эти адаптеры есть. Есть еще промежуточное звено, когда запрос сначала поступает к АО, а затем куда требовалось. Тогда схема такая –
Диспетчеризация запросов.
Рис. 3.13.
То есть сначала запрос переадрисовывается к соотв. АО. АО смотрит, к какому obj идет запрос, если obj не активен, то АО его активизирует. Только после этого запрос передается к соотв. заглушки объекта. Тут уже надо распаковать параметры и она смотрит к какому методу запрос. А дальше понятно.
Объект, прежде чем вызвать нужный запрос, он должен выполнить диспетчеризацию операций – действия по организации вызова конкретного метода.
Адаптер перед передачей запроса должен активизировать obj. Информацию о том, как запустить данный obj, АО получает из репозитария реализации (реестр).
Внимание: АО не знает ничего об интерфейсах объектов. Это не его инфорамция. Его назначение – извлечь из запроса ссылку на объект и активизировать в соотв. с политикой активизации. После этого он передает запрос соотв. заглушке объекта, которая затем производит деморшалинг(распаковку параметров) и она осуществляет вызов.