1. Правила обращения к объекту называют политикой активизации. Прежде чем обратится к объекту, часто его надо поместить в адресное пространство сервера, то есть активизирован. Удаленный клиент не знает, что делается на сервере. И здесь возникает проблема: объект нужно подготовить перед обращением.
2. Эта предварительная подготовка для разных объектов разная. Необходимо как-то сгруппировать объекты в соответствии с политикой активизации. Это механизм группирования – адаптер объекта. Адаптер объекта готовит объект, чтобы к нему можно было обратится. Нельзя сказать, что эту кусок сервера объекта, это функциональность.
3. Адаптер объектов является общедоступным для разработчиков распределенных объектов.
Если несколько объектов с разной политикой активизации, то на каждую группу с одинаковой политикой активизации надо иметь адаптер активизации. И у сервера эти адаптеры есть. Есть еще промежуточное звено, когда запрос сначала поступает к АО, а затем куда требовалось. Тогда схема такая –
Диспетчеризация запросов.
Рис. 3.5.
То есть сначала запрос переадрисовывается к соотв. АО. АО смотрит, к какому obj идет запрос, если obj не активен, то АО его активизирует. Только после этого запрос передается к соотв. заглушки объекта. Тут уже надо распаковать параметры и она смотрит к какому методу запрос. А дальше понятно.
Объект, прежде чем вызвать нужный запрос, он должен выполнить диспетчеризацию операций – действия по организации вызова конкретного метода.
Адаптер перед передачей запроса должен активизировать obj. Информацию о том, как запустить данный obj, АО получает из репозитария реализации (реестр).
Внимание: АО не знает ничего об интерфейсах объектов. Это не его инфорамция. Его назначение – извлечь из запроса ссылку на объект и активизировать в соотв. с политикой активизации. После этого он передает запрос соотв. заглушке объекта, которая затем производит деморшалинг(распаковку параметров) и она осуществляет вызов.