Общая архитектура брокера объектных запросов - Common Object Request Broker Architecture

Эта статья включает в себя список общих Рекомендации, но он остается в основном непроверенным, потому что ему не хватает соответствующих встроенные цитаты. Пожалуйста, помогите улучшать эта статья введение более точные цитаты. (Февраль 2009 г.) (Узнайте, как и когда удалить этот шаблон сообщения)

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

Обзор

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

CORBA использует язык определения интерфейса (IDL) для определения интерфейсов, которые объекты представляют внешнему миру. CORBA затем указывает отображение от IDL к конкретному языку реализации, например C ++ или же Ява. Стандартные сопоставления существуют для Ада, C, C ++, C ++ 11, КОБОЛ, Ява, Лисп, PL / I, Object Pascal, Python, Рубин и Болтовня. Нестандартные отображения существуют для C #, Erlang, Perl, Tcl и Visual Basic реализовано брокеры запросов на объекты (ORB) написаны для этих языков.

Спецификация CORBA требует наличия ORB, через который приложение будет взаимодействовать с другими объектами. Вот как это реализуется на практике:

1. Приложение просто инициализирует ORB и обращается к внутреннему Адаптер объекта, который поддерживает такие вещи, как подсчет ссылок, политики создания экземпляров объектов (и ссылок) и политики времени жизни объектов.
2. Адаптер объекта используется для регистрации экземпляров сгенерированные классы кода. Сгенерированные классы кода являются результатом компиляции кода IDL пользователя, который переводит определение интерфейса высокого уровня в базу классов, зависящую от ОС и языка, для использования в пользовательском приложении. Этот шаг необходим для обеспечения семантики CORBA и обеспечения чистого пользовательского процесса для взаимодействия с инфраструктурой CORBA.

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

Чтобы построить систему, которая использует или реализует интерфейс распределенных объектов на основе CORBA, разработчик должен либо получить, либо написать код IDL, который определяет объектно-ориентированный интерфейс для логики, которую система будет использовать или реализовывать. Обычно реализация ORB включает инструмент, называемый компилятором IDL, который переводит интерфейс IDL на целевой язык для использования в этой части системы. Затем традиционный компилятор компилирует сгенерированный код для создания файлов связываемых объектов для использования в приложении. Эта диаграмма показывает, как сгенерированный код используется в инфраструктуре CORBA:

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

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

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

В этой таблице представлена ​​история стандартных версий CORBA.^[1][2]

Слуги

А слуга цель вызова, содержащая методы для обработки вызовы удаленных методов. В более новых версиях CORBA удаленный объект (на стороне сервера) разделен на объект (который доступен для удаленных вызовов) и слуга (которому бывшая часть вперед вызов метода). Это может быть один слуга на пульт объект, или один и тот же сервант может поддерживать несколько (возможно все) объектов, связанных с данным Портативный объектный адаптер. В слуга для каждого объект может быть установлен или найден «раз и навсегда» (активация серванта) или динамически выбран каждый раз, когда вызывается метод этого объекта (местоположение серванта). И локатор слуг, и активатор слуг могут перенаправлять вызовы на другой сервер. В целом, эта система предоставляет очень мощные средства для балансировки нагрузки, распределяя запросы между несколькими машинами. В объектно-ориентированных языках оба удаленных объект и это слуга являются объектами с точки зрения объектно-ориентированного программирования.

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

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

На стороне сервера POA образуют древовидную структуру, где каждый POA отвечает за один или несколько обслуживаемых объектов. Ветви этого дерева могут быть независимо активированы / деактивированы, иметь другой код для местоположения или активации слуги и разные политики обработки запросов.

Функции

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

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

Эта ссылка либо получена через строковый Единый указатель ресурсов (URL), поиск NameService (аналогично система доменных имен (DNS)) или передается как параметр метода во время вызова.

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

Данные по значению

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

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

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

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

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

CCM имеет компонентный контейнер, в котором могут быть развернуты программные компоненты. Контейнер предлагает набор сервисов, которые могут использовать компоненты. Эти услуги включают (но не ограничиваются) уведомление, аутентификация, упорство и обработка транзакции. Это наиболее часто используемые службы, которые требуются любой распределенной системе, и за счет переноса реализации этих служб из программных компонентов в контейнер компонентов сложность компонентов значительно снижается.

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

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

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

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

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

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

1. Протокол Internet InterORB (IIOP). Протокол Internet Inter-Orb представляет собой реализацию GIOP для использования в Интернет, и обеспечивает соответствие между сообщениями GIOP и TCP / IP слой.
2. Протокол SSL InterORB (SSLIOP) - SSLIOP превышает IIOP SSL, предоставляя шифрование и аутентификация.
3. Протокол HyperText InterORB (HTIOP) - HTIOP - это протокол IIOP HTTP, обеспечивающий прозрачный обход прокси.
4. Заархивированный IOP (ZIOP) - сжатая версия GIOP, которая снижает использование полосы пропускания.

VMCID (идентификатор второстепенного набора кодов поставщика)

Каждое стандартное исключение CORBA включает второстепенный код для обозначения подкатегории исключения. Коды второстепенных исключений имеют тип unsigned long и состоят из 20-битного «идентификатора вспомогательного кодового набора поставщика» (VMCID), который занимает 20 битов высокого порядка, и собственно вспомогательного кода, занимающего 12 бит младшего разряда.

Второстепенным кодам для стандартных исключений предшествует VMCID, присвоенный OMG, определенный как длинная константа без знака CORBA :: OMGVMCID, у которой VMCID, назначенный OMG, занимает старшие 20 битов. Коды второстепенных исключений, связанные со стандартными исключениями, которые находятся в Таблице 3–13 на стр. 3-58, упорядочиваются с помощью OMGVMCID для получения значения второстепенного кода, возвращаемого в структуре ex_body (см. Раздел 3.17.1, «Стандартные»). Определения исключений »на странице 3-52 и Раздел 3.17.2,« Стандартные второстепенные коды исключений »на странице 3-58).

В пространстве, назначенном поставщиком, присвоение значений второстепенным кодам предоставляется поставщику. Продавцы могут запросить выделение идентификаторов VMCID, отправив электронное письмо на адрес [email protected]. Список присвоенных в настоящее время 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)

Расположение Корба (CorbaLoc)

Местоположение Corba (CorbaLoc) относится к строковой объектной ссылке для объекта CORBA, который похож на URL-адрес.

Все продукты CORBA должны поддерживать два URL-адреса, определенные OMG: "корбалок:" и "corbaname:". Их цель - предоставить удобочитаемый и доступный для редактирования способ указать место, где можно получить IOR.

Пример корбалока показан ниже:

corbaloc :: 160.45.110.41: 38693 / StandardNS / NameServer-POA / _root

Продукт CORBA может дополнительно поддерживать "http:", "ftp:" и "файл:Их семантика заключается в том, что они предоставляют подробную информацию о том, как загрузить строковый IOR (или, рекурсивно, загрузить другой URL, который в конечном итоге предоставит строковый IOR). Некоторые ORB действительно предоставляют дополнительные форматы, которые являются собственностью этого ORB.

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

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

Независимость от языка

CORBA была разработана, чтобы освободить инженеров от ограничений, связанных с привязкой их проектов к определенному программному языку. В настоящее время существует множество языков, поддерживаемых различными поставщиками CORBA, самыми популярными из которых являются Java и C ++. Существуют также реализации C ++ 11, C-only, 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 на веб-сервере и на различных серверах CORBA, содержащих бизнес-логику и обертывающих доступ к базе данных. Это позволяет изменять реализации бизнес-логики, в то время как изменения интерфейса необходимо обрабатывать, как и в любой другой технологии. Например, для базы данных, обернутой сервером, может быть изменена схема базы данных для улучшения использования диска или производительности (или даже для полномасштабного изменения поставщика базы данных), не влияя на внешние интерфейсы. В то же время унаследованный код C ++ может взаимодействовать с унаследованным кодом C / Fortran и кодом базы данных Java, а также может предоставлять данные в веб-интерфейс.

Типизация данных

CORBA обеспечивает гибкую типизацию данных, например типа данных «ЛЮБОЙ». CORBA также обеспечивает тесную связь типов данных, уменьшая количество человеческих ошибок. В ситуации, когда передаются пары «имя-значение», вполне возможно, что сервер предоставляет число там, где ожидалась строка. CORBA Interface Definition Language предоставляет механизм, обеспечивающий соответствие пользовательского кода именам методов, возвращаемым значениям, типам параметров и исключениям.

Высокая настраиваемость

Многие реализации (например, ORBexpress (реализация на Ada, C ++ и Java)^[4] и OmniORB (реализация на C ++ и Python с открытым исходным кодом))^[5] есть параметры для настройки функций управления потоками и подключениями. Не все реализации ORB предоставляют одинаковые функции.

Свобода от деталей передачи данных

При обработке низкоуровневых соединений и потоков CORBA обеспечивает высокий уровень детализации в условиях ошибки. Это определено в стандартном наборе исключений, определенном CORBA, и в расширенном наборе исключений для конкретной реализации. С помощью исключений приложение может определить, не удалось ли выполнить вызов по таким причинам, как «Небольшая проблема, попробуйте еще раз», «Сервер не работает» или «Ссылка не имеет смысла». Общее правило: отсутствие исключения означает, что вызов метода завершился успешно. Это очень мощная особенность дизайна.

Сжатие

CORBA упорядочивает свои данные в двоичной форме и поддерживает сжатие. IONA, Remedy IT и Telefónica работали над расширением стандарта CORBA, обеспечивающим сжатие. Это расширение называется ZIOP, и теперь это формальный стандарт OMG.

Проблемы и критика

Несмотря на то, что CORBA во многом соответствовала способам написания кода и создания программного обеспечения, она была предметом критики.^[6]

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

Несовместимость начальной реализации

Первоначальные спецификации CORBA определяли только IDL, а не формат передачи данных. Это означало, что совместимость исходного кода была лучшей за несколько лет. В CORBA 2 и более поздних версиях эта проблема была решена.

Прозрачность местоположения

Понятие прозрачности местоположения CORBA подверглось критике; то есть объекты, находящиеся в одном адресное пространство и доступны с помощью простого вызов функции обрабатываются так же, как объекты, находящиеся в другом месте (разные процессы на одной машине или разных машинах). Это фундаментальный недостаток дизайна,^{[7][неудачная проверка ]} поскольку это делает доступ ко всем объектам таким же сложным, как и самый сложный случай (например, удаленный сетевой вызов с широким классом сбоев, которые невозможны при локальных вызовах). Он также скрывает неизбежные различия между двумя классами, делая невозможным для приложений выбор подходящей стратегии использования (то есть вызов с 1мкс Задержка и гарантированный возврат будут использоваться совершенно иначе, чем вызов с задержкой в ​​1 с с возможным отказом транспорта, в котором статус доставки потенциально неизвестен и может потребоваться 30 секунд для ожидания).

Недостатки дизайна и процесса

Создание стандарта CORBA также часто упоминается как процесс дизайн комитетом. Не существовало процесса арбитража между конфликтующими предложениями или определения иерархии проблем, которые необходимо решать. Таким образом, стандарт был создан путем объединения характеристик всех предложений без учета их согласованности.^[8] Это сделало спецификацию сложной, дорогостоящей в реализации и часто неоднозначной.

Комитет по дизайну, состоящий из поставщиков и заказчиков внедрения, создал широкий круг интересов. Это разнообразие затрудняло создание единого стандарта. Стандарты и функциональная совместимость увеличили конкуренцию и облегчили переход клиентов между альтернативными реализациями. Это привело к большой политической борьбе внутри комитета и частым выпускам исправлений стандарта CORBA, которые, как уверяли некоторые разработчики ORB, было сложно использовать без проприетарных расширений.^[6] Менее этичные поставщики CORBA поощряли привязку к потребителю и добились хороших краткосрочных результатов. Со временем поставщики ORB, которые поощряют переносимость, захватили долю рынка.^{[нужна цитата ]}

Проблемы с реализациями

На протяжении всей своей истории CORBA страдала от недостатков в плохих реализациях ORB. К сожалению, многие статьи, критикующие CORBA как стандарт, представляют собой просто критику особенно плохой реализации CORBA ORB.

CORBA - это всеобъемлющий стандарт с множеством функций. Некоторые реализации пытаются реализовать все спецификации,^[8] и первоначальные реализации были неполными или неадекватными. Поскольку не было требований предоставить эталонную реализацию, участники могли предлагать функции, которые никогда не тестировались на полезность или реализуемость. Реализациям также мешала общая тенденция стандарта быть многословной и обычная практика компрометации путем принятия суммы всех представленных предложений, которые часто создавали API, которые были непоследовательными и сложными в использовании, даже если отдельные предложения были совершенно разумными. .^{[нужна цитата ]}

В прошлом было очень трудно получить надежные реализации CORBA, но теперь их гораздо легче найти. SUN Java SDK поставляется со встроенной CORBA. Некоторые плохо спроектированные реализации оказались сложными, медленными, несовместимыми и неполными. Начали появляться надежные коммерческие версии, но за значительную плату. Когда стали доступны бесплатные реализации хорошего качества, плохие коммерческие реализации быстро умерли.

Межсетевые экраны

CORBA (точнее, GIOP ) не привязан к какому-либо конкретному транспорту связи. Специализацией GIOP является протокол Internet Inter-ORB Protocol или IIOP. IIOP использует сырые TCP / IP соединения для передачи данных.

Если клиент находится за очень ограничивающим брандмауэром или прозрачный прокси серверная среда, которая позволяет HTTP соединения с внешним миром через порт 80, связь может быть невозможной, если рассматриваемый прокси-сервер не позволяет HTTP ПОДКЛЮЧЕНИЕ метод или НОСКИ соединения тоже. Когда-то было сложно даже заставить реализации использовать один стандартный порт - вместо этого они обычно выбирали несколько случайных портов. На сегодняшний день существующие ORB действительно имеют эти недостатки. Из-за таких трудностей некоторые пользователи все шире используют веб-сервисы вместо CORBA. Они общаются, используя XML /МЫЛО через порт 80, который обычно остается открытым или фильтруется через прокси-сервер HTTP внутри организации, для просмотра веб-страниц через HTTP. Однако последние реализации CORBA поддерживают SSL и его можно легко настроить для работы с одним портом. Некоторые ORBS, такие как ТАО, omniORB и JacORB также поддерживает двунаправленный GIOP, что дает CORBA преимущество возможности использовать обратный вызов, а не метод опроса, характерный для реализаций веб-сервисов. Кроме того, большинство современных межсетевых экранов поддерживают GIOP и IIOP и, таким образом, являются дружественными к CORBA межсетевыми экранами.

Смотрите также

Программная инженерия

• Компонентная разработка программного обеспечения
• Распределенных вычислений
• Переносной объект
• Сервис-Ориентированная Архитектура (SOA)

Компонентные программные технологии

• Freedesktop.org D-автобус - текущая открытая межъязыковая кроссплатформенная объектная модель
• ГНОМ Бонобо - устаревшая межъязыковая объектная модель GNOME
• KDE DCOP - устаревшая система межпроцессного взаимодействия и взаимодействия компонентов программного обеспечения KDE
• KDE KParts - Структура компонентов KDE
• Компонентная объектная модель (COM) - межъязыковая объектная модель только для Microsoft Windows
• DCOM (Распределенный COM) - расширение, позволяющее COM работать в сетях
• Инфраструктура общего языка - Текущий .СЕТЬ межъязыковая кроссплатформенная объектная модель
• XPCOM (Кросс-платформенная компонентная объектная модель) - разработана Mozilla для приложений на ее основе (например, Пакет приложений Mozilla, SeaMonkey 1.x)
• Системная объектная модель IBM SOM и DSOM - компонентные системы от IBM, используемые в OS / 2 и AIX
• Internet Communications Engine (ЛЕД)
• Вызов удаленного метода Java (Java RMI)
• Платформа Java, Enterprise Edition (Java EE)
• JavaBean
• Под открытым небом
• Удаленный вызов процедур (RPC)
• Фонд связи Windows (WCF)
• Программная коммуникационная архитектура (SCA) - компоненты для встроенных систем, кросс-языковой, кросс-транспортный, кроссплатформенный

Языковые привязки

• Привязка к языку
• Интерфейс внешней функции
• Соглашение о вызове
• Интерфейс динамического вызова
• Изменение имени
• Интерфейс прикладного программирования - API
• Бинарный интерфейс приложения - ABI
• Сравнение виртуальных машин приложений
• SWIG генератор автоматических привязок интерфейсов с открытым исходным кодом со многих языков на многие языки

Рекомендации

дальнейшее чтение

• «КОРБА». Текущий. Технические характеристики. мой Бог.
• Орфали, Роберт. Основное руководство по выживанию клиент / сервер. Джон Вили и сыновья. ISBN  0-471-15325-7.
• Орфали, Роберт; Харки, Дэн; Эдвардс, Джери. Руководство по выживанию для основных распределенных объектов. Джон Вили и сыновья. ISBN  0-471-12993-3.
• Орфали, Роберт; Харки, Дэн. Клиент-серверное программирование с помощью JAVA и CORBA. Джон Вили и сыновья. ISBN  0-471-24578-X.
• Слама, Дирк; Гарбис, Джейсон; Рассел, Перри. Корпоративная CORBA. Прентис Холл. ISBN  0-13-083963-9.
• Хеннинг, штат Мичи; Виноски, Стив. Расширенное программирование CORBA на C ++. Эддисон-Уэсли. ISBN  0-201-37927-9.
• Кортаус, Аксель; Шадер, Мартин; Алексий, Маркус. Реализация распределенных систем с помощью Java и CORBA. Springer. ISBN  3-540-24173-6. Архивировано из оригинал 31 октября 2005 г.. Получено 23 июн 2005.
• Болтон, Финтан. Чистая Корба. Самс Паблишинг. ISBN  0-672-31812-1.
• Сигел, Джон. CORBA 3 - Основы и программирование. Джон Вили и сыновья. ISBN  0-471-29518-3.
• Захави, Рон. Интеграция корпоративных приложений с CORBA: компонентные и веб-решения. Джон Вили и сыновья. ISBN  0-471-32720-4.
• Хартман, Брет; Безносов, Хартман; Виноски, Стив; Флинн, Дональд. Безопасность предприятия с EJB и CORBA. Джон Вили и сыновья. ISBN  0-471-40131-5.
• Моубрей, Томас Дж .; Захави, Рон. The Essential Corba: системная интеграция с использованием распределенных объектов. Джон Вили и сыновья. ISBN  0-471-10611-9.
• Розен, Майкл; Кертис, Дэвид. Интеграция приложений CORBA и COM. Джон Вили и сыновья. ISBN  0-471-19827-7.
• Брозе, Джеральд; Фогель, Андреас; Дадди, Кит. Программирование на Java с помощью CORBA. Джон Вили и сыновья. ISBN  0-471-37681-7.
• Скеттино, Джон; Хохман, Робин С .; О'Хара, Лиз. CORBA для чайников. Голодные умы. ISBN  0-7645-0308-1.
• Розенбергер, Джереми Л. Научитесь CORBA за 14 дней. Самс Паблишинг. ISBN  0-672-31208-5.
• Сигел, Джон. Быстрая CORBA 3. Джон Вили и сыновья. ISBN  0-471-38935-8.
• Моубрей, Томас Дж .; Мальво, Рафаэль С. Шаблоны проектирования CORBA. Джон Вили и сыновья. ISBN  0-471-15882-8.
• Орфали, Роберт; Харки, Дэн; Эдвардс, Джери. Мгновенный CORBA. Джон Вили и сыновья. ISBN  0-471-18333-4.
• Хармон, Пол; Моррисси, Уильям (1996). Справочник по объектным технологиям. Джон Вили и сыновья. ISBN  0-471-14717-6.

внешняя ссылка

• Официальная страница компонентов OMG CORBA
• Страница неофициальной модели компонентов CORBA
• Сравнение IDL с C ++ и IDL с C ++ 11
• Корба: ушел, но (надеюсь) не забыт
• OMG XMI Спецификация