В архитектуре CORBA адаптер представляет собой элемент, обеспечивающий создание и реализацию серверных объектов. До CORBA 2.1 в качестве такого элемента был определен стандартный адаптер – Основной Объектный Адаптер (Basic Object Adapter), поддержка которого регламентировалась для всех ORB. Спецификации Основного Адаптера были неполными, и разработчики создавали свои, весьма различные версии. В итоге адаптеры стали самой пестрой частью стандарта, т.е. наименее стандартизованной. Они жили своей независимой жизнью, демонстрируя капризный нрав и непокорный характер. POA (Portable Object Adapter), или Портируемый Объектный Адаптер, был впервые определен в CORBA 2.2. Он полностью интегрирован с другими спецификациями технологии, и является одним из основных усовершенствованных элементов серверной части в CORBA 3. Основной Адаптер просто исключен из CORBA. Конечно, создатели ORB могут его поддерживать в целях преемственности.
POA можно назвать практически новым элементом архитектуры, настолько отличается он от своего предшественника. Для того ,чтобы познакомиться с ним, давайте повторим некоторые основные понятия.
Рис. 7. Некоторые варианты взаимодействия жизненных циклов Corba-объекта и серванта
Все приведенные понятия касаются жизненного цикла объекта. На рис.7 показаны взаимосвязи некоторых описанных элементов. Большое количество элементов, касающихся различных моментов жизни объекта, позволяет задействовать стандарты для объектов различной природы, и строить их отношения с сервантами по-разному.
Из рис. 7 видно, что CORBA-объект и связанный с ним сервант в общем случае имеют жизненные циклы разной длины. Один сервант за свою жизнь может инкарнировать один или более объектов. Например, сервант по умолчанию, который будет определен позднее, способен инкарнировать все объекты для данного РОА. Спецификации допускают также возможность инкарнации одного СОRВА-объекта несколькими сервантами. В сложном случае, когда нет связки сервант – объект в Карте Активных Объектов, РОА обращается к менеджеру сервантов, который предоставляет сервант, способный отвечать за обработку пришедшего запроса. Возможна схема, при которой менеджер сервантов создает в каждом случае новый сервант. Таким образом, жизненные циклы сервантов и объектов независимы и определяются типом приложений, которые их используют. Обычно, особенно для устойчивых объектов, жизнь объекта длиннее жизни серванта.
Понимание различий между CORBA-объектами и сервантами позволяет создавать гибкие и экономичные приложения.
Рис. 8. Объектный адаптер в архитектуре Corba
Объектный адаптер, по определению OMG, отображает понятие программно-реализованных сервантов на концепцию CORBA-объектов. рис. 8 поясняет местоположение объектного адаптера в архитектуре CORBA. Объектный адаптер превращает серверные объекты в CORBA-объекты или извлекает CORBA-объекты из серверного приложения.
Что умеет делать объектный адаптер (или лучше сказать «должен уметь», поскольку CORBA 3 – это набор стандартов, а не готовая система)? Перечислим обязанности объектного адаптера:
Адаптер переводит обращение к CORBA-объекту на язык, понятный серванту, т. е программному приложению. В свою очередь, скелетон может использоваться для перевода параметров клиентского запроса в форму аргументов операций серванта. Рис.9 проясняет логику работы адаптеров.
Различные объектные адаптеры поддерживают разные стили реализации сервантов.
Чем же был плох Основной Объектный Адаптер (BOA)?
Рис. 9. Роль объектного адаптера в передаче запросов
Во-первых, спецификации BOA не описывали, как должен выглядеть скелетон, и как серванты связываются с ним. Отсюда трудности переноса приложений на другие платформы.
Во-вторых, не был регламентирован способ регистрации сервантов. Обычно это осуществлялось либо вызовом подходящего метода на адаптере, либо в момент инкарнации самого серванта. Все создатели ORB реализовывали регистрацию по-своему.
Наконец, полностью игнорировалась возможность многопотоковых серверных процессов. Но ведь именно такие процессы позволяют сложные задачи выполнять параллельно. Поэтому каждый ORB осуществлял работу с многопотоковыми процессами в собственном стиле.
Новый объектный адаптер POA призван компенсировать все недостатки Основного Адаптера. Основная его цель – обеспечить портируемость серверных элементов СОRВА, в частности, сервантов, через разные ORB.
Рис. 10. Передача клиентских вызовов
На рис. 10 показана схема вызова клиентом объекта серверного приложения. Этот вызов обращается к объекту по объектной ссылке, которая уникально идентифицирует CORBA-объект в соответствующем пространстве имен. Через брокер объектных запросов запрос передается на сервер. Как уже упоминалось, часть объектной ссылки, объектный ключ, уникально идентифицирует объект в его серверном приложении. Этот объектный ключ позволяет ORB выбрать именно тот адаптер, который отвечает за вызываемый объект (к одному приложению может относиться несколько адаптеров). POA выделяет из объектного ключа объектный идентификатор, и по объектному идентификатору определяет, какой сервант связан с вызываемым объектом. Адаптер может узнать это по специальной Карте Активных Объектов, или вызвать приложение и попросить его обеспечить нужный сервант по идентификатору объекта, или использовать сервант, выставленный приложением по умолчанию. Далее с запросом начинает работать сервант. Он отвечает за выполнение запроса и возвращает результаты обратно к объектному адаптеру, который передает их брокеру объектных запросов, а тот в свою очередь – клиенту. Таким образом запрос передается из рук в руки, как эстафетная палочка. Можно провести некоторую аналогию с сетевой моделью, та же эстафета в передаче запроса и обработка идентификаторов-адресов.
Замечательной особенностью CORBA-среды является возможность автоматической активизации серверных объектов. Без этого CORBA не была бы всеобщей идеологией распределенных систем. Ведь иногда клиент посылает запрос «на деревню дедушке», а технология этого самого «дедушку» материализует. Мало того, вполне возможен запуск необходимого серверного процесса (процессов), а уже потом активизация объекта (т.е. материализация не только «дедушки», но и той самой деревни).
Основной Объектный Адаптер поддерживал 4 модели активизации серверных процессов (а не объектов).
Процесс создания сервантов также жестко не регламентирован. В зависимости от приложений иногда бывает необходимо создать серванты до того, как соответствующие объекты получат запрос. Например, в случае, когда серверный объект располагается в сенсоре, а объект, скорее всего, совпадает с самим сенсором. Другой случай – приложение, содержащее много объектов. В целях экономии памяти следует создавать серванты в момент поступления запроса к соответствующему объекту. В конкретном случае, если объект совпадает с элементом базы данных (строкой таблицы) можно использовать менеджер сервантов, который по запросу от адаптера создает соответствующий сервант или использует уже существующий. В зависимости от приложения связка сервант-объект может сохраняться некоторое время в Карте Активных Объектов, а может и не сохраняться.
Увы, Портируемый Обектный Адаптер повысил ответственность серверных приложений за обработку клиентских запросов. Но кто же, как не эти родные для объекта приложения, может наилучшим образом представить его внешнему миру. В утешение разработчикам можно добавить, что никто не запрещает использовать POA для прямой работы с объектом, например, для присвоения ему идентификатора. Если Вы, конечно, не боитесь отдать взлелеянный Вами объект в «чужие» руки.