Лабораторная работа № 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-объектами и их сервантами.
Некоторые из этих терминов уже знакомы по предыдущей работе.
6.1. Архитектура 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.