Технология corba (Common Object Request Broker Architecture).

Это обобщенная архитектура брокера объектных запросов. Как и в DCOMактивно используется интерфейс объекта.

Главное отличие от DCOM: интегрированный в нее слой реализует удаленный доступ к объектам (доступ к удаленной области).

В соответствии с технологией CORBAвзаимодействие объекта с клиентом выглядит следующим образом:

Машина клиента

Машина сервера

Сетевое окружение

skeleton

клиент

Stub

Smart Agent

Basic Object Adapter

Рис. Схема взаимодействия объекта с клиентом по технологии CORBA2.1.

На машине клиента создается два объекта посредника – Stub(уже упоминавшийся ранее) иORB(ObjectRequestBroker– брокер объектных запросов).

• Stubвыступает как полномочный представитель объекта. В соответст­вии с интерфейсом объекта клиент обращается кStubтак, как если бы это был сам объекта. Получив вызов метода,Stubпередает этот вызов брокеруORB, который посылается в сеть сообщение о вызове. На это сообщение откликается один из объектовSmart Agent(SA, «умный агент»), установленный в сетевом окружении клиента в локальной сети илиInternet.

• Объект Smart Agentпредставляет собой сетевой каталог, в котором зарегистрированы серверы объекта.SmartAgentотыскивает нужный сетевой адрес сервера и передает запрос брокеру на машине сервера. Через базовый объектный адаптерBOA(BasicObjectAdapter) запрос передается особому объекту сервера –skeleton(“каркас”, “основа”), который помещает параметры запроса в стек адресного пространства объекта сервера и осуществляет его вызов.

Роль BOA: фильтрация обращений к объекту сервера. С помощью методов, которые имеются у адаптера, сервер черезskeleton может объявить некоторые свои поля или свойства доступными только для чтения или вовсе скрытыми для данного клиента.

В архитектуре CORBA адаптер представляет собой элемент, обеспечивающий создание и реализацию серверных объектов. Вплоть до CORBA 2.1 в качестве такого элемента был определен BOA, поддержка которого регламентировалась для всех ORB. СпецификацииBOAбыли неполными, и разработчики создавали свои, весьма различные версии. В итоге адаптеры стали самой пестрой частью стандарта, т.е. наименее стандартизованной. Они жили своей независимой жизнью, поэтому в CORBA 2.2 вместоBOAбыл определенPOA(PortableObjectAdapter), или Портируемый Объектный Адаптер. Он полностью интегрирован с другими спецификациями технологии, и является одним из основных усовершенствованных элементов серверной части в CORBA 3. Базовый Адаптер (BOA) был исключен из CORBA. (Конечно, создатели ORB могут его поддерживать в целях преемственности.)

Начиная с версии 2.2, в CORBA используются термины:

CORBA-объект– виртуальное понятие: он представляет собой нечто, расположенное на брокере объектных запросов, посылающее запросы к другим CORBA-объектам – серверным объектам и получающее запросы от других CORBA-объектов – клиентов. В контексте запроса от клиента такой объект называютцелевым(target object). Нужно подчеркнуть, что CORBA-объект не имеет физической реализации, его нельзя пощупать, отладить, записать на дискету. Обращение к нему осуществляется пообъектной ссылке(object reference), которая в отличие от самого объекта является вполне реальной и представляет собой последовательность символов.

Идентификатор объекта (object ID) – уникальное имя объекта вну­три его объектного адаптера. Он представляет собой последовательность байт, которая ассоциируется с объектом в момент его создания. Обеспечивается либо программным приложением, либо РОА. Идентификатор объекта не обязан быть уникальным во всем остальном мире и даже для сервера. Там объект известен под своей объектной ссылкой (objectreference). Как правило, идентификатор объекта является частью объектной ссылки. Клиент при обращении к целевому объекту не позволяет себе фамильярничать и называть его по идентификатору, он уважительно именует объект полной объектной ссылкой (по имени-отчеству). Есть еще объектный ключ (тоже часть объектной ссылки), который используетсяGIOP(General Inter-ORB Protocol), протоколом взаимодействия брокеров объектных запросов, для идентификации конечной точки связи. Объектный ключ уникален именно в этом смысле.

