Задачей консорциума OMG является определение набора спецификаций, позволяющих строить интероперабельные информационные системы. Спецификация OMG -- The Common Object Request Broker Architecture (CORBA) является индустриальным стандартом, описывающим высокоуровневые средства поддерживания взаимодействия объектов в распределенных гетерогенных средах.
CORBA специфицирует инфраструктуру взаимодействия компонент (объектов) на представительском уровне и уровне приложений модели OSI. Она позволяет рассматривать все приложения в распределенной системе как объекты. Причем объекты могут одновременно играть роль и клиента, и сервера: роль клиента, если объект является инициатором вызова метода у другого объекта; роль сервера, если другой объект вызывает на нем какой-нибудь метод. Объекты-серверы обычно называют "реализацией объектов". Практика показывает, что большинство объектов одновременно исполняют роль и клиентов, и серверов, попеременно вызывая методы на других объектах и отвечая на вызове извне. Используя CORBA, тем самым, имеется возможность строить гораздо более гибкие системы, чем системы клиент-сервер, основанные на двухуровневой и трехуровневой архитектуре [6].
IDL
Язык OMG IDL (Interface Definition Language -- Язык Описания Интерфейсов) представляет собой технологически независимый синтаксис для описания интерфейсов объектов. При описании программных архитектур, OMG IDL прекрасно используется в качестве универсальной нотации для очерчивания границ объекта, определяющих его поведение по отношению к другим компонентам информационной системы. OMG IDL позволяет описывать интерфейсы, имеющие различные методы и атрибуты. Язык также поддерживает наследование интерфейсов, что необходимо для повторного использования объектов с возможностью их расширения или конкретизации.
IDL является чисто декларативным языком, то есть он не содержит никакой реализации. IDL-спецификации могут быть откомпилированы (отображены) в заголовочные файлы и специальные прототипы серверов, которые могут использоваться непосредственно программистом. То есть IDL-определенные методы могут быть написаны, а затем выполнены, на любом языке, для которого существует отображение из IDL. К таким языкам относятся C, C++, SmallTalk, Java и Ada.
Рисунок 5: CORBA IDL отображения в модели Клиент/Сервер
С помощью 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>]
.
.
}
Репозитарий Интерфейсов (Interface Repositary), содержащий определения интерфейсов на IDL, позволяет видеть интерфейсы доступных серверов в сети и программировать их использование в программах-клиентах.
Object Management Architecture
Осенью 1990 года OMG впервые опубликовала документ Object Management Architecture Guide (OMA Guide). Он был подкорректирован в сентябре 1992. Детали Common Facilities (Общие средства) были добавлены в январе 1995. Следующий рисунок показывает четыре основные элемента этой архитектуры:
Рисунок 6: OMG's Object Management Architecture
Object Request Broker определяет объектную шину CORBA.
Common Object Services представляют собой коллекцию служб, снабженных объектными интерфейсами и обеспечивающих поддержку базовых функций объектов [7].
Common Facilities образуют набор классов и объектов, поддерживающих полезные во многих прикладных системах функции. Прикладные объекты представляют прикладные системы конечных пользователей и обеспечивают функции, уникальные для данной прикладной системы [7].
Application Objects -- это прикладные бизнес-объекты и приложения, которые являются основными потребителями всей CORBA инфраструктуры.
Object Request Broker
ORB (Object Request Broker, то есть брокер объектных запросов) -- это объектная шина. Она позволяет объектам напрямую производить и отвечать на запросы других объектов, расположенных как локально (на одном компьютере, но в разных процессах), так и удаленно. Клиента не интересуют коммуникационные и другие механизмы, с помощью которых происходит взаимодействие между объектами, вызов и хранение серверных компонент. CORBA-спецификации затрагивают лишь IDL, отображение в другие языки, APIs для взаимодействия с ORB и сервисы, предоставляемые ORB.
CORBA ORB предоставляет широкий набор распределенных middleware услуг. Шина ORB позволяет объектам находить друг друга прямо в процессе работы и вызывать друг у друга различные службы. Она является гораздо более тонкой системой, чем другие клиент/сервер middleware-системы, такие как RPC (Remote Procedure Calls) или MOM (Message-Oriented Middleware).
От RPC к ORB
Чем механизм вызовов CORBA отличается от механизма RPC? Да, эти механизмы похожи, но тем не менее между ними есть серьезные различия [5]. С помощью RPC можно вызвать определенную функцию. А с помощью ORB можно вызвать метод у определенного объекта. Разные объекты классов могут по-разному отвечать на вызов одного и того же метода. Так как каждый объект управляет своей собственной (в добавок личной) информацией, то метод будет вызван на сугубо конкретных данных.
В случае RPC, будет выполнен лишь какой-то конкретный кусок кода сервера, который и взаимодействует с данными сервера. Все функции с одинаковыми именами будут выполнены абсолютно одинаково. В RPC отсутствует конкретизация вызовов, в том смысле, в каком это происходит в ORB. В ORB все вызовы функций происходят к конкретным объектам, тем самым, результаты этих функций могут быть совершенно различны. Вызовы функций обрабатываются в специфичной для каждого отдельного объекта форме.
Достоинства ORB
В теории, CORBA представляется как лучшая клиент/сервер middleware-система, но на практике она хороша лишь настолько, насколько хороши продукты, ее реализующие. К основным коммерческим ORB относятся: Orbix от фирмы IONA Technologies; DSOM от IBM; ObjectBroker от Digital; JOE от Sun; Visibroker от Visigenic и Netscape; ORB+ от HP.
Небольшой список тех выгод, которыми обладает каждая CORBA ORB [5]:
Статические и динамические вызовы методов. CORBA ORB предоставляет возможность либо статически определить вызовы методов прямо во время компиляции, либо находить их динамически, но уже во время работы программы.
Отображение в языки высокого уровня. CORBA ORB позволяет вызывать методы у серверных компонент используя любой из некоторого списка языков высокого уровня -- C, C++, SmallTalk, Java и Ada. Совершенно неважно, на каком языке написаны объекты. CORBA отделяет интерфейсы от реализации и предоставляет языково-независимые типы данных, что позволяет осуществлять вызов методов, минуя границы какого-то конкретного языка программирования и конкретной операционной системы.
Само-описывающаяся система. С помощью своих метаданных, CORBA позволяет описывать интерфейс любого сервера, известного системе. Каждая CORBA ORB должна поддерживать Репозитарий Интерфейсов, который хранит необходимую информацию, описывающую синтаксис интерфейсов, поддерживаемых серверами. В своей работе клиенты используют эти метаданные для осуществления вызовов к серверам.
Прозрачность. ORB может выполняться как сам по себе (например на портативном компьютере), так и в окружении целого мира других ORB, с которыми она взаимодействует путем CORBA 2.0 IIOP (Internet Inter-ORB Protocol) протокола. ORB может осуществлять меж-объектное взаимодействие и для одного процесса, и для нескольких процессов, выполняющихся на одной машине, и для процессов, чье выполнение происходит в сети, под разными операционными системами. Реализация этих взаимодействий, однако, нисколько не затрагивает сами объекты. В общих чертах, при использовании технологии CORBA, разработчик не должен беспокоиться ни о таких вещах как расположение серверов, запуск (активирование) объектов, выравнивание размера переменных в зависимости от платформы и операционной системы, ни и о том, как осуществляется передача сообщений. Решение всех этих задач берет на себя продукт, поддерживающий стандарт CORBA.
Встроенная безопасность. Все свои запросы ORB дополняет некоторой контекстной информацией которая обеспечивает сохранность данных.
Полиморфизм при вызове методов. Как уже говорилось, ORB не просто вызывает удаленный метод -- ORB вызывает метод на удаленном объекте. То есть выполнение одних и тех же функций на разных объектах будет приводить к различным действиям, в зависимости от типа объекта.
Object Services
CORBA Object Services представляет собой набор сервисов системного уровня, представимых в виде компонент с некоторыми определенными IDL-интерфейсами. Эти компоненты, в некотором смысле, дополняют функциональность ORB. Их можно использовать для создания, именования компонент и многого другого. На сегодняшний день OMG определил четырнадцать стандартных сервисов.
К сожалению, практически все коммерческие ORB не поддерживают ни один из сервисов, и лишь немногие (Visibroker) -- один, два.
Common Facilities
Common Facilities (общие средства) заполняют пространство между ORB и объектными службами с одной стороны, и прикладными службами, с другой. Таким образом, ORB обеспечивает базовую инфраструктуру, Object Services -- фундаментальные объектные интерфейсы, а задача Common Facilities -- поддержка интерфейсов сервисов высокого уровня, которые, впрочем, могут включать специализацию Object Services. Таким образом, операции, представляемые Common Facilities, предназначены, в частности, для использования Object Services и прикладными объектами. Реализуется это посредством наследования стандартных Интерфейсов [7].