Лабораторная работа № 6. Адаптер РОА

Применять адаптер POA несколько сложнее, чем BOA, но в награду за излишнюю возню программист получает полную независимость от платформы и невероятную гибкость создаваемых серверов CORBA. Поэтому темой этой работы будет знакомство с POA.

В CORBA объектный адаптер как таковой существует для выполнения различных рутинных операций на серверной стороне информационной системы. Брокер объектных запросов ORB сам по себе не может взаимодействовать с объектами CORBA напрямую, эти функции возложены на объектный адаптер — по сути своей некий местный администратор, распоряжающийся созданием, регистрацией и уничтожением объектов, а также их связью с внешним миром.

Для понимания архитектуры POA следует сначала ознакомиться с терминологией, которая будет использоваться на протяжении работы:

· долгоживущий объект (persistent object) — объект CORBA, способный существовать за пределами процесса, в котором он был порожден;

· временный объект (transient object) — объект CORBA, живущий только внутри процесса, в котором он был порожден;

· се^,рвант (servant) — физический программный код, реализующий абстрактный CORBA-объект;

· менеджер сервантов (servant manager) — объект, отвечающий за управление ассоциациями между объектами и их сервантами, а также за проверку существования объектов;

· менеджер POA (POA manager) — объект, который управляет состоянием POA, например, может ли последний обслуживать входящие запросы или нет;

· активатор адаптеров (adapter activator) — объект, создающий POA в ответ на запросы, полученные в адрес POA, который в тот момент не существует;

· идентификатор объекта (object ID) — идентификатор, который ассоциирует объекты CORBA и их серванты и служит для идентификации объекта в объектном адаптере POA, куда он помещен;

· таблица активных объектов (active object map) — таблица, которая хранит соответствия между объектами CORBA и их сервантами с помощью идентификаторов объектов;

· инкарнация (incarnation) — процесс установления ассоциации между объектами CORBA и их сервантами;

· эфиризация (etherialization) — процесс расторжения связи между CORBA-объектами и их сервантами.

Некоторые из этих терминов уже знакомы по предыдущей работе.

Архитектура POA

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

Обычное архитектурное решение с несколькими экземплярами POA приведено на рис. 6.1., где главный POA, имя которого «RootPOA», - корневой объектный адаптер. Поскольку часто серверы создают несколько различных экземпляров объектного адаптера и располагают их в виде иерархического дерева, в его основание помещается «RootPOA». Такая схема очень похожа на файловую систему. Даже программный поиск подходящего адаптера выглядит как поиск файла в UNIX — корневой адаптер «RootPOA» в этом случае обозначается символом слэша «/». Отметим, что корневой адаптер всегда имеется в системе, и через него производятся все операции по созданию новых POA.

Рис. 6.1. Архитектурное решение с несколькими экземплярами POA

Из рис.6.1. также видно, что POA хранят ссылки на активные серванты. Под этим термином подразумевается конкретный существующий в памяти код, реализующий один или несколько объектов CORBA. Если POA использует политику (см. «Политики POA») RETAIN, то в специальной таблице активных объектов хранится ссылка на активный сервант и один или несколько объектных идентификаторов, соответствующих этому серванту. Если POA не содержит таблицы активных объектов или в последней ссылка на нужный сервант не была обнаружена, запрос передается специальному серванту по умолчанию. По сути, это самый обычный сервант, который может обработать запрос к любому объекту, зарегистрированному в его экземпляре POA. То есть все запросы, приходящие к этому POA, автоматически попадают серванту по умолчанию. Правда, для этого нужно задать политику USE_DEFAULT_SERVANT.

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

Политики POA

При создании нового экземпляра POA можно настроить его иначе, чем другие POA. Этого добиваются, управляя политиками (policy), представляющими собой объекты CORBA, унаследованные от CORBA::Policy. Создавая объект POA операцией POA::create_POA, надо передать ссылки на настроенные объекты политик. Если какие-то объекты политик не указаны, считается, что передается POA политики по умолчанию.

Единожды созданный POA уже не может поменять свои установленные политики, — для этого нужно создать новый POA, а старый уничтожить. Для настройки поточной модели применяется объект поточной политики ThreadPolicy, у которого могут быть следующие значения:

· ORB_CONTROL_MODEL — брокер объектных запросов заботится о распределении конкурирующих запросов по различным потокам, данная модель принята в VisiBroker;

· SINGLE_THREAD_MODEL — все запросы от клиентов обслуживаются по очереди одним главным потоком.

Объект ThreadPolicy создается вызовом операции POA::create_thread_policy.

Политика продолжительности жизни объектов (LifespanPolicy) может отличаться следующим образом:

· TRANSIENT — объекты существуют короткое время и «погибают» вместе с POA, где они были зарегистрированы;

· PERSISTENT — объекты «долгоживущие» и могут пережить процесс, в котором они были созданы.

О временных и долгоживущих объектах сказано в предыдущей работе. Можно сказать лишь, что объект LifespanPolicy создается операцией POA::create_lifespan_policy.

Объект политики уникальности идентификаторов объектов (IdUniquenessPolicy) создается операцией POA::create_id_uniqueness_policy. С ее помощью определяют, может ли один сервант иметь сразу несколько идентификаторов объектов. Такая ситуация возникает, когда один сервант реализует сразу несколько объектов CORBA. Для IdUniquenessPolicy допустимы следующие значения:

· UNIQUE_ID — сервант может иметь только один объектный идентификатор;

· MULTIPLE_ID — сервант может иметь один или несколько идентификаторов.

Вызвав операцию POA::create_id_assignment_policy, программист может получить объект политики присвоения идентификаторов объектов (IdAssignmentPolicy), с помощью которого определяется, кто задает идентификаторы для объектов. Вот два возможных значения:

· USER_ID — идентификатор для объекта задается программой;

· SYSTEM_ID — адаптер объектов POA сам генерирует идентификатор и следит за его уникальностью.

Объект ServantRetentionPolicy определяет политику удержания сервантов в таблице активных объектов:

· RETAIN — POA сохраняет активные серванты в таблице активных объектов;

· NON_RETAIN — активные серванты в таблице активных объектов не удерживаются.

Для создания объекта вышеуказанной политики существует операция POA::create_servant_retention_policy.