Сервант – серверная программа, написанная на каком-либо из языков программирования и выполняющая CORBA-объект. Это может быть набор функций, представляющих состояние объекта (на Си или Коболе) или реализации определенных классов серверного приложения (на C++ или Java). Сервант написан на том же программном языке, что и приложение, и является программной реализацией объекта CORBA.

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

Скелетон– серверная программа, которая связывает сервант с объектным адаптером, позволяя объектному адаптеру перенаправлять запросы к соответствующему серванту. В языке Си, скелетон – набор указателей на функции серванта, а вC++, скелетон – родительский класс для всех классов сервантов. При статических методах вызова скелетон формируется при компиляции IDL кода. При динамических – не используется.

Активизация– запуск существующего CORBA-объекта для обработки клиентских запросов. Активизация предполагает, что интересующий клиента объект имеет подходящий сервант. Создание серванта может входить в процесс активизации. В отличие от сервантов создание объектов не является предметом активизации и, чаще всего, осуществляется с помощью фабрик объектов. Объекты-фабрики столь же виртуальны, как и другие CORBA-объекты и, следовательно, в программном смысле создание объектов возложено на соответствующий сервант объекта-фабрики. Именно такой сервант вызывает на объектном адаптере операцию по созданию объекта, что подразумевает установление связки с сервантом и ссылки на новый объект. Кроме того, фабрика-объект может активизировать созданный объект.

Активизированные объектыбывают двух типов: устойчивые и временные.Устойчивые объектысуществуют и после останова процесса, который их создал или активизировал. Их жизненный цикл не зависит от жизненного цикла активизировавшего их серверного процесса. Устойчивые объекты более традиционны, для них идентификатор объекта обычно предоставляется приложением и может являться, в частности, ссылкой на устойчивое хранилище объекта, например, совпадать с ключом базы данных.

Временные объекты– это объекты, чей жизненный цикл ограничен процессом или даже объектным адаптером, который их создал. Это необходимо, например, в следующем случае: одно приложение запрашивает другое с требованием обратного запроса-отклика, не дождавшись которого завершает свою работу. В этом случае отклик должен быть временным. Временные объекты «легче» для ORB, так как их жизненный цикл ограничен периодом работы соответствующего объектного адаптера, и они не должны быть реактивизированы.

Деактивизация– действие, обратное активизации, останов CORBA-объекта, разрыв связки между объектом и сервантом, в общем случае без разрушения объекта. В дальнейшем CORBA-объект может быть вновь активизирован. Разрушение CORBA-объекта обязательно вызывает деактивизацию.

Инкарнация(воплощение) – слово, пришедшее из восточных религий и означающее «облекать в вещественную форму или материализовывать». В мире CORBA инкарнация – это связывание серванта с CORBA-объектом для обработки клиентского запроса. Инкарнация материализует в серванте виртуальный CORBA-объект. В отличие от активизации инкарнация относится не к объекту, а к его серванту.

Эфемеризация– в противоположность инкарнации разрушение связки CORBA-объект – сервант со стороны серванта. Эфемеризация возносит (возвращает) объект «в небеса», удаляя от «грешной земли» и выполнения клиентских запросов. Так же как инкарнация, эфемеризация является операцией серванта.

Карта активных объектов(ActiveObjectMap) – таблица объектного адаптера, в которой он ведет реестр активных CORBA-объектов и связанных с ними сервантов. Первые представлены в карте своими идентификаторами.

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

CORBA-объект не существует Создание CORBA-объекта Портированный объектный адаптер (POA) CORBA-объект не активирован А Инкарнация серванта ктивизацияCORBA-объекта CORBA-объект активирован Эфемеризация серванта CORBA-объект не активирован Деактивизация CORBA-объекта CORBA-объект не существует Разрушение CORBA-объекта

Рис. Отношение жизненных циклов CORBA-объекта и серванта

