|
CORBA
CORBA
(Common Object Request Broker Architecture) – Общая Архитектура Брокера
Объектных Запросов - это стандарт, набор спецификаций для промежуточного
программного обеспечения (ППО, middleware) объектного типа. Задача ППО, как
известно, заключается в связывании программных приложений для обмена данными.
Эволюция ППО - это путь от программ передачи информации между конкретными
приложениями, через средства импорта- экспорта данных и организацию мостов между
некоторыми приложениями, через SQL, RPC (Remote Procedure Call), TP мониторы
(Transaction Proceesing) обработки транзакций, Groupware - управление различными
неструктурированными данными (тексты, факсы, письма электронной почты, календари
и т.д.) и, наконец, MOM - Message-Oriented Middleware (асинхронный обмен
сообщениями между сервером и клиентом), к созданию распределенных компьютерных
систем. Элементы этих систем могут взаимодействовать друг с другом как на одной
локальной машине, так и по сети. CORBA позволяет организовать единую
информационную среду, элементы которой могут общаться друг с другом, вне
зависимости от их конкретной реализации, "прописки" в распределенной системе,
платформы и языка их реализации [1]. CORBA образует нижний слой архитектуры
промежуточного слоя, обеспечивающий технологическую платформу
интероперабельности. Семантика объектов на этом уровне не принимается во
внимание [8]. Брокер Объектных Заявок (Object
Request Broker – ORB) - это промежуточное ПО, которое устанавливает клиент-
серверные отношения между объектами в распределенной компьютерной среде [1]. ORB
обеспечивает механизмы, позволяющие объектам посылать или принимать заявки,
отвечать на них и получать результаты, не заботясь о положении других объектов в
распределенной среде и способе их реализации. ORB отвечает за поиск реализации
объекта-сервера для выполнения заявки, подготовку реализации этого объекта
кприему заявки и за передачу данных, являющихся результатом выполнения заявки
[8]. Брокер представляет собой механизм, позволяющий объектам выдавать заявки и
получать ответы прозрачным образом. Благодаря этому обеспечивается
интероперабельность между приложениями на различных аппаратных платформах в
неоднородных распределенных средах. Необходимо подчеркнуть, что речь идет здесь
о Интероперабельность брокеров распространяет эту
возможность на случаи, когда объекты-клиенты и объекты-серверы ассоциированы с
несколькими однотипными или разнотипными брокерами. Под однотипными брокерами
понимаются здесь различные установки одной и той же реализации брокера какого-
либо производителя, а установки различных реализаций брокера мы называем
разнотипными брокерами. Интероперабельность брокеров трактуется OMG как
способность объекта-клиента, управляемого брокером-1, вызывать определенные IDL-
спецификациями операции объекта-сервера, управляемого брокером-2, при условии,
что брокер-1 и брокер-2 были разработаны независимо друг от друга. Иначе говоря,
такие вызовы должны быть независимы от того, одним и тем же или разными
(возможно, разнотипными) брокерами поддерживаются взаимодействующие объекты.
CORBA определяет среду для различных реализаций ORB, поддерживающих общие
сервисы и интерфейсы (рис.1). Это обеспечивает мобильность клиентов и реализаций
объектов по отношению к различным реализациям ORB. ORB обеспечивает
интероперабельность компонентов глобального объектного пространства. Определения
интерфейсов объектов могут быть помещены в Репозитарий Интерфейсов (Interface
Repository) двумя способами: статически - в результате спецификации на IDL, или
динамически. Репозитарий представляет компоненты интерфейса как объекты и
обеспечивает доступ к ним в период выполнения. При
формировании заявки клиент может использовать интерфейс динамического вызова или
генерируемый компилятором IDL стаб (stub) - локальную процедуру вызова заданной
операции при обращении к ней. Клиент может непосредственно взаимодействовать
с ORB. В этом случае ORB ищет соответствующий код реализации объекта, пересылает
ему параметры заявки и передает управление. Реализация объекта принимает
параметры заявки через сгенерированный компилятором IDL скелетон (Skeleton) и
при этом может обращаться к Объектному Адаптеру (Object Adaptor) и ORB [8].
Основная функция объектного адаптера, используемого для реализации CORBA-
объекта, - обеспечение доступа к сервисам брокера объектных запросов. Объектный
адаптер предоставляет все низкоуровневые средства для связи объекта с его
клиентами. В число этих средств входят: обеспечение
безопасности взаимодействия, установление соответствия между ссылками на удаленные
объекты и реальными экземплярами объектов, Спецификация OMG CORBA определяет базовый объектный адаптер,
который должен быть реализован во всех брокерах запросов. Basic Object Adapter
(BOA) - это набор интерфейсов для создания ссылок на удаленные объекты,
регистрации объектов, авторизации запросов и активизации приложений. Базовый
объектный адаптер является решением первоочередной задачи обеспечения связи
между реализацией объекта и брокером запросов. Для организации взаимодействия
между ORB и, например, системой управления базами данных должен быть разработан
свой объектный адаптер [10]. Скелетон – серверная программа, которая
связывает сервант с объектным адаптером, позволяя объектному адаптеру
перенаправлять запросы к соответствующему серванту. При статических методах
вызова скелетон формируется при компиляции IDL кода. При динамических – не
используется[12]. В структуре ORB выделяется Ядро, обеспечивающее внутреннее
представление объектов и передачу заявок, и набор надстраиваемых компонентов,
интерфейсы которых маскируют различия в реализации ORB. Задачей Ядра является
обеспечение мобильности программ и спецификаций типов, а также достижение
интероперабельности компонентов в распределенной неоднородной среде. Клиенты
максимально мобильны и должны работать без изменения исходного кода в среде
любого ORB, который поддерживает отображение IDL в соответствующий язык
программирования. Языковое отображение включает определение характерных для
IDL типов данных и интерфейсов доступа к объектам средствами соответствующего
языка программирования. Отображение определяет структуру интерфейса стаба
клиента, интерфейса динамического вызова, скелетона реализации объекта,
объектных адаптеров и прямые интерфейсы ORB. Для определенного языкового
отображения обеспечивается программный интерфейс к стабу для каждого типа
интерфейса. Стабы осуществляют обращения к ORB, используя скрытые и, возможно,
оптимизированные для определенного ядра ORB интерфейсы. Для определенного
языкового отображения и, возможно, в зависимости от используемого Объектного
Адаптера будет обеспечиваться доступ к методам, реализующим каждый объектный
тип. Вызов этих методов осуществляется через скелетон. Наличие скелетона не
подразумевает существование соответствующего стаба клиента. Возможно, и
обратное. Можно написать Объектный Адаптер, который не использует скелетоны для
вызова методов реализации объектов [10]. Доступно широкое множество способов
реализации конкретных ORB-ов. Далее будут приведены примеры таких реализаций.
Следует иметь ввиду, что конкретный ORB может быть реализован сразу несколькими
способами. Если
имеется подходящий механизм коммуникаций, то возможна реализация ORB-а в виде
набора подпрограмм как со стороны клиента, так и со стороны реализации объекта.
Вызовы методов могут транслироваться в работу со средствами взаимодействия
процессов (Inter Process Communication - IPC). С целью обеспечения централизованного сбора и управления всевозможной
информацией, ORB может быть реализован в виде отдельного приложения.
Взаимодействующие приложения устанавливают контакт с ORB-ом посредством
нормальных механизмов IPC. Для повышения надежности,
защиты данных и достижения лучшей производительности ORB может быть реализован
как часть операционной системы. При этом ссылки на объект могут быть сделаны
постоянными, таким образом уменьшая время, необходимое для обработки каждого
запроса. При реализации ORB-а как части операционной системы возможны
всевозможные виды оптимизации, такие как избежание кодирования и декодирования
данных, если клиент и сервер находятся на одной и той же машине. Если код объекта занимает небольшой объем и не
требует никаких дополнительных средств, то он может быть выполнен в виде
библиотеки. При этом все заглушки на самом деле будут являться настоящими
методами. При этом предполагается, что, имея доступ к данным реализации, клиент
не разрушит эти данные. Один из ключевых
принципов архитектуры CORBA, обеспечивающий интероперабельность приложений,
заключается в независимости спецификации интерфейсов объектов от их реализации.
Именно для решения этой задачи в комплексе стандартов CORBA предусматривается
специальный язык для определения интерфейсов - OMG IDL (Interface Definition
Language). Определение интерфейса объекта средствами OMG IDL полностью
характеризует все операции, которые могут выполняться данным объектом по заявкам
клиентов. Это определение служит источником информации для разработки программ-
клиентов, обращающихся к объектам с заявками на выполнение операций,
предусмотренных определениями их интерфейсов. Поскольку определение
используемого клиентом интерфейса должно быть доступно его реализации,
необходимо осуществлять отображение спецификаций, заданных в языке OMG IDL, в
язык реализации клиента. Для описания синтаксиса языка в спецификациях
стандарта CORBA используется нотация, аналогичная EBNF (Extended Backus-Naur
Format - Расширенный формат Бэкуса-Наура). < > - нетерминальный символ, представляемый заключенным в скобки
понятием + - возможность повторения
предшествующей синтаксической конструкции один или более раз [ ] - заключенная в скобки синтаксическая конструкция является
необязательной. При отображении IDL в различные языки программирования CORBA
требует, чтобы конструкции IDL были адекватно отображены: все базовые и
конструируемые типы, ссылки на объекты и константы, определяемые в IDL, вызовы
операций, исключительные ситуации, доступ к атрибутам, сигнатуры операций в
виде, определенном ORB (интерфейс динамического вызова). Реализация отображения
дает возможность программисту иметь доступ ко всем функциям ORB в виде, удобном
для соответствующего языка программирования. Все реализации ORB должны следовать
стандарту OMG отображения для конкретного языка программирования. Основные
вопросы, вызывающие трудности при разработке стандартов отображения IDL,
включают выбор представления объекта ORB в конкретном языке программирования
(следует различать, как объект представляется в программе, как он передается в
качестве параметра, как осуществляется вызов операций на его интерфейсе);
представление исключительных ситуаций в конкретном языке; представление
интерфейсов ORB. К настоящему времени OMG определены отображения IDL в языки
C, C++ и Smalltalk. Завершается разработка стандарта отображения IDL в язык Ada.
Эта работа не проста. Так, только обсуждение и принятие отображения IDL в С++
заняло более двух лет напряженной работы, подтвердившей важность технологии
принятия стандартов, используемой OMG [10]. Универсальным
Межброкерным Протоколом (General Inter-ORB Protocol, сокращенно GIOP). GIOP
является универсальным, поскольку он не зависит от конкретной сетевой
транспортной среды и может быть отображен в любой транспортный протокол,
поддерживающий виртуальные соединения. Одно из таких отображений - отображение
GIOP в протокол TCP/IP - определено CORBA 2.0 в качестве (Internet Inter-ORB Protocol, сокращенно IIOP).
Назначение протокола GIOP/IIOP заключается в том, чтобы поддержать сети брокеров
в рамках Internet и за ее пределами. Согласно GIOP, внутренняя архитектура
брокеров предполагается неизвестной. Подход, который может быть выбран
конкретным брокером для поддержки GIOP/IIOP, не определяется. Все, что требуется
для согласованного включения брокера в компьютерную сеть, - это существование
связанных с ним компонентов, способных посылать и принимать сообщения
IIOP. (Common Data Representation - CDR), являющегося, по
существу, коммуникационным синтаксисом, отображающим значения типов данных OMG
IDL в формат передачи данных между брокерами и межброкерными мостами
(агентами); форматы передаваемых между агентами сообщений GIOP,
которые введены для поддержки объектных заявок, установления местоположения
реализаций объектов и управления транспортными
соединениями; Протокол IIOP, который можно считать специализацией GIOP,
определяет дополнительно, как агенты открывают соединения TCP/IP и используют их
для передачи сообщений GIOP. GIOP трактует транспортное соединение как
асимметричное. Определяются две различных роли использования соединения: роль
клиента и роль сервера. Клиент образует соединение и посылает объектные заявки,
сервер принимает заявки и посылает ответы. Сервер не может посылать объектных
заявок. Соединение может использоваться совместно многочисленными клиентами в
одном брокере для посылки независимых заявок различным объектам в определенном
брокере или сервере. Допускается асинхронная посылка заявок при их произвольном
чередовании в соединении. В передаваемых сообщениях допускается произвольный
порядок байтов (зависящий от архитектуры процессора), устанавливаемый
отправителем сообщения. Получатель сообщения должен изменить этот порядок нужным
для себя образом. Установлены выравнивания значений базовых типов IDL (char,
octet, short, unsigned short, long, unsigned long, float, double, boolean, enum)
по границе естественных для них полей. Установлено кодирование конструируемых
типов IDL (struct, union, array, sequence, string), не накладывающее
дополнительных требований выравнивания по отношению к тем, которые установлены
для базовых типов [9]. Объектная
модель OMG определяет общую объектную семантику для спецификации базовых
характеристик объектов стандартным, независимым от реализации образом.
Объектная модель OMG определяется в виде объектной модели - ядра (Core Object
Model - COM) и совокупности расширений. Объектная модель - ядро - специфицирует
некоторый набор базовых понятий. Примерами понятий COM являются объекты,
операции, типы, отношение тип/подтип, наследование, интерфейс типа. Каждое
расширение вводит дополнительный набор понятий. Расширяться может либо COM, либо
уже существующие и согласованные расширения. При этом вводится понятие профиля,
как некоторой комбинации COM, и одного или нескольких расширений, вместе
поддерживающих определенную целевую архитектуру [3]. Объектная модель CORBA
определяет взаимодействие между клиентами и серверами. Клиенты - это приложения,
которые запрашивают сервисы, предоставляемые серверами. Объекты-серверы содержат
набор сервисов, разделяемых между многими клиентами. Операция указывает
запрашиваемый сервис. Интерфейсы объектов описывают множество операций, которые
могут быть вызваны клиентами определенного объекта. Реализации объектов - это
приложения, исполняющие сервисы, запрашиваемые клиентами [10]. Клиентом является компонент, который обращается к интерфейсам
других компонентов. Компоненты, предоставляющие свои интерфейсы другим
компонентам, являются серверами. В трехуровневой архитектуре понятие клиента и
сервера весьма условно. Компонент распределенной системы может выступать
одновременно в роли клиента для другого компонента и быть сервером для других
компонентов системы (рис. 2). Клиентские стабы (заглушки) и серверные
скелетоны выступают в роли "клея", который связывает языково-независимую
спецификацию интерфейса на IDL с языково-зависимым кодом реализации. Клиентские
стабы каждого интерфейса включаются клиентами, которые используют эти
интерфейсы. Клиентский стаб для конкретного интерфейса обеспечивает пустые
реализации для каждого метода этого интерфейса. Перед тем, как выполнить сервер
функциональности, стаб клиента соединяется с Брокером Объектных Заявок, чтобы
передать и получить параметры. Стаб клиента, который генерируется IDL-
компилятором, это часть кода, которая делает доступным клиенту интерфейс
конкретного CORBA сервера. Скелетон сервера, также генерируемый IDL-
компилятором, это часть кода, которая обеспечивает "каркас", на котором построен
код реализации сервера для конкретного интерфейса. Трехуровневая архитектура информационных систем, согласно
спецификациям OMG, включает в себя системы управления данными, сети
взаимодействующих CORBA-объектов и пользовательские интерфейсы для представления
данных. Однако очевидно, что в большинстве ИС требуется некоторое множество
системных объектных сервисов, которые не зависят от предметной области и
обеспечивают базовую функциональность для управления распределенными объектами.
С целью облегчения создания распределенных приложений консорциум OMG
стандартизовал наиболее часто употребляемые сервисы (спецификация CORBAservices
1.0) [10]. Сервис Жизненнго Цикла (Life Cycle Service) определяет операции
создания, копирования, перемещения и удаления компонентов на шине [7]. Сервис
Именования (Naming service) служит для управления и хранения ссылок на CORBA-
объекты. Его основная задача состоит в том, чтобы универсальным образом
организовать соединение объектов друг с другом. Служба имен представляет собой
хранилище объектных ссылок. Обращение к этому сервису выполняется для получения
нужной объектной ссылки, идентифицируемой по читаемому (понятному разработчику)
имени объекта. Сервис Долговременного Хранения
(Persistence service) предоставляет набор универсальных интерфейсов для
сохранения экземпляров объектов в долговременной памяти. Сервис разработан таким
образом, что возможна его реализация на основе объектной базы данных. Сервис
Транзакций (Transaction service) поддерживает множество моделей транзакций,
включая вложенные транзакции. Сервис транзакций необходим для корректной работы
приложений в многопользовательском режиме. Сервис Отношений (Relationship
service) реализует логические связи между CORBA-объектами. Сервис определяет два
дополнительных типа объектов: связь и роль. Роль представляет собой CORBA-
объект, отражающий характер связи, а связь характеризует зависимости объектов
прикладной области. Сервис Контроля Совместного Доступа (Concurrency control
service) позволяет клиентам координировать свои действия при использовании
разделяемых ресурсов. Управление разделяемыми ресурсами осуществляется с помощью
блокировок. Каждая блокировка ассоциируется с единственным ресурсом и
единственным клиентом. Сервис определяет также несколько режимов блокировок,
которые соответствуют различным способам доступа. Сервис Внешнего
Представления (Externalization service) формирует копию CORBA-объекта в виде
некоторого внешнего представления - файла, элемента базы данных и т. д.
[10]. Сервис Запросов (Query Sevice) обеспечивает поддержку запросов для
объектов. Он представляет собой надмножество SQL и основан на расширенных
спецификациях SQL3 и языке объектных запросов (Object Query Language -
OQL). Сервис Лицензирования (Licensing Service) предоставляет операции для
отслеживания использования компонентов, чтобы обеспечить законную компенсацию их
использования. Данный сервис поддерживает некоторую модель использования
компонента в любой точке его жизненного цикла. Сервис Свойств (Properties
Service) предоставляет операции, которые позволяют вам ассоциировать именованные
величины (или свойства) с любым компонентом. Сервис Времени (Time Service)
предоставляет интерфейс для синхронизации времени в среде распределенных
объектов. Кроме того, предусматривает операции для определения и управления
событиями, ориентированными на определенное время. Сервис Безопасности
(Security Sercice) предоставляет полную инфраструктуру для обеспечения
безопасности распределенных объектов. Он поддерживает аутентификацию, списки
контроля доступа, конфиденциальность, безотказность и делегирования прав доступа
между объектами. Сервис Коммерции (Trade Service) обеспечивает "Желтые
страницы" для объектов; это дает возможность объектам оповещать о своих сервисах
и выставлять заявки о себе на "рынок труда". Сервис Контейнеров (Collection
Service) предоставляет интерфейсы CORBA для создания и поддержки общедоступных
контейнеров [7]. Известно, что службы OMG не являются независимыми друг
от друга. Часть из них может быть создана на базе других служб. Согласно
рекомендациям OMG, существует представленный на рис. 3 граф зависимостей одной
службы от другой [11]. Универсальные
средства предоставляют поддержку интерфейсов высокого уровня и делятся на два
типа: горизонтальные и вертикальные. Горизонтальные универсальные средства
определяют интерфейсы, не зависящие от предметной области. В настоящее время
существует предварительная спецификация горизонтальных универсальных средств,
состоящая из следующих разделов: .
Они покрывают аспекты, касающиеся представления информации, и включают
инструменты для разработки интерфейса, средства для автоматизации этой работы,
спецификации на рабочий стол (desktop) пользователя и т. д. . Они предоставляют операции, с помощью которых можно
моделировать, описывать, сохранять, выбирать, перемещать информацию и
обмениваться ею. Предполагается, что данный набор должен состоять из следующих
спецификаций: а) информационное моделирование (определяет правила, по
которым осуществляется структуризация и доступ к информации), в) информационный обмен, г) стандарты
перекодировки и представления, поддерживающие обмен информацией через
разделяемые ресурсы, сетевые протоколы или программные
интерфейсы. . Они задают множество
утилит, реализующих функции системного администрирования, то есть определяют
интерфейсы основных операций, отвечающих за управление, мониторинг,
безопасность, конфигурирование и т. д. .
Предполагается, что данный набор будет представлен четырьмя спецификациями:
службы управления потоками работ (workflow facility), службы программных агентов
(agent facility), службы управления правилами (rule management facility), службы
автоматизации (automation facility). Вертикальные средства предназначены для
поддержки конкретных областей рынка: финансовой деятельности, промышленного
производства, медицины и т. д. Разрабатываются спецификации следующих средств:
. Специфицируют доступ и обмен
графическими данными. Роль этой службы заключается в поддержке приложений
конечного пользователя по проверке, обработке, визуализации и сохранению
графических данных. . Специфицируется множество сетей, протоколов и
правил их использования, а также множество репозитариев информации и набор
средств, обеспечивающих пользователям и приложениям доступ к этой информации.
.
Обеспечивают интеграцию производственных функций предприятия с помощью
компьютеров. В число объединяемых функций могут входить также управление
процессами разработки, контроль качества, финансовые и маркетинговые операции.
. Службы этой спецификации
должны обеспечить базис, на основе которого возможно быстрое построение и
функционирование эмулируемой модели. . Эта предметная область характеризуется большим
количеством данных и высокой сложностью алгоритмов. . Включают все формы коммерческих
транзакций: обмен валюты, управление платежами, продажами и т.п. . Обслуживают выбор, разработку, построение и
эволюцию приложений, составляющих корпоративную информационную систему. Данные
спецификации включают средства анализа, проектирования, реализации, тестирования
и поддержки системы [10]. В разделе дан обзор
информационной архитектуры систем на основе объектной технологии и принципов
интероперабельности компонентов, развиваемых OMG. Нетрудно видеть, что
архитектура CORBA специально ориентирована на достижение целей - насущных
потребностей разработки прикладных систем, сформулированных в начале статьи:
обеспечение функционирования систем в условиях информационной и
реализационной неоднородности, распределенности и автономности информационных
ресурсов; повторное использование
неоднородных информационных ресурсов; Объектный подход развивается около 25 лет. За это время он
прошел путь от академических исследований до промышленных, стандартизованных
решений, позволяющих создавать по-настоящему большие, распределенные
корпоративные системы, способные эволюционировать экономически эффективным
образом. Можно предположить, что консолидация современных сетевых, реляционных и
объектно-ориентированных технологий позволит выйти на еще более высокий уровень
интеграции и качества информационных систем. Рассматриваемая архитектура
убедительно показывает, что время объектных технологий, технологий конца 20 -
начала 21 века, пришло.
| |
