История развития:

Термином CORBA обозначают технологию, архитектуру и набор спецификаций и стандартов промежуточного программного обеспечения (middleware) объектного типа для создания распределенных программных приложений, причем акцент делается на слове "распределенных".

Базовые принципы:

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

Прообразом взаимодействия между клиентским процессом и сервером объекта, то есть процессом, который порождает и обслуживает экземпляры объекта, является объектный вариант механизма вызова удаленной процедуры (RPC, remote procedure call). Механизм RPC реализует схему передачи сообщений, в соответствии с которой в распределенном клиент-серверном приложении процедура-клиент передает специальное сообщение с параметрами вызова по сети в удаленную серверную процедуру, а результаты ее выполнения возвращаются в другом сообщении клиентскому процессу.

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

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

В отличие от СОМ, архитектура CORBA с самого начала создавалась для распределенных объектных систем. Ее автором является не отдельно взятая фирма, а консорциум Object Management Group (сейчас в него входят более 800 компаний), поставивший своей целью разработать стандартную архитектуру для взаимодействия объектов в неоднородной сетевой среде.

Среди компаний, основавших OMG, были в основном производители компьютерных систем различного уровня и интеграторы с мировым именем, такие, например, как IBM, DEC, HP. Проблема развертывания приложений на смеси из самых разнородных платформ - от мэйнфреймов и Unix-компьютеров до персональных компьютеров - для них стояла очень остро. Консорциум OMG стремился объединить объектную технологию и принципы построения клиент-серверных распределенных систем, с тем чтобы предложить архитектуру, способную эффективно поддерживать взаимодействие приложений в сложной неоднородной корпоративной среде.

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

На самом верхнем уровне можно говорить, что CORBA состоит из 4 основных частей:

• Object Request Broker - брокер (посредник) объектных запросов;
• Object Services - объектные сервисы;
• Common Facilities - общие средства;
• Application и Domain Interfaces - прикладные и отраслевые интерфейсы.

Ядром архитектуры CORBA является брокер объектных запросов (Object Request Broker, ORB). Это объектная шина, по которой в стиле классического механизма RPC, происходит взаимодействие локальных и удаленных объектов. Помимо самого вызова метода удаленного объекта, ORB отвечает за поиск реализации объекта, его подготовку к получению и обработке запроса, передачу запроса и доставку результатов клиенту.

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

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

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

В CORBA есть также понятие домена; реализации объектов домена (CORBA domains) предназначены для приложений вертикальных рынков - здравоохранения, страхования, финансового рынка, производственных отраслей и т.д.

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

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

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

Для описания ORB и других компонент CORBA-стандарта используется язык определения интерфейсов (IDL - Interface Definition Language). Этот необычный язык не содержит присваиваний, операторов if или while, функций и логических переходов. IDL - это только описания, декларация, пассивные определения атрибутов, родительских классов, типов поддерживаемых событий, методов, включая входные и выходные данные, основные и составные типы данных, исключительные ситуации для обработки ошибок. Синтаксически IDL является подмножеством С++ с дополнительными ключевыми словами для поддержки концепции распределенности. Существуют компиляторы IDL в С++, Java, Ada, Smalltalk, COBOL, OLE (VisualBasic, PowerBuilder и Delphi).

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

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

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

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

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

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

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

Инкарнация - связывание серванта с CORBA-объектом для обработки клиентского запроса. Инкарнация материализует в серванте виртуальный CORBA-объект. В отличие от активизации инкарнация относится не к объекту, а к его серванту.

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

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

Все приведенные выше понятия касаются жизненного цикла объекта.

Возможности:

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

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

Перечислим обязанности объектного адаптера:

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

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

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