Из рис.? видно, что CORBA-объект и связанный с ним сервант в общем случае имеют жизненные циклы разной длины. Один сервант за свою жизнь может инкарнировать один или более объектов. Например, сервант по умолчанию, который будет определен позднее, способен инкарнировать все объекты для данного РОА. Спецификации допускают также возможность инкарнации одного СОRВА-объекта несколькими сервантами. В сложном случае, когда нет связки сервант – объект в Карте Активных Объектов, РОА обращается к менеджеру сервантов, который предоставляет сервант, способный отвечать за обработку пришедшего запроса. Возможна схема, при которой менеджер сервантов создает в каждом случае новый сервант. Таким образом, жизненные циклы сервантов и объектов независимы и определяются типом приложений, которые их используют. Обычно, особенно для устойчивых объектов, жизнь объекта длиннее жизни серванта.

CORBA-объект не существует Создание CORBA-объекта Приложение CORBA-объект не активирован Активизация CORBA-объекта P O A CORBA-объект активирован Инкарнация серванта Эфемеризация серванта Инкарнация серванта Эфемеризация серванта CORBA-объект не активирован Деактивизация CORBA-объекта CORBA-объект не существует Разрушение CORBA-объекта Приложение

Рис. Вариант взаимодействия жизненных циклов CORBA-объекта и серванта

Что должен уметь делать объектный адаптер:

• создавать CORBA объекты и их объектные ссылки;

• демультиплексировать запросы на каждый серверный CORBA-объект;

• перенаправлять запросы к соответствующему серванту, который обеспечивает реализацию серверного CORBA-объекта;

• активизировать и деактивизировать CORBA-объекты и, соответственно, инкарнировать и эфемеризировать соответствующие серванты.

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

Чем был плох BOA?

• Во-первых, спецификации BOA не описывали, как должен выглядеть скелетон, и как серванты связываются с ним. Отсюда трудности переноса приложений на другие платформы.

• Во-вторых, не был регламентирован способ регистрации сервантов. Обычно это осуществлялось либо вызовом подходящего метода на адаптере, либо в момент инкарнации самого серванта. Все создатели ORB реализовывали регистрацию по-своему.

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

Новый объектный адаптер POA призван компенсировать все недостатки Основного Адаптера. Основная его цель – обеспечить портируемость серверных элементов СОRВА, в частности, сервантов, через разные ORB.

На рис.? показана схема вызова клиентом объекта серверного приложения. Этот вызов обращается к объекту по объектной ссылке, которая уникально идентифицирует CORBA-объект в соответствующем пространстве имен. Через брокер объектных запросов запрос передается на сервер. Как уже упоминалось, часть объектной ссылки, объектный ключ, уникально идентифицирует объект в его серверном приложении. Этот объектный ключ позволяет ORB выбрать именно тот адаптер, который отвечает за вызываемый объект (к одному приложению может относиться несколько адаптеров). POA выделяет из объектного ключа объектный идентификатор, и по объектному идентификатору определяет, какой сервант связан с вызываемым объектом. Адаптер может узнать это по специальной Карте Активных Объектов, или вызвать приложение и попросить его обеспечить нужный сервант по идентификатору объекта, или использовать сервант, выставленный приложением по умолчанию. Далее с запросом начинает работать сервант. Он отвечает за выполнение запроса и возвращает результаты обратно к объектному адаптеру, который передает их брокеру объектных запросов, а тот в свою очередь – клиенту. Т.о., запрос передается из рук в руки, как эстафетная палочка. Можно провести некоторую аналогию с сетевой моделью, та же эстафета в передаче запроса и обработка идентификаторов-адресов.

Объектный ID	Сервант
AB1230D	Сервант 1
OM9546B	Сервант 2

Карта активных

объектов

Серверное приложение

Сервант 1

Сервант 2

Сервант 3

Объект­ный ID

Вызов: «объектная ссылка» целевого объекта

Номер серванта

Отклик

POA2

Вызов: «объектный ключ» целевого объекта

Клиент

