Метаданные

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

Мобильная система отличается от традиционной системы клиент/сервер повсеместным использованием метаданных для согласованного описания всех доступных сервисов, компонентов и данных. Метаданные позволяют независимо разработанным компонентам динамически обнаруживать присутствие друг друга и взаимодействовать между собой. Повсеместное распространение метаданных является ключевой cocтавной частью в инфраструктуре распределенных компонентов. Без метаданных мы имеем жестко спроектированные системы клиент/cepвер, не обладающие какой-либо гибкостью.

CORBA представляет собой такую мобильную систему. Чтобы удовлетворять стандарту CORBA, любой создаваемый вами компонент должен быть самоописываемым. Любой объект или сервис системного уровня, который живет на шине CORBA должен также быть самоописываемым. Даже сама шина CORBA обладает этим свойством. В результате CORBA представляет собой полностью самоописываемую систему. Язык метаданных CORBA - это язык описания интерфейса (Interface Definition Language - IDL). Библиотека метаданных CORBA - это Репозитарий Интерфейсов (Interface Repository). Это не что иное, как база данных времени выполнения, содержащая спецификации интерфейса каждого объекта, который может быть опознан ORB. Представьте библиотеку интерфейсов как опрашиваемую и модифицируемую базу данных этапа выполнения, которая содержит IDL-сгенерированную информацию.

Прекомпилятор IDL и Репозитарий Интерфейсов представляют собой базовые сервисы ORB, которые поставляются со всеми CORBA-совместимыми ORB. Повсеместное использование IDL и Репозитария Интерфейсов делает CORBA более самоописываемой, чем любая другая форма промежуточного программного обеспечения (middleware) клиент/сервер. Здесь описаны CORBA IDL и Репозитарий Интерфейсов. Мы также подробно коснемся новых сервисов CORBA, определенных для того, чтобы сделать метаданные Репозитария Интерфейсов доступными ORB разных производителей.

CORBA IDL: Более внимательный взгляд

Как мы упоминали в ранее, IDL - это контрактный язык, который позволяет задать границы компонентов и их интерфейс с потенциальными клиентами. CORBA IDL не зависит от языка программирования и полностью декларативный. Это означает, что он не определяет деталей реализации. IDL предоставляет независимые от операционной системы и языка программирования интерфейсы для всех сервисов и компонентов, расположенных на шине CORBA.

Что подразумевает контракт IDL?

Контракт IDL содержит описание любых ресурсов или сервисов, которые серверный компонент желает предоставить своим клиентам. Серверные компоненты должны поддерживать два типа клиентов: 1) клиенты этапа выполнения, которые вызывают их сервисы и 2) разработчики, которые используют IDL для расширения функций существующих компонентов посредством наследования. В обоих случаях IDL требуется для описания компонентного интерфейса, чтобы реализацию можно было бы рассматривать как черный ящик (или двоичный код).

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

IDL — это описательный язык, который поддерживает синтаксис C++ для констант, типов и объявления операций. Однако, IDL не содержит каких-либо процедурных структур или переменных. Обратите внимание, поскольку в нем отделены реализация и спецификации, IDL представляет хороший нотационный инструмент для разработки ПО. Большинство нотационных языков предоставляют только описание интерфейса. В противоположность этому, CORBA IDL обеспечивает; прямой путь между архитектурой ПО, определяемой интерфейсом, и скомпилированным кодом, который ее реализует. Из описаний IDL предкомпилятор может сгенерировать непосредственно клиентские имитаторы и серверные скелеты. IDL предоставляет также прекрасную возможность инкапсулировать API нижнего уровня и устаревшие программные системы. Архитекторы систем клиент/сервер сочтут CORBA IDL очень полезным и разносторонним инструментальным средством.

Структура CORBA IDL

Репозитарий Интерфейсов хранит метаданные, которые идентичны описываемым вами в IDL компонентам. Фактически, Репозитарий Интерфейсов является просто активной БД, которая содержит скомпилированные версии метаданных, описанных посредством IDL. Прежде чем перейти к структуре библиотеки интерфейсов, давайте бросим быстрый взгляд на то, что находится внутри файла CORBA IDL.

Далее показаны основные элементы, составляющие CORBA IDL. Давайте по ним пройдем:

• Модули предоставляют пространство имен для группирования набора описаний классов (или интерфейсов в терминологии OMG). Модуль идентифицируется ключевым словом module. Модуль имеет имя, состоящее из одного или нескольких идентификаторов. Это означает обычные строки. Идентификаторы разделяются символами»::». Основное назначение модулей состоит в том, чтобы ввести дополнительный уровень иерархии в пространство имен IDL.
• Интерфейсы определяют набор методов (или операций в терминологии OMG), которые могут быть вызваны клиентом на данном объекте. Считайте их определениями классов, но без секции реализации. Интерфейс может объявить одну или несколько исключительных ситуаций, которые индицируют неверно выполненную операцию. Интерфейс может иметь атрибуты. Это значения, для которых реализация автоматически создает операции get и set. Вы можете объявить атрибут с доступом только для чтения, в этом случае реализация создает только функцию get. Интерфейс может бытъ унаследован от одного или нескольких интерфейсов, а это значит, что IDL поддерживает множественное наследование интерфейсов. Отношения наследования определяются с использованием C++ — подобного синтаксиса.
• Операция — эквивалент CORBA для термина метод. Он означает сервис, который может быть вызван клиентом. IDL определяет сигнатуру операции, т.е. параметры метода и возвращаемые им результаты. Параметр имеет вид, который указывает передается ли значение от клиента к серверу (in — входной), от сервера клиенту (out — выходной) или в обоих направлениях (inout — двунаправленный). Параметр также обладает типом, который определяет диапазон его возможных значений. Тип op_type представляет тип возвращаемого значения. Сигнатура метода может определять исключительные ситуации возбуждаемые этим методом при обнаружении ошибки. Необязательный контекст содержит набор значений атрибутов, которые описывают клиентский контекст. Благодаря контексту, клиент может передать серверу информацию о своем локальном окружении.
• Типы денных используются для описания допустимых значений параметров, атрибутов, исключительных ситуаций и возвращаемых значений. Типы данных представляют собой именованные объекты CORBA, которые используются независимо от применяемых языков, операционных систем и ORB. CORBA поддерживает две категории типов: базовые или составные. Базовые типы CORBA включают short, long, unsigned long, unsigned short, float, double, boolean и octet. Составные типы CORBA включают enum, string, array, union, sequence и any. Тип struct подобен структуре C++ и позволяет создавать любые сложные типы данных, используя typedef (определения типов). Тип sequence позволяет передавать массив объектов переменной длины, но вы должны указывать максимальное количество элементов, которое может быть помещено в последовательность (sequence). Тип any очень полезен в динамических ситуациях, поскольку может представлять любой допустимый тип данных IDL - базовый, составной или объектную ссылку. Каждый тип данных CORBA IDL проецируется на родной для конкретного языка тип данных, благодаря соответствующим языковым связываниям.

Структура файла  CORBA IDL

 module <identifier> {
       <type declarations>;
       <constant declarations>;
       <exception declarations>;

       interface <identifier> [:<inheritance>] {
               <type declarations>;
               <constant declarations>;
               <attribute declarations>;
               <exception declarations>;

               [<op_type>]<identifier>(<parameters>)
               [raises exception] [context]
               .
               .
               [<op_type>]<identifier>(<parameters>)
               [raises exception] [context]
               .
               .
       }

       interface <identifier> [:<inheritance>]
               .
               .
  }

CORBA IDL представляет собой исчерпывающий и краткий язык. Полное описание языка занимает 36 страниц (см. CORBA: Architecture and Specification (OMG, 1996)). Оно включает определение грамматики IDL и всех типов данных CORBA.

Типовые коды: самоописываемые данные CORBA

CORBA определяет типовые коды (type codes}, которые представляют каждый тип данных, определенный в IDL. Типовые коды исползуются для создания самоописываемых данных, которые можно передать разным операционным системам, ORB и в Репозитории Интерфейсфов. Каждый типовой код имеет глобально уникальный репозитарный идентификатор (Repository ID). Типовые коды используются CORBA в любой ситуации, где требуются самоописываемые данные. Например, они используются:

• Интерфейсом динамических вызовов для указания типов данных аргументов.
• Протоколами взаимодействия ORB, включая IIOP и DCE/ESIOP, для указания типов данных аргументов внутри сообщений, которые передаются через ORB и операционные системы. Так, они служат в качестве канонического представления данных IIOP.
• Библиотеками интерфейсов для создания ORB-независимых описаний.
• Любыми типами данных для создания самоописываемых параметров общего вида.

Интерфейс TypeCode архитектуры CORBA определяет набор методов для работы с типовыми кодами, их сравнения и получения их описаний (табл 5). Например, вы можете вызвать операцию content_type для массива или последовательности, чтобы получить типы содержащихся в них элементов. Обратите внимание, что многие операции специфичны для определенных типов данных. Например, операции «member» могут быть вызваны только для структур, объединений и перечислений (structures, unions, enumerated).

Табл. 5. Интерфейс TypeCode

Что такое Репозитарий Интерфейсов?

Репозитарий Интерфейсов (Interface Repository) CORBA представляет собой постоянно активную БД определений объектов. Создать эти определения вы можете непосредственно из компилятора IDL или с помощью функций записи библиотеки интерфейсов - CORBA совершенно не волнует способ внесения информации. Однако спецификации CORBA детально описывают структуру этой информации и способы ее извлечения из репозитария. Для этого существует набор классов, чьи экземпляры представляют находящуюся в репозитарии информацию. Иерархия этих классов отражает спецификацию IDL. Результатом является чрезвычайно гибкая объектная база данных, хранящая коллекцию объектов организованных такими же строками, как это имеет место в IDL. Естественно, все объекты репозитария представляют собой скомпилированные версии информации, содержащейся в исходном файле IDL.

Кому нужен Репозитарии Интерфейсов?

ORB обязан понимать определения объектов, с которыми он работает. Один из способов получить такие определения состоит во встраивании этой информации в имитаторы. Другой способ получить требуюмую информацию - постоянно доступный Репозитарии Интерфейсов. Что делает ORB с репозитарной информацией? Он может использовать определения объектов следующим образом:

• Обеспечить контроль типов, указанных в сигнатуре метода. Типы параметров проверяются независимо от способа издания запросас, т.е. используется ли динамический API или имитаторы. Сигнатура определяет параметры метода и их типы.
• Помочь ORB связаться друг с другом. «Федерации» Репозитариев Интерфейсов используются для преобразования объектов, которые перемещаются вдоль гетерогенных ORB. Обратите внимание, вы обязаны использовать один и тот же библиотечный идентификатор (Repository ID) для описания этих объектов. Интерфейсы таких "межгалактических" объектов должны быть определены во всех репозитариях ORB.
• Предоставить информацию о метаданных для клиентов и инструментальных средств. Клиенты используют Репозитарии Интерфейсов для построения вызова метода «на лету». Инструментальные средства, например, браузеры классов, генераторы приложений и компиляторы, могут использовать эту информацию для получения структуры наследования и определений классов во время выполнения.
• Предоставить самоописываемые объекты. Вы можете вызвать метод getInterface для любого объекта CORBA, чтобы получить его интерфейсную информацию (после того, как такая информация будет установлена в библиотеке интерфейсов).

Репозитарии Интерфейсов могут обслуживаться локально или как ресурсы ведомства или предприятия. Они выступают ценными источниками метаданных о структуре класса и интерфейсе компонента.ORB может потребоваться доступ к нескольким Репозитариям Интерфейсов.

Классы библиотеки интерфейсов: иерархия включения

Репозитарии Интерфейсов реализована как набор объектов, представляющих ее информацию. Эти объекты должны быть постоянными, т.е. должны храниться на энергонезависимом носителе (в постоянной памяти). CORBA группирует метаданные в модули, которые представляют пространства имен. Имена репозитарных объектов уникальны в пределах модуля. CORBA определяет интерфейс для каждой из восьми структур IDL:

• ModuleDef определяет логическое группирование интерфейсов. Подобно файлам IDL, Репозитарии Интерфейсов использует модули для группирования интерфейсов и навигации по группам с помощью имен. Таким образом, вы можете рассматривать модуль в качестве поставщика пространства имен.
• InterfaceDef определяет интерфейс объекта и содержит список констант, определений типов, исключительных ситуаций и описаний интерфейса.
• OperationDef определяет метод объектного интерфейса и содержит список параметров и возбуждаемых методом исключительных ситуаций.
• ParameterDef определяет аргумент метода.
• AttributeDef определяет атрибуты интерфейса.
• ConstantDef определяет именованную константу.
• ExceptionDef определяет исключительные ситуации, возбуждаемые операцией.
• TypeDef определяет именованные типы, которые являются частью определения IDL.

В дополнение к восьми приведенным интерфейсам, которые представляют структуры IDL, CORBA определяет интерфейс Repository, который является корнем для всех модулей, содержащихся в библиотечном пространстве имен. Каждый Репозитарии Интерфейсов представлена глобальным корневым репозитарным объектом. На рис. 9 показана иерархия включения для объектов, принадлежащих этим интерфейсам (или классам). Вы уже заметили, что некоторые из этих объектов, например, экземпляры класса Repository, содержат другие объекты. Некоторые объекты, например, экземпляры класса ModuleDef, является как контейнерами, так и составными частями других объектов. Наконец, некоторые объекты, например, экземпляры класса ExceptionDef, всегда являются составной частью других объектов, но сами не содержат других объектов.

Рис. 9. Иерархия

Иерархия классов Репозитария Интерфейсов

Создатели библиотеки интерфейсов CORBA определили три абстрактных суперкласса (экземпляры абстрактных классов создавать нельзя) IRObject, Contained и Container (рис. 10). Обратите внимание, на этом рисунке показана иерархия наследования в противоположность иерархии включения. Все объекты Репозитария Интерфейсов унаследованы от интерфейса IRObject, который появился только в CORBA 2.0. Этот интерфейс предоставляет операцию для идентификации фактического типа объекта, а также метод destroy. Объекты, являющиеся контейнерами, наследуют навигационные операции от интерфейса Container. Интерфейс Contained определяет поведение объектов, содержащихся в других объектах. Все репозитарные классы унаследованы от Container, от Contained или от обоих сразу посредством множественного наследования. Такая искусная схема позволяет репозитарным объектам координировать свое поведение в соответствии с отношениями включения.

рис. 10. Иерархия Наследования Классов Репозитария Интерфейсов

Репозитарий Интерфейсов: внимательный взгляд

Классы Репозитария Интерфейсов обеспечивают операции для чтения, записи и уничтожения метаданных, хранимых в репозитарии. Операция destroy удаляет объект из библиотеки. Если она вызывается для объекта-контейнера, то уничтожается все его содержимое. Интерфейс Contained содержит операцию move для удаления объекта из его текущего контейнера и добавления в контейнер-получатель. Операции -write, destroy и move появились только в CORBA 2.0.

Доступ к метаданным Репозитария Интерфейсов осуществляется вызовом полиморфных методов для объектов различных типов. Благодаря такой удачной конструкции вы можете извлекать информацию из репозитарных объектов всего лишь девятью методами. Пять из них унаследованы от родительских классов Container и Contained. Оставшиеся четыре метода специфичны для интерфейсов InterfaceDef и Repository. Ниже приведены описания методов навигации и чтения:

• Describe — вызов этого метода для объекта типа Contained возвращает структуру, содержащую информацию IDL, описывающую объект.
• Lookup — вызов этого метода для объекта типа Container возвращает последовательность указателей на содержащиеся в нем объекты..
• Lookup_name — вызывайте этот метод для объекта типа Container чтобы получить объект по имени.
• Contents — вызов этого метода для объекта типа Container возвращает список объектов, содержащихся непосредственно в данном объекте или унаследованных непосредственно от этого объекта. Используйте этот объект для навигации по иерархии объектов. Например, можете начать с объекта Repository и получить список всех содержащихся в нем объектов и т.д.
• Describe_contents — вызов этого метода для объекта типа Container возвращает последовательность указателей на описания содержащихся в нем объектов. Этот метод объединяет операции contents и describe. Вы можете ограничить диапазон поиска, исключая унаследованые объекты или выполняя поиск для определенного типа объекта (например, для типа InterfaceDef).
• Describe_interface — вызов этого метода для объекта типа InterfaceDef возвращает структуру, которая полностью описывает интерфейс, включая его имя, библиотечный идентификатор, номер версии операции, атрибуты и все родительские интерфейсы.
• Is_a - вызов этого метода для объекта типа InterfaceDef возвращает TRUE, если интерфейс идентичен или унаследован непосредственно от интерфейса, указанного во входном параметре.
• Lookup_id — вызов этого метода для объекта Repository позволяет найти в библиотеке объект по его библиотечному идентификатору (Repository ID).
• Get_primitive — вызов этого метода для объекта Repository позволяет получить ссылку на примитивный объект. Это означает неизменный объектный тип, которым владеет библиотека. Примерами примитивных объектов являются объектные ссылки, базовые типы данных и типовые коды.

Совокупность этих методов позволяет проводить навигацию по библиотеке интерфейсов. Вы можете организовать поиск в пространстве имен определенных модулей, чтобы получить объекты, удовлетворяющие условиям поиска. После того, как объект найден, вы можете использовать метод describe для получения информации IDL с его описанием. Помните также, что IRObject, Container и Contained — абстрактные классы, с которыми вы никогда не имеете дело непосредственно. Вместо этого вы вызываете методы объектов библиотеки интерфейсов, которые наследуют свое поведение от этих абстрактных базовых классов.

Как найти интерфейс в первый раз?

Интерфейс объекта можно найти одним из трех способов:

1. Непосредственно вызывая метод ORB Object::get_interface. Этот метод можно вызывать с любой допустимой объектной ссылкой. Он возвращает объект InterfaceDef, который полностью описывает интерфейс объекта. Этот метод полезен, если вы имеете дело с объектом, чей тип не известен во время компиляции.
2. Перемещаясь по пространству имен модуля, используя последовательность имен. Например, если вы знаете имя интерфейса, который расположен перед вами, вы можете начать с просмотра корневого модуля библиотеки. Как только интерфейс найден, вызывайте метод InterfaceDef::describe_interface для получения метаданных, которые описывают искомый интерфейс.
3. Определяя объект InterfaceDef, который соответствует искомому библиотечному идентификатору (Repository ID). Это делается с помощью вызова метода Repository::lookup_id.

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

Объединения репозитариев интерфейсов

Новые расширения CORBA позволяют создавать межгалактические федерации репозитариев интерфейсов, которые оперируют на множестве ORB. Чтобы избежать конфликтов имен, эти репозитарии назначают глобальным интерфейсам и операциям уникальные идентификаторы, которые называются репозитарными идентификаторами (Repository ID). Эти идентификаторы вы можете использовать для размножения копий метаданных по множеству библиотек, сохраняя при этом согласованное представление о них. Это означает, что уникальная идентификация интерфейса сохраняется вдоль множества ORB и библиотек. Например, имея глобальный библиотечный идентификатор, вы можете получить некоторые метаданные интерфейса из локальной библиотеки. Затем вы можете получить дополнительные метаданные того же интерфейса из удаленной библиотеки.

CORBA гарантирует, что определения IDL в разных библиотеках не содержат каких-либо дубликатов, и для этого определяет следующие соглашения по наименованию:

• В пределах Репозитария Интерфейсов составные имена уникально идентифицируют модули, интерфейсы, константы, определения типов, исключительные ситуации, атрибуты, операции и параметры. Составное имя состоит из одного или нескольких идентификаторов, разделенных символами «::».
• Репозитарные идентификаторы обеспечивают глобальную идентификацию модулей, интерфейсов, констант, определений типов, исключительных ситуаций, атрибутов, операций и параметров. Oни используются для синхронизации определений всего множества ORB и репозитариев.

В следующем разделе описаны механизмы для создания таких глобальных репозитарных идентификаторов.

Как может выглядеть репозитарный идентификатор?

Репозитарный идентификатор представляет собой строку, состоящую из трехуровневой иерархии имен. CORBA определяет два формата репозитарного идентификатора:

• Использование имен IDL с уникальными префиксами. Вы создаете репозитарный идентификатор, используя имя IDL, при этом идентификатор составляется из трех компонентов, разделенных двоеточием «:». Первый компонент — строка «IDL». Второй компонент — список идентификаторов, разделенных знаком «/». Первый идентификатор — уникальный префикс, оставшаяся часть — идентификаторы IDL, образующие составное имя. Третий компонент состоит из старшей и младшей частей версии в десятичном формате, разделенных точкой.
• Использование универсальных уникальных идентификаторов (Universal Unique Identifiers — UUID) DCE. DCE предоставляет генератор UUID, который формирует глобально уникальное число, используя текущую дату и время, идентификатор сетевой карты и высокоскоростной счетчик. Практически невероятно, чтобы данный алгоритм построил дублированный UUID. Формат DCE для библиотечного идентификатора также состоит из трех компонентов, разделенных двоеточием «:». Первый компонент — строка «DCE». Второй компонент — текстовое представление UUID. Третий компонент образуется из номера версии в десятичном формате. Обратите внимание, что младшая часть версии не используется. Например, библиотечный идентификатор DCE мог бы выглядеть так "DCE:700dc500-0111-22ce-aa9f:1". (механизм уникальных идентификаторов СОМ, таких как GUID и CLSID, также заимствован из DCE)

Вы можете сопоставить репозитарный идентификатор определениям IDL несколькими способами. Например, его может генерировать программа установки. Или его может генерировать прекомпилятор IDL, основываясь на директивах pragma, которые вы встраиваете в IDL.

Директивы pragma для создания репозитарных идентификаторов

Pragma — это специальная директива компилятора. В данном случае pragma сообщает предкомпилятору IDL, как сгенерировать репозитарный идентификатор и сопоставить его с определенным интерфейсом. CORBA определяет три новых директивы pragma IDL, которые помогут вам создать репозитарный идентификатор:

• prefix pragma устанавливает префикс, который будет добавляться ко всем последующим формируемым прекомпилятором IDL репозитарный идентификаторам, пока не встретится новая директива prefix pragma. Формат этой директивы таков, #pragma prefix <строка>. Вот пример: #pragma prefix DogCatInc.
• version pragma добавляет к репозитарный идентификатору номер версии для конкретного имени IDL. Формат этой директивы: #pragma version <имя> <старшая>.<младшая> Если эта директива не указана, подразумевается версия 1.0. Вот пример: #pragma version Cat 1.3.
• ID pragma сопоставляет произвольную строку репозитарный идентификатора с конкретным именем IDL. Формат этой директивы: #pragma ID <имя> <id>. Вот пример: #pragma ID Cat DCE:700dc500-0111-22ce-aa9f:1.

CORBA IDL без мучений

Самая типичная жалоба программистов C++, Java или Smalltalk состоит вот в чем: почему мы должны выполнять лишний шаг описание наших объектов на IDL? Почему ORB не может понять объекты нашего языка? Некоторые поставщики компиляторов удовлетворили эту просьбу, генерируя CORBA IDL непосредственно из классов других языков. Например, компиляторы MetaWare C++ и VisualAgefor C++ могут генерировать CORBA IDL для SOM прямо из C++.

Еще раньше компания Visigenic/Netscape представила Caffeine, который содержит постпроцессор Java2IIOP, который генерирует имитаторы и скелеты CORBA прямо из байт-кода Java. Наконец, OMG тоже работает над стандартом обратного преобразования Java в CORBA (см. документ OMG orbos/96-12-12). Итак, если вам не нравится IDL, помощь — в пути. Естественно, если вы программист С, то вам неоткуда ждать помощи. В этом языке у вас нет способа определить классы, единственный способ — использовать IDL.

САМОАНАЛИЗ ОБЪЕКТОВ CORBA

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

Интроспективный интерфейс CORBA

Объекты CORBA наследуют свои интроспективные свойства от CORBA:: Object. В дополнение к этому CORBA::ORB предоставляет две полезные вспомогательные функции: object_to_string и string_to_object (методы со светлыми кнопками на табл. 6). Ниже дано быстрое введение в Интроспективность CORBA:

Табл. 6. Методы Интроспекции Объекта CORBA

• CORBA:: Object определяет операции, поддерживаемые всеми объектными ссылками CORBA. Это корневой интерфейс всех объектов CORBA. ORB свободно предоставляет эти операции. Вы просто наследуете их при создании своих объектов. Семь из его методов относятся к интроспективности. В ранее мы уже обсуждали метод getInterface, он возвращает ссылку на InterfaceDef, что есть объект библиотеки интерфейсов, который описывает интересующий нас интерфейс. Вы вызываете getJmplementation для объектной ссылки, чтобы получить объект ImplementationDef. Это объект библиотеки реализации, описывающий реализацию вашего объекта.

Вы вызываете is_nil, чтобы определить, существует ли объект. Вы также можете вызвать non_existent, чтобы определить, не был ли объект уничтожен. Вы вызываете is__equivalent, чтобы определить, эквивалентны ли две объектные ссылки, ORB возвращает TRUE, если ссылка на ваш объект эквивалентна объектной ссылке, переданной в качестве параметра. Если две объектные ссылки идентичны, то они эквивалентны. Две различные объектные ссылки, которые ссылаются на один и тот же объект, тоже эквивалентны. Для оптимизации поиска объектов ORB может использовать внутренне хеш-значение для объектной ссылки. Если хеш-значения двух объектных ссылок различны, такие ссылки не идентичны. Но обратное верно не всегда. Наконец, вы вызываете is_a, чтобы определить, действительно ли экземпляр имеет указанный вами тип.

• CORBA::ORB - псевдообъектный интерфейс, который определят методы общего назначения ORB. Два из них относятся к интроспективности. Вы вызываете string_to_object для создания «строковой версии объекта, которую можно передать куда угодно. Вы вызываете object _to_string для преобразования строкового представления в объектную ссылку, для которой можно вызывать методы. Итак, каждый объект CORBA интроспективен. Вы можете вызывать методы ORB для любой объектной ссылки, чтобы получить информацию о данном объекте. Обратите внимание, что сами метаданные хранятся в библиотеке интерфейсов. Интроспективные методы просто возвращают объектные ссылки на объекты библиотеки интерфейсов.

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

назад | содержание | далее