Если Вы никогда не слышали о технологии CORBA (Common Object Request Broker Architecture — Общей Архитектуре Брокеров Объектных Запросов), то сегодня в этом еще не стыдно признаться. Но уже совсем скоро CORBA станет одним из тех магических слов и аббревиатур, знание которых определяет причастность к обществу избранных - специалистов по информационным технологиям. Так что не думайте, что это из мира пресмыкающихся.

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

Итак, для начала немного истории. СORBA 3 представляет собой третий этап смелой попытки выработать общую технологию, подходы, методы и стандарты для промежуточного программного обеспечения. Такую грандиозную задачу поставила перед собой OMG (Object Management Group), группа объектного управления, международная некоммерческая организация, в которую входят программные и промышленные компании. При этом в постановке задачи заложена универсальность и практически отсутствуют ограничения, а именно:
  • связываемые программные приложения могут быть написаны на разных языках программирования, в частности, не обязательно объектно-ориентированных;
  • приложения могут выполняться на компьютерах с разной архитектурой и разными операционными системами, при этом могут не очень много «знать» друг о друге, а то и вовсе ничего.

Каждый следующий этап развития CORBA не только дополняет достижения предыдущего, но и позволяет себе частичный, а иногда и полный пересмотр устаревших понятий. Незыблемым является фундаментальный принцип CORBA - использование брокеров объектных запросов (ORB - Object Request Broker) для взаимодействия распределенных объектов. Для описания стандартов создан специальный декларативный язык IDL (Interface Definition Language - Язык Описания Запросов), для которого существуют компиляторы в большинство современных языков программирования.

CORBA 1 начиналась как прививка объектной идеологии на крепкое дерево RPC (Remote Procedure Call - Вызов удаленных процедур). Затем появилась CORBA 2, обогащенная средствами интеграции брокеров объектных запросов, в частности, по TCP/IP. Именно это дополнение позволило активно использовать брокеры в Internet и строить территориально распределенные динамические программные системы. За несколько лет, которые прошли с момента появления CORBA 2, в технологии наметились серьезные изменения. Одни новые стандарты уже опубликованы, другие продолжают разрабатываться или обсуждаться. Как и положено, повзрослевшая CORBA стала строже и солидней. Можно сказать, что она, наконец, стоит на пороге зрелости. CORBA 3 будет паспортом технологии в мир «взрослых».

Она существенно продвинулась в создании компонентной модели. Это новый многообещающий подход к построению программного обеспечения, который предполагает использование готовых компонентов и предлагает технологию их связывания. Таким образом, CORBA решает (или пытается решить) проблему создания в реальные сроки современных промышленных приложений, которые отвечали бы конкретным, а зачастую уникальным, задачам предприятия и позволяли бы быстро реагировать на возникающие изменения.

Другое интересное направление развития - применение CORBA-объектов в системах реального времени. Но не будем перечислять все достижения, они подробно описаны в работах [1] и [2]. Скажем только, что точка еще не поставлена и фанфары не отзвучали.

Каковы же основные цели (в смысле purpose - стратегические) нового стандарта CORBA 3? Уменьшить количество «может быть». Ограничить свободу разработчиков, впрочем, если смотреть под таким углом зрения, то вся технология CORBA направлена на регламентацию деятельности разработчиков, создателей брокеров объектных запросов и других элементов, таких как сервисы и средства. Подобная «кабала» дает массу преимуществ.

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

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

Портируемый объектный адаптер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 2. Объектный адаптер в архитектуре Corba

Объектный адаптер, по определению OMG, отображает понятие программно-реализованных сервантов на концепцию CORBA-объектов. рис. 2 поясняет местоположение объектного адаптера в архитектуре CORBA. Объектный адаптер превращает серверные объекты в CORBA-объекты или извлекает CORBA-объекты из серверного приложения.

Что умеет делать объектный адаптер (или лучше сказать «должен уметь», поскольку CORBA 3 - это набор стандартов, а не готовая система)? Перечислим обязанности объектного адаптера:

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

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

Различные объектные адаптеры поддерживают разные стили реализации сервантов.

Чем же был плох Основной Объектный Адаптер (BOA)?
Рис. 3. Роль объектного адаптера в передаче запросов

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

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

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

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

Рис. 4. Передача клиентских вызовов

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

Замечательной особенностью 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-объектов (для экономии серверных ресурсов). Примером может служить ситуация, когда объект представляет собой запись в БД, а его идентификатором является ключ. Для всех таких объектов можно использовать один сервант, который по ключу обращается к соответствующему объекту.
  • Активизация сервантов только потребованию клиента - если есть запрос.

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

Увы, Портируемый Обектный Адаптер повысил ответственность серверных приложений за обработку клиентских запросов. Но кто же, как не эти родные для объекта приложения, может наилучшим образом представить его внешнему миру. В утешение разработчикам можно добавить, что никто не запрещает использовать POA для прямой работы с объектом, например, для присвоения ему идентификатора. Если Вы, конечно, не боитесь отдать взлелеянный Вами объект в «чужие» руки.

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

Статический случай

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

Адаптер POA поддерживает два типа статических сервантов.
  • Серванты, основанные на наследовании. Класс серванта наследуется от абстрактного класса скелетона.
  • Связанные серванты с использованием делегирования. Этот тип обычно используется, когда наследование невозможно, например, если необходимо множественное наследование, а язык программирования, на котором написано приложение, множественное наследование не поддерживает (Java). Делегирование - передача функциональности другому классу.

Динамический случай

Примером может служить односторонний мост к другим распределенным системам (в частности - СОМ, Сommon Object Model). Клиент СОRВА посылает запрос к объекту, реализованному на СОМ. Когда к системе присоединяются интерфейсы СОМ нового типа, клиенты должны иметь возможность работать с ними без остановки системы и перекомпиляции. Интерфейс Динамических Скелетонов поддерживает такие ситуации и позволяет сервантам в реальном времени определять детали интерфейса и операций, вызывающих конкретный объект. Обычно используется Репозитарий Интерфейсов, который «на лету» предоставляет подробности динамических интерфейсов.

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

  • Для каждого запроса создается отдельный поток.
  • Для каждого объекта создается отдельный поток.
  • Для всех запросов создается один общий поток.
  • Создается пул потоков фиксированного размера для обработки всех запросов.

Выбор конкретной потоковой политики зависит от программных приложений распределенной среды.

На более высоком уровне ORB CORBA 3 предоставляет две модели многопоточности.

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

У Вас разбегаются глаза? Не знаете, какую политику предпочесть? Как разобраться во всех этих новых возможностях? Действительно, богатство выбора заставляет задуматься. От «молотка» старого Основного Адаптера CORBA перешла к более сложному инструменту, им надо уметь пользоваться. Выбор той или иной модели POA должен быть сделан только после тщательного анализа создаваемой распределенной среды, целей и функций разрабатываемой системы, доступного оборудования. Но зато сколько новых элементов! Среди них менеджеры сервантов, политики РОА, гибкость присвоения индентификатора объекту, устойчивые и временные объекты, возможность хранения связей сервант-объект в Карте Активных Объектов. Можно воплотить любой воздушный замок.

Поддержка асинхронного метода вызова Asynchronous Method Invocation (AMI)

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

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

Вспомним, что первые версии поддерживали три модели клиентских запросов.

  • Синхронные. Клиент посылает запрос на выполнение операции и ждет отклика от целевого объекта. Во время ожидания клиентский процесс, осуществивший запрос, блокируется и, используя системные ресурсы, не выполняет никаких действий.
  • Синхронные отложенные. Клиент вызывает операцию на целевом объекте и продолжает выполняться. Блокировки клиентского процесса не происходит, а вместо этого через некоторое время клиентское приложение проверяет, получен ли запрос, и, в зависимости от ответа, производит те или иные действия. Вырожденный вариант такой ситуации - запуск отдельного процесса, ожидающего отклик от целевого объекта. Эта модель была определена только для динамического случая, когда используется Dynamic Invocation Interface (DII), Интерфейс Динамических Вызовов.
  • Однонаправленные. Запросы, не требующие отклика. Клиент вызывает операцию и ОRВ гарантирует только то, что запрос будет доставлен. Такая модель необходима, например, в случае использования транспортных протоколов, не гарантирующих доставку (UDP - User Datagram Protocol).

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

    Новые спецификации сообщений, включенные в CORBA 3, расширяют возможности технологии. К ним относится Асинхронный Метод Вызова (Asynchronous Method Invocaction - AMI).

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

  • Обратный вызов (callback) - Каждый вызов клиента в качестве параметра содержит объектную ссылку на специальный объект, управляющий такими вызовами, который и получает отклик от целевого объекта. Этот объект клиентской части перенаправляет его соответствующему клиенту.
  • Голосование (polling). Для этой модели IDL был расширен новым типом данных: Poller valuetype, который наследуется от нового типа данных, определенного в спецификациях Передача Объекта по Значению (см. следующий пункт). Клиент использует специальный Poller метод, чтобы получать информацию о статусе своего вызова: подготовил ли сервер ответ и если да, то считать отклик. Политика голосования может быть достаточно гибкой, что выгодно отличает этот метод от Синхронного Отложенного.

    Две эти модели являются СORBA-отражениями хорошо знакомых моделей push и pull. Заинтересованная сторона, в данном случае, клиент, либо постоянно интересуется, как поживает его запрос (pull- polling), либо передает инициативу целевому объекту, который должен уведомить клиента в случае готовности ответа (push-callback). Обе модели не порождают новых потоков на клиенте, что немаловажно. В данном случае изменения касаются клиентской стороны модели.

    В CORBA 3 определяются еще два полезных средства.
  • Незвависимые от времени вызовы (Time-Independent Invocations - TII).

    Эта разновидность асинхронных вызовов поддерживает алгоритм «запомнил и послал».

    Подобные вызовы необходимы в тех случаях, когда клиент посылает асинхронный запрос к объекту, который неактивен или отсоединен в данный момент. Для поддержки метода определен специальный протокол Interoperable Routing Protocol (IRP), основанный на General Inter-ORB Protocol (GIOP). С помощью этого протокола брокеры объектных запросов интегрируются с Ориентированным на сообщения Промежуточным программным обеспечением (Message Oriented Middleware —MOM).

  • Качество сервиса сообщений (Messaging Quality of Service — QoS) тоже пришло из МОМ. Это средство определяет поведение различных элементов технологии в области передачи сообщений. Основные методы включают в себя: Качество Доставки, Управление Очередью и Приоритет Сообщений. Все эти методы определяются на различных уровнях архитектуры CORBA.
    • На уровне брокеров объектных запросов. На этом уровне определяются методы оценки качества всех сообщений, передаваемых брокером.
    • На уровне потоков (thread). Здесь задаются методы для всех запросов от данного потока.
    • На уровне объектной ссылки. Соответственно, определяются все запросы, использующие эту объектную ссылку.
Методы последующего уровня переписывают методы предыдущего.

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

Итак, асинхронные методы вызовов были белым пятном в CORBA 2. В этом смысле «старая» CORBA отставала от МОМ. Эта область, в частности, не позволяла CORBA стать уникальной всеобщей объектной идеологией Распределенных Программных Приложений, превосходящей все доселе известные технологии. Теперь этот досадный недостаток устранен.

Поддержка передачи Объектов по значению

Задача поддержки передачи объектов по значению является следующим шагом на пути СORBA в честолюбивом стремлении «догнать и перегнать» все остальные технологии. В данном случае речь идет о Java, которая поддерживает эту особенность. Под передачей Объекта по Значению имеется в виду возможность передачи целевому объекту вместо ссылки на объект самого объекта. С самого начала CORBA позволяла передавать как аргументы операций такие типы данных, как структуры и массивы. Чтобы дать возможность объекту вызывать операции на других объектах, CORBA разрешала передавать ссылки на объекты в качестве аргументов. Это означало, что объект остается на клиенте, а серверное приложение формирует обратные запросы к этому объекту клиентского приложения. Нагрузка на ORB возрастает - проще передать сам объект на серверную сторону.

Для поддержки Передачи Объекту по Значению в IDL введено новое понятие - value type, нечто среднее между структурой и интерфейсом, так как поддерживает одновременно и данные, и операции над ними в стиле С++ и Java. Как и интерфейсы, valuetype поддерживает наследование (не множественное). Valuetype, который содержит только отдельные данные без операций, называется boxed valuetype (коробка). Абстрактный интерфейс - новая разновидность CORBA-интерфейса.

Когда valuetype передается как аргумент удаленной (вызываемой) операции, его копия создается в «принимающем» адресном пространстве. Эти копии полностью независимы от оригиналов, и операции на одной из них не оказывают никакого влияния на другую.Операции на valuetypes всегда локальны по отношению к процессу, в котором valuetype существует. В противоположность операциям вызова (invocations) на объектах CORBA, вызовы valuetype не порождают обратных откликов к клиенту и, следовательно, не нагружают сеть.

Что касается передачи данных valuetaype от клиента к серверу, то это действие ничем не отличается от передачи данных других типов и затруднений не вызывает. Однако необходимо передавать еще и операции, что не так просто, хотя бы потому, что клиент и сервер могут быть написаны на разных языках. В некоторых ситуациях до сих пор непонятно, как это сделать. Самый лучший случай (Си или С++), когда операции хранятся в форме DLL-библиотек, которые можно передать от клиента к серверу. Другая удобная ситуация, когда на сервере есть те же библиотеки, что и на клиенте и, следовательно, ему известны операции клиента. При использовании в качестве языка программирования Java и работе через Internet подгрузка операций на сервер осуществляется идеальным образом, в виде Java апплетов - просто и безопасно.

Работа над спецификацией Передачи Объекта по Значению продолжается. В настоящее время она чересчур громоздкая и неполная. Возможно, именно это является камнем преткновения для объектного подхода (как передать операции - действия, передавать данные уже научились). Еще одна беда - влияние нового подхода на сервисы CORBA. Их придется менять для передачи Объектов по Значению, особенно сервисы Безопасности,Транзакций и Жизненного Цикла.

Хотя я и старалась никого не запутать, у Вас, вероятно, возникло впечатление, что CORBA 3 - особа весьма загадочная. В утешение приведу некоторые размышления, которые позволят Вам не отвернуться от нее, а попробовать познакомиться поближе.

  • На технологию CORBA можно смотреть как на философию создания инструментов для распределенных промышленных приложений. Есть слесарный инструмент, есть портняжный, а есть - для промежуточного программного обеспечения. Во-первых, Вам вовсе не обязательно пользоваться всем набором самостоятельно, а во-вторых, его можно осваивать постепенно. Если эта стамеска пока не нужна - пускай полежит в сторонке.
  • Сами инструменты уже созданы. Ящичек собран. Это - брокеры объектных запросов с дополнительными сервисами и прочими приятными дополнениями. Наиболее известные среди них - Visibroker (Inprise) и Orbix (Iona). Тенденция такова,что основные программные трудности переносятся именно туда. Те, кто создает такие брокеры, стараются заинтересовать ими не только специалистов, но и новичков. Конкуренция на этом рынке присутствует, так что есть надежда, что умные разработчики сумеют нам помочь.
  • Мы уже обсуждали понятие CORBA-объекта. В терминах Вашего приложения это те объекты, которые Вы хотите открыть окружающему миру. Отправляясь отдыхать, Вы же не берете с собой любимый комод или холодильник. Так и тут. Вам необязательно показывать другим приложениям ни Вашу «кухню», ни вспомогательные утилиты. Вам всего-навсего надо выбрать внешние, «презентационные» бизнес-объекты и использовать наиболее подходящие средства для доступа к ним снаружи.

«А где же обещанное путешествие?» - спросит строгий читатель. Я уверена, что Вы обязательно отправитесь в путешествие с CORBA. Разработаете собственную грамотную, «уживчивую» систему, или будете использовать эту технологию в проектах по интеграции разнохарактерных программ, или, быть может, примете участие в развитии самих стандартов CORBA, используя свой бесценный опыт разработчика. Считайте эту статью вводным инструктажем перед дальней дорогой. Поэтому поменяем название: «Некоторые разъяснения перед путешествием с CORBA...»

Об авторe

Марина Аншина - руководитель сектора разработок и системной поддержки компании «ТопС, Системный Интегратор», с ней можно связаться по почте по адресу: Marinaa@tops-msk.com, anshina@aha.ru

Литература

[1] Роберт Орфали, Ден Харки, Джери Эдвардс «Основы CORBA» 1999.

[2] Сергей Орлик «CORBA3» «Открытые системы» 1999, №2

[3] Douglas C. Schmidt, Steve Vinoski «Introduction to CORBA Messaging» SIGS C++ Report magazine, 1998

[4] Douglas C. Schmidt, Steve Vinoski «Portable Object Adapter», SIGS C++ Report magazine,

[5] Steve Vinoski «New Features for CORBA 3.0»

Поделитесь материалом с коллегами и друзьями