Вызов: «объектная ссылка» целевого объекта

ORB

POA1

Отклик

Отклик

Рис. Схема передачи клиентских вызовов.

Замечательной особенностью CORBA-среды является возможность автоматической активизации серверных объектов. Без этого CORBA не была бы всеобщей идеологией распределенных систем. Ведь иногда клиент посылает запрос «на деревню дедушке», а технология этого самого «дедушку» материализует. Мало того, вполне возможен запуск необходимого серверного процесса (процессов), а уже потом активизация объекта (т.е. материализация не только «дедушки», но и той самой деревни).

Основной Объектный Адаптер поддерживал 4 модели активизации серверных процессов (а не объектов).

• Разделяемый сервер– сервер поддерживает разные объекты разных типов.

• Устойчивый сервер.Не слишком удачный термин, так как это просто запускаемый вручную процесс (чаще всего с помощью программного скрипта).

• Опережающий сервер – на каждую операцию. Один процесс – одна операция конкретного типа на CORBA-объекте.

• Неделимый сервер – сервер поддерживает только один CORBA-объект. Один объект – один процесс. Для нового объекта создается новый процесс.

В отличие от Основного Объектного Адаптера Портируемый ОбъектныйАдаптер (POA) поддерживает следующие модели активизации серверных объектов (прошу заметить, речь идет об объектах, а не о процессах).

• Точная (прямая – explicit) активизация – регистрация сервантов для CORBA-объектов напрямую в серверной программе посредством прямого обращения к POA. Это удобно, если серверные приложения содержат немного CORBA-объектов.

• Активизация по требованию.В серверном программном приложении регистрируется менеджер сервантов. Его и вызывает POA, когда получает запрос для CORBA-объектов, которые еще не активизированы. Менеджер сервантов в этом случае осуществляет одно из следующих действий:

• инкарнирует сервант, если нужно, и регистрирует его в POA, который затем передает соответствующие запросы напрямую серванту, минуя менеджер;

• пересылает запрос другому объекту;

• отвечает POA, что CORBA объект разрушен (destroyed);

• Безусловная активизация. Сервант активизируется без уведомления об этом POA

• Сервант по умолчанию.Сервант по умолчанию (default servant) используется для запросов к тем CORBA-объектам, которые еще не активизированы и не зарегистрированы в менеджере сервантов. Такие серванты особенно полезны, когда используется DSI (Dynamic Skeleton Interface), чтобы инкарнировать все CORBA-объекты без привлечения менеджера сервантов. Для связок сервант-объект, POA также предлагает различные модели.

• Каждый CORBA-объект активизируется своим сервантом. Девиз: личный сервант – каждому объекту. Взаимно-однозначное соответствие между CORBA-объектами и сервантами не подходит, когда серверное приложение содержит большое количество CORBA-объектов.

• POA позволяет одному серванту инкарнировать несколько CORBA-объектов (для экономии серверных ресурсов). Примером может служить ситуация, когда объект представляет собой запись в БД, а его идентификатором является ключ. Для всех таких объектов можно использовать один сервант, который по ключу обращается к соответствующему объекту.

• Активизация сервантов только по требованию клиента – если есть запрос.

Процесс создания сервантов также жестко не регламентирован. В зависимости от приложений иногда бывает необходимо создать серванты до того, как соответствующие объекты получат запрос. Например, в случае, когда серверный объект располагается в сенсоре, а объект, скорее всего, совпадает с самим сенсором. Другой случай – приложение, содержащее много объектов. В целях экономии памяти следует создавать серванты в момент поступления запроса к соответствующему объекту. В конкретном случае, если объект совпадает с элементом базы данных (строкой таблицы) можно использовать менеджер сервантов, который по запросу от адаптера создает соответствующий сервант или использует уже существующий. В зависимости от приложения связка сервант-объект может сохраняться некоторое время в Карте Активных Объектов, а может и не сохраняться.

Рассмотрим по отдельности два случая (как две стороны жизни CORBA) – статический и динамический, применительно к использованию РОА и сопутствующих элементов.