Технология распределенных вычислений CORBA (Common Object Request Broker Architecture) предложена ассоциацией OMG (Object Management Group). Это инвариантная к приложениям и языку программирования компонентно-ориентированная (объектная) сетевая технология. Архитектура CORBA представлена на рис. 1.
Схематично взаимодействие компонентов в технологии CORBA можно представить следующим образом. Клиент обращается с запросом на выполнение некоторой процедуры или получение некоторых данных. Запрос направляется к посреднику, называемому ORB (Object Request Broker), который способен выполнить действия, необходимые для нахождения нужного объекта в сети и его подготовки к обработке запроса. В посреднике имеется предварительно сформированный каталог (реестр или репозитарий) интерфейсов процедур с указанием компонентов-исполнителей. Посредник перенаправляет запрос соответствующему исполнителю. Исполнитель может запросить параметры процедуры. После выполнения процедуры полученные результаты возвращаются клиенту.
Рис. 1.   Архитектура CORBA
При этом пользователь оперирует удобными для его восприятия идентификаторами компонентов и интерфейсов, а с помощью каталога эти идентификаторы переводятся в указатели (ссылки), используемые аппаратно-программными средствами и которые однозначно определяют интерфейс в распределенной сети из многих компьютеров.
Для описания интерфейсов и для организации связи клиента с серверными компонентами используется язык IDL (предложенный OMG и не совпадающий с языком IDL в RPC). Язык IDL в CORBA позволяет описывать интерфейсы создаваемых компонентов. Описание, называемое метаданными, представляется в виде модуля метаданных, модуль включает заголовок, описания типов данных, интерфейсов и операций. В заголовке указывается идентификатор модуля. В части типов данных перечисляются атрибуты, возвращаемые значения, исключительные ситуации. Примерами типов данных могут служить типы базовые (например, float, double, char, boolean, struct), конструируемые пользователем (например, записи и массивы) и объектные ссылки, указывающие на интерфейсы компонентов. Описание интерфейсов начинается с ключевого слова interface, за которым следуют идентификаторы данного интерфейса и возможно наследуемых интерфейсов. Далее описываются операции (методы) в виде идентификаторов операций с возможными перечислениями параметров операций и указанием их принадлежности к входным или выходным данным.
Классы объектов (программные модули) должны быть реализованы в CORBA-среде. Для этого компилятор IDL выполняет следующие действия. Во-первых, метаданные для каждого класса объектов помещаются в специальную базу данных, имеющуюся в ORB, — репозитарий интерфейсов. Во-вторых, компилятор создает для каждого определенного на IDL метода клиентский и серверный стабы – программные модули, обеспечивающие доступ к компонентам.
С помощью репозитария интерфейсов приложения во время выполнения могут получать информацию о структуре и форматах IDL-интерфейсов, необходимую для генерации динамических запросов.
Определения интерфейсов хранятся в репозитарии в виде множества объектов, содержащих описания операций, возможных исключительных ситуаций, типов параметров. Репозитарий обеспечивает также механизм доступа к этим объектам. Являясь одной из главных компонент стандарта CORBA, IR поддерживает взаимодействие брокеров различных производителей.
Физически репозитарий интерфейсов является программным компонентом, имеющим собственный IDL-интерфейс. Через этот интерфейс различные приложения и получают данные о других CORBA-объектах.
Спецификация репозитария интерфейсов удобна для построения приложений, в которых данные, параметры и функции могут изменяться во время работы приложений. К этой категории относятся CASE-средства, навигаторы и т.д.
Стабы используются для обеспечения взаимодействия клиента и сервера, функционирующих в разных адресных пространствах или на разных компьютерах (в том числе и в разных операционных системах). В терминологии CORBA они называются stub и skeleton. Stub (стаб) - это представитель сервера в адресном пространстве клиента (иногда для его обозначения используют и термин proxy). Skeleton (скелетон)- это представитель клиента в адресном пространстве сервера.
Основное назначение стабов — выполнение маршалинга и организация передачи данных через сеть. Маршалингом называют упаковку параметров в стандартный формат для пересылки. Маршалинг необходим по той причине, что представление данных в разных компьютерных средах может быть различным (например, различия в кодировке символов, в изображении чисел с плавающей запятой). Клиентский стаб будет использоваться для передачи вызовов и данных от клиента в сеть, а скелетон, называемый также серверным стабом, будет вызывать метод уже в среде сервера и возвращать результаты.
Клиентское приложение взаимодействует со stub-объектом, вызывая его методы (названия которых совпадают с названиями методов серверного объекта). В действительности stub-объект обращается к клиентской части Object Request Broker (ORB), обращающейся, в свою очередь, к специализированному сервису middleware - Smart Agent (он может функционировать на каком-либо из компьютеров сети), представляющему собой не что иное, как directory service - службу, обеспечивающую поиск доступного сервера, содержащего реализацию запрашиваемого клиентом объекта.
Когда сервер найден, в его адресном пространстве создается запрошенный серверный объект, содержащий, в свою очередь, skeleton-объект, которому ORB передает запрос клиента с помощью базового объектного адаптера Basic Object Adapter (BOA). BOA - это набор интерфейсов для создания ссылок на удаленные объекты, регистрации объектов, авторизации запросов и активизации приложений. Используя эту службу, skeleton регистрирует созданный серверный CORBA-объект с помощью Smart Agent, а также сообщает о доступности, факте создания и о готовности объекта принимать запросы клиента.
На серверной стороне данные о каждом новом классе объектов, поддерживаемом конкретным сервером, заносятся в репозитарий реализаций. Эту операцию выполняет объектный адаптер. Обычно в ORB имеется несколько объектных адаптеров, обслуживающих разные группы компонентов (так, возможны объектные адаптеры, ориентированные на библиотеки, на базы данных, на группу отдельных программ и т.п.).
Объектные адаптеры выполняют также ряд других отмеченных выше функций, в частности, активацию и дезактивацию компонентов. Возможны разные способы активации и дезактивации компонентов. В первом из них для обслуживания каждого клиентского запроса создается своя копия компонента. В других способах копии не создаются, компонент обслуживает все запросы с разделением или без разделения во времени.
При реализации запроса брокер через объектный адаптер активирует соответствующий компонент. Далее клиент-серверное взаимодействие происходит через стабы.
Изложенную схему клиент-серверного взаимодействия называют статической. В CORBA предусмотрены также динамические вызовы. Для их осуществления не требуется предварительного формирования стабов с помощью компилятора языка IDL. Вместо стабов, специфических для каждого вызываемого метода, в CORBA используются специальные программы динамического взаимодействия, инвариантные к вызываемым методам. При этом необходимые данные для обращения к компоненту должны быть представлены в клиентской программе, в частности, они могут быть предварительно получены из репозитария интерфейсов. Динамические вызовы обеспечивают большую гибкость при программировании, но выполняются они значительно медленнее
В CORBA предусмотрен ряд унифицированных сервисов, работающих под управлением ORB. В частности, это сервисы: