9.1. Менеджеры сервантов

Если помните, мы начинали наши занятия с упоминания о менеджерах сервантов, задача которых активировать объекты в тот момент, когда к ним приходит запрос. Полезность данного компонента, появившегося одновременно с адаптером объектов POA, не подлежит сомнению. Как только объектов становится много, поддержание их в активном состоянии значительно увеличивает накладные расходы. Да и не факт, что все эти объекты будут востребованы в процессе работы, а если и будут, то придется проследить за их последующим удалением. Следовательно, отложенная активация и есть тот самый механизм, который позволит избежать ненужной нагрузки на информационные системы.

Спецификация CORBA 2.3 очень четко расписывает работу и составляющие части менеджеров сервантов. Там упоминается пустой интерфейс ServantManager, являющийся прародителем двух других — ServantActivator и ServantLocator. Они-то и используются разработчиками для реализации собственных менеджеров сервантов, причем применение того или иного зависит от политики, установленной для POA. Если программист, создавая POA, планирует хранить ссылки в таблице активных объектов, то он будет использовать политику RETAIN (установлена для нового POA по умолчанию). В этом случае следует создавать свой менеджер сервантов, реализуя в нем интерфейс ServantActivator. При политике NON_RETAIN, которая не дает POA хранить ссылки на активные объекты, нужно реализовать интерфейс ServantLocator. Еще одно важное условие: созданный менеджер сервантов должен быть локальным по отношению к его POA, т. е. располагаться в том же адресном пространстве. И разумеется, предполагается, что установлена политика USE_SERVANT_MANAGER.

ServantActivator

Интерфейс ServantActivator включает в себя всего лишь два метода, служащих функциями обратного вызова, — incarnate() и ethercalize(). Это значит, что они вызываются адаптером объектов в определенных ситуациях.

Метод incarnate() будет вызван, как только поступит запрос для объекта с заданным идентификатором. Если вы хотите создать объект или, скажем, воспользоваться объектом, находящимся в пуле, то следует поместить код, реализующий эти замыслы, именно в метод incarnate(). Для успешного выполнения этой задачи у данного метода есть два важных параметра. Один из них — oid — является идентификатором, отличающим каждый экземпляр объекта. Другим параметром передается ссылка на адаптер объектов POA, в рамках которого должен находиться объект. Метод incarnate() должен возвращать ссылку на тип Servant. Если создание объекта невозможно, возбуждается стандартное исключение CORBA::ForwardRequest:

Servant incarnate (

in ObjectId oid,

in POA adapter)

raises(ForwardRequest);

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

Обратный процесс деактивации объекта сопровождается вызовом метода etherealize():

void etherealize(

in ObjectId oid,

in POA adapter,

in Servant serv,

in boolean cleanup_in_progress,

in boolean remaining_activation);

Первые два параметра абсолютно схожи с параметрами метода incarnate(), а третий является ссылкой на сервант деактивируемого объекта. Если этот сервант связан с разными объектами, то параметр remaining_activation будет равен TRUE. Следовательно, уничтожать его нельзя. Предпоследний параметр cleanup_in_progress говорит о причине вызова etherealize(). При значении TRUE вам будет ясно, что причина кроется в вызовах deactivate() или destroy() с параметрами etherialize_objects, равными TRUE.