Введение

Стандарт, облегчающий взаимодействие между системами на разнородных платформах

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

Обзор

CORBA обеспечивает связь между программным обеспечением, написанным на разных языках и работающим на разных компьютерах. Детали реализации конкретных операционных систем, языков программирования и аппаратных платформ полностью исключены из зоны ответственности разработчиков, использующих CORBA. CORBA нормализует семантику вызова методов между объектами приложений, расположенными либо в одном адресном пространстве (внутри приложения), либо в удаленных адресных пространствах (на том же хосте или на удаленном хосте в сети). Версия 1.0 была выпущена в октябре 1991 года. CORBA использует язык определения интерфейсов (IDL) для спецификации интерфейсов, которые объекты предоставляют внешнему миру. Затем CORBA определяет соответствие между IDL и конкретным языком реализации, таким как C++ или Java. Существуют стандартные соответствия для Ada, C, C++, C++11, COBOL, Java, Lisp, PL/I, Object Pascal, Python, Ruby и Smalltalk. Нестандартные соответствия существуют для C#, Erlang, Perl, Tcl и Visual Basic, реализованные брокерами запросов объектов (ORB), написанными для этих языков. Версии IDL значительно изменились, при этом аннотации заменили некоторые прагмы. Спецификация CORBA предписывает наличие ORB, через который приложение взаимодействует с другими объектами. Реализация этого выглядит следующим образом:

Приложение инициализирует ORB и получает доступ к внутреннему адаптеру объектов, который поддерживает такие функции, как подсчет ссылок, политики инстанцирования объектов (и ссылок) и политики жизненного цикла объектов. Адаптер объектов используется для регистрации экземпляров сгенерированных классов кода. Сгенерированные классы кода являются результатом компиляции пользовательского кода IDL, который преобразует определение интерфейса высокого уровня в базовый класс, специфичный для ОС и языка, для использования в пользовательском приложении. Этот шаг необходим для обеспечения семантики CORBA и предоставления чистого интерфейса для взаимодействия с инфраструктурой CORBA. Некоторые соответствия IDL сложнее в использовании, чем другие. Например, благодаря особенностям Java, соответствие IDL для Java достаточно простое и делает использование CORBA очень удобным в Java-приложении. То же самое относится и к соответствию IDL для Python. Соответствие C++ требует от программиста изучения типов данных, предшествующих C++ Standard Template Library (STL). В отличие от этого, соответствие C++11 проще в использовании, но требует активного использования STL. Поскольку язык C не является объектно-ориентированным, соответствие IDL для C требует от программиста C ручной эмуляции объектно-ориентированных возможностей. Для создания системы, использующей или реализующей распределенный объектный интерфейс на основе CORBA, разработчик должен получить или написать код IDL, определяющий объектно-ориентированный интерфейс для логики, которую система будет использовать или реализовывать. Обычно реализация ORB включает инструмент, называемый компилятором IDL, который преобразует интерфейс IDL в целевой язык для использования в этой части системы. Затем традиционный компилятор компилирует сгенерированный код для создания компонуемых объектных файлов для использования в приложении. Эта диаграмма иллюстрирует, как сгенерированный код используется в инфраструктуре CORBA.

На этой фигуре показана высокоуровневая парадигма удаленной межпроцессной коммуникации с использованием CORBA. Спецификация CORBA также охватывает типизацию данных, исключения, сетевые протоколы, тайм-ауты связи и т.д. Например: Обычно на стороне сервера находится портативный адаптер объектов (POA), который перенаправляет вызовы либо на локальные сервисы, либо (для балансировки нагрузки) на другие серверы. Спецификация CORBA (и, следовательно, эта фигура) оставляет различные аспекты распределенной системы на усмотрение приложения, включая жизненный цикл объектов (хотя семантика подсчета ссылок доступна для приложений), резервирование/отказоустойчивость, управление памятью, динамическую балансировку нагрузки и модели, ориентированные на приложение, такие как разделение семантики представления/данных/управления (например, см. Model-View-Controller). В дополнение к предоставлению пользователям языка и платформонезависимой спецификации удаленного вызова процедур (RPC), CORBA определяет обычно необходимые сервисы, такие как транзакции и безопасность, события, время и другие модели интерфейсов, специфичные для предметной области.

История версий

В данной таблице представлена история стандартных версий CORBA. Версия Дата Основные моменты Corba IDL Версия 1.0 Октябрь 1991 Первая версия, C-отображение 1.1 Февраль 1992 Взаимодействие, C++-отображение 1.2 Декабрь 1993 2.0 Август 1996 Первое крупное обновление стандарта, также известное как CORBA 2 2.1 Август 1997 2.2 Февраль 1998 Java-отображение 2.3 Июнь 1999 2.4 Август 2000 2.5 Сентябрь 2001 2.6 Декабрь 2001 3.0 Июль 2002 Второе крупное обновление стандарта, также известное как CORBA 3 CORBA Component Model (CCM) 3.0 3.0.1 Ноябрь 2002 3.0.2 Декабрь 2002 3.0.3 Март 2004 3.1 Январь 2008 3.1.1 Август 2011 Принято в качестве редакции ISO/IEC 19500 за 2012 год 3.2 Ноябрь 2011 3.3 Ноябрь 2012 Добавление ZIOP 3.4 Февраль 2021 4.2 Примечание: изменения в IDL развивались с использованием аннотаций (например, @unit, @topic), заменяющих некоторые прагмы.

Слуги

Служащий – это целевой объект вызова, содержащий методы для обработки удаленных вызовов методов. В более новых версиях CORBA удаленный объект (на стороне сервера) разделяется на объект (который доступен для удаленных вызовов) и служащего (которому первая часть пересылает вызовы методов). Может быть один служащий на удаленный объект, или один и тот же служащий может обслуживать несколько (возможно, все) объектов, связанных с данным портативным адаптером объектов. Служащий для каждого объекта может быть установлен или найден "один раз и навсегда" (активация служащего) или динамически выбираться каждый раз, когда вызывается метод этого объекта (определение местоположения служащего). И определитель местоположения служащего, и активатор служащего могут перенаправлять вызовы на другой сервер. В целом, эта система предоставляет мощные средства для балансировки нагрузки, распределяя запросы между несколькими машинами. В объектно-ориентированных языках как удаленный объект, так и его служащий являются объектами с точки зрения объектно-ориентированного программирования. Инкарнация – это процесс связывания служащего с объектом CORBA для обслуживания запросов. Инкарнация предоставляет конкретную форму служащего для виртуального объекта CORBA. Активация и деактивация относятся только к объектам CORBA, в то время как термины инкарнация и эфириализация относятся к служащим. Однако, жизненные циклы объектов и служащих независимы. Всегда следует инкарнировать служащего перед активацией объекта, но обратное также возможно: создание ссылки активирует объект без инкарнации служащего, а инкарнация служащего выполняется позже по требованию с помощью менеджера служащих. Портативный адаптер объектов (POA) – это объект CORBA, отвечающий за разделение серверной части обработчика удаленных вызовов на удаленный объект и его служащего. Объект доступен для удаленных вызовов, а служащий содержит методы, которые фактически обрабатывают запросы. Служащий для каждого объекта может быть выбран либо статически (один раз), либо динамически (для каждого удаленного вызова), в обоих случаях позволяя перенаправлять вызов на другой сервер. На стороне сервера POA образуют древовидную структуру, где каждый POA отвечает за один или несколько обслуживаемых объектов. Ветви этого дерева могут быть независимо активированы/деактивированы, иметь различный код для определения местоположения или активации служащего и различные политики обработки запросов.

Особенности

Ниже описаны некоторые из наиболее важных способов использования CORBA для обеспечения взаимодействия между распределенными объектами.

Объекты по ссылке

Эта ссылка может быть получена из строкового представления универсального указателя ресурсов (URL), посредством поиска в NameService (аналогичном системе доменных имен (DNS)), или передана в качестве параметра метода при вызове. Ссылки на объекты – это легковесные объекты, соответствующие интерфейсу реального объекта (удаленного или локального). Вызов методов у ссылки приводит к последующим вызовам в ORB и блокировке потока до получения ответа об успехе или неудаче. Параметры, возвращаемые данные (при наличии) и данные об исключениях сериализуются внутри ORB в соответствии с локальной языковой средой и отображением операционной системы.

Данные по стоимости

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

Объекты по стоимости (OBV)

Помимо удаленных объектов, CORBA и RMI IIOP определяют концепции OBV и ValueTypes. Код внутри методов объектов ValueType выполняется локально по умолчанию. Если OBV был получен с удаленной стороны, необходимый код должен быть заранее известен обеим сторонам или динамически загружен от отправителя. Для этого запись, определяющая OBV, содержит CodeBase – список URL-адресов, разделенных пробелами, откуда этот код должен быть загружен. OBV также может содержать удаленные методы.

Модель компонентов CORBA (CCM)

Компонентная модель CORBA (CCM) является дополнением к семейству спецификаций CORBA. Она была представлена вместе с CORBA 3 и описывает стандартную прикладную структуру для компонентов CORBA. Хотя она не зависит от "языкозависимых Enterprise Java Beans (EJB)", CCM представляет собой более общую форму EJB, предоставляя четыре типа компонентов вместо двух, определенных в EJB. Она обеспечивает абстракцию сущностей, способных предоставлять и потреблять сервисы через четко определенные именованные интерфейсы, называемые портами. CCM включает в себя компонентный контейнер, в котором развертываются программные компоненты. Контейнер предоставляет набор сервисов, доступных для компонентов. Эти сервисы включают (но не ограничиваются ими) уведомления, аутентификацию, постоянное хранение данных и обработку транзакций. Это наиболее востребованные сервисы в любой распределенной системе, и, перенося реализацию этих сервисов из программных компонентов в компонентный контейнер, удается значительно снизить сложность компонентов.

Портативные перехватчики

Портативные перехватчики — это "крючки", используемые CORBA и RMI IIOP для управления наиболее важными функциями системы CORBA. Стандарт CORBA определяет следующие типы перехватчиков:

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

Общий протокол InterORB (GIOP)

GIOP — это абстрактный протокол, посредством которого взаимодействуют брокеры объектов (ORB). Стандарты, связанные с этим протоколом, поддерживаются Объектным управлением группой (OMG). Архитектура GIOP предоставляет несколько конкретных протоколов, включая:

Интернет-протокол InterORB (IIOP) — Интернет-протокол InterORB является реализацией GIOP для использования в Интернете и обеспечивает сопоставление сообщений GIOP с уровнем TCP/IP. SSL InterORB Protocol (SSLIOP) — SSLIOP представляет собой IIOP поверх SSL, обеспечивающий шифрование и аутентификацию. HyperText InterORB Protocol (HTIOP) — HTIOP представляет собой IIOP поверх HTTP, обеспечивающий прозрачное обхождение прокси-серверов. Zipped IOP (ZIOP) — сжатая версия GIOP, которая снижает использование полосы пропускания.

VMCID (Vendor Minor Codeset ID) (Идентификатор малого кода поставщика)

Каждое стандартное исключение CORBA включает в себя дополнительный код для обозначения подкатегории исключения. Дополнительные коды исключений имеют тип unsigned long и состоят из 20-битного "Vendor Minor Codeset ID" (VMCID), который занимает 20 старших битов, и собственно дополнительного кода, который занимает 12 младших битов. Дополнительные коды для стандартных исключений предваряются VMCID, присвоенным OMG, определенным как константа unsigned long CORBA::OMGVMCID, в которой VMCID, выделенный OMG, занимает 20 старших битов. Дополнительные коды исключений, связанные со стандартными исключениями, представленные в таблице 3–13 на странице 3 58, комбинируются по битовой операции ИЛИ с OMGVMCID для получения значения дополнительного кода, которое возвращается в структуре ex body (см. раздел 3.17.1, "Определения стандартных исключений", на странице 3 52 и раздел 3.17.2, "Стандартные дополнительные коды исключений", на странице 3 58). В пределах пространства, выделенного поставщиком, присвоение значений дополнительным кодам остается за поставщиком. Поставщики могут запросить выделение VMCID, отправив электронное письмо на tagrequest@omg.org. Список в настоящее время присвоенных VMCID можно найти на веб-сайте OMG по адресу: http://www.omg.org/cgi-bin/doc?vendor_tags.

VMCID 0 и 0xfffff зарезервированы для экспериментального использования. VMCID OMGVMCID (раздел 3.17.1, "Определения стандартных исключений", на странице 3 52) и от 1 до 0xf зарезервированы для использования OMG. Брокер общих объектных запросов: архитектура и спецификация (CORBA 2.3).

Преимущества

Преимущества CORBA включают независимость от языка и ОС, свободу от привязки к конкретным технологическим реализациям, строгую типизацию данных, высокий уровень настраиваемости и независимость от деталей распределенной передачи данных. Языковая независимость CORBA была разработана, чтобы освободить разработчиков от ограничений, связанных с привязкой их проектов к определенному языку программирования. В настоящее время существует множество языков, поддерживаемых различными поставщиками CORBA, наиболее популярными из которых являются Java и C++. Также поддерживаются C++11, C, Smalltalk, Perl, Ada, Ruby и Python, и это лишь некоторые из них. Независимость от ОС Дизайн CORBA предполагает независимость от операционной системы. CORBA доступна на Java (независимая от ОС), а также нативно для Linux/Unix, Windows, Solaris, OS X, OpenVMS, HPUX, Android, LynxOS, VxWorks, ThreadX, INTEGRITY и других. Свобода от технологий Одним из основных неявных преимуществ CORBA является предоставление нейтральной платформы для разработчиков, позволяющей нормализовать интерфейсы между различными новыми и устаревшими системами. При интеграции C, C++, Object Pascal, Java, Fortran, Python и любых других языков или ОС в единую согласованную модель проектирования системы, CORBA предоставляет средства для выравнивания и позволяет различным командам разрабатывать системы и модульные тесты, которые впоследствии могут быть объединены в единую систему. Это не отменяет необходимости принятия базовых решений в области системной инженерии, таких как многопоточность, временные характеристики, время жизни объектов и т.д. Эти вопросы являются частью любой системы, независимо от используемой технологии. CORBA позволяет нормализовать элементы системы в единую согласованную модель. Например, проектирование многоуровневой архитектуры упрощается при использовании Java Servlets на веб-сервере и различных серверов CORBA, содержащих бизнес-логику и обеспечивающих доступ к базе данных. Это позволяет изменять реализацию бизнес-логики, в то время как изменения интерфейса должны обрабатываться как в любой другой технологии. Например, схема базы данных, инкапсулированная сервером, может быть изменена для повышения эффективности использования дискового пространства или производительности (или даже полной смены поставщика базы данных), не затрагивая внешние интерфейсы. В то же время, устаревший код на C++ может взаимодействовать с устаревшим кодом на C/Fortran и кодом базы данных Java, а также предоставлять данные для веб-интерфейса. Типизация данных CORBA обеспечивает гибкую типизацию данных, например, тип данных "ANY". CORBA также обеспечивает строгую типизацию данных, снижая вероятность ошибок, связанных с человеческим фактором. В ситуации, когда передаются пары "Имя-Значение", возможно, что сервер предоставит число там, где ожидалась строка. Язык определения интерфейсов CORBA (CORBA Interface Definition Language) предоставляет механизм для обеспечения соответствия пользовательского кода именам методов, типам возвращаемых значений и параметров, а также исключениям. Высокая настраиваемость Многие реализации (например, ORBexpress (реализация на Ada, C++ и Java) и OmniORB (реализация на C++ и Python с открытым исходным кодом)) предоставляют возможности настройки функций управления потоками и соединениями. Не все реализации ORB предоставляют одинаковый набор функций. Независимость от деталей передачи данных При работе с соединениями и потоками низкого уровня CORBA предоставляет высокий уровень детализации в отношении условий возникновения ошибок. Это определено в стандартном наборе исключений, определенных в CORBA, и в расширенном наборе исключений, специфичном для реализации. С помощью исключений приложение может определить, не удался ли вызов по причинам, таким как "Небольшая проблема, повторите попытку", "Сервер не работает" или "Ссылка недействительна". Общее правило: отсутствие исключения означает, что вызов метода выполнен успешно. Это очень мощная особенность проектирования. Сжатие CORBA сериализует данные в двоичном формате и поддерживает сжатие. Компании IONA, Remedy IT и Telefónica работали над расширением стандарта CORBA, обеспечивающим сжатие. Это расширение называется ZIOP и теперь является официальным стандартом OMG.