Реализация связи компонентов в среде CORBA

В системе CORBA механизм связи разнородных объектов напоминает проектные решения в системе АПРОП с помощью модуля-посредника (stub, skeleton). Модуль-посредник stub выполняет аналогичные функции, связанные с преобразованием типов данных клиентских компонентов в ТД серверных компонентов посредством [46]:

• 1) отображения запросов клиента в ЯМ в операции языка IDL (Interface Definition Language), RMI (Remote Invocation Interface) или API (Application Program Interface);
• 2) преобразования операций IDL в конструкции ЯП и передачи их серверу средствами брокера ORB, реализующего stub в ТД клиента.

Так как ЯП (C++, JAVA, Smalltalk, Visual C++, COBOL, ADA-95) реализованы на разных платформах и в разных средах и двоичное представление объектов зависит от конкретной аппаратной платформы, в системе CORBA реализован общий механизм связи разнородных готовых объектов — брокер ORB.

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

В случае вхождения в состав модели CORBA объектной модели JAVA/RMI, вызов удаленного метода объекта осуществляется ссылками на объекты, задаваемые указателями на адреса памяти. Интерфейс как объектный тип реализуется классами и предоставляет удаленный доступ к нему сервера. Компилятор JAVA создает байт-код, который интерпретируется виртуальной машиной, обеспечивающей переносимость байт-кодов и однородность представления данных на всех платформах среды CORBA.

В среде клиент-сервера CORBA реализуется два способа связи:

• 1) на уровне ЯП через интерфейсы прикладного программирования;
• 2) на уровне компиляторов IDL, генерирующих клиентские и серверные интерфейсные посредники — stub, skeleton.

Интерфейсы определяются в IDL или APL для объекта-клиента и объектасервера, имеют отдельную реализацию и доступны разноязычных программам. Интерфейсы включают в себя описание формальных и фактических параметров программ, их типов и порядок задания операций передачи параметров и результатов при их взаимодействии. Другими словами, такое описание есть не что иное, как спецификация интерфейсного посредника двух разноязычных программ, которые взаимодействуют друг с другом через механизм вызова, который реализован на разных процессах. В функции интерфейсного посредника (stub) клиента входит:

• 1) подготовка внешних параметров клиента для обращения к сервису сервера,
• 2) посылка параметров серверу и запуск получения результата или сведений об ошибках.

Общие функции интерфейсного посредника (skeleton) сервера:

• 1) получение сообщения от клиента, запуск удаленной процедуры, вычисление результата и подготовка (кодирование или перекодирование) данных в формате клиента;
• 2) возврат результата клиенту через параметры сообщения и уничтожение удаленной процедуры и др.

Таким образом, интерфейсные посредники задают связь между клиентом и сервером (stub для клиента и skeleton для сервера).