Общая архитектура посредника объектных запросов

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

Содержание

• 1 Обзор
• 2 История версий
• 3 Слуги
• 4 Функции
  • 4.1 Объекты по ссылке
  • 4.2 Данные по значению
  • 4.3 Объекты по значению (OBV)
  • 4.4 Модель компонентов CORBA (CCM)
  • 4.5 Портативные перехватчики
  • 4.6 Общий протокол InterORB (GIOP)
  • 4.7 VMCID (идентификатор вспомогательного кодового набора поставщика)
  • 4.8 Местоположение Corba (CorbaLoc)
• 5 Преимущества
• 6 Проблемы и критика
• 7 См. Также
• 8 Ссылки
• 9 Дополнительная литература
• 10 Внешние ссылки

Обзор

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), написанные для этих языков.

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

1. Приложение просто инициализирует ORB и обращается к внутреннему адаптеру объекта, который поддерживает такие вещи, как подсчет ссылок, политики создания экземпляров объектов (и ссылок) и политики времени жизни объектов.
2. Адаптер объектов используется для регистрации экземпляров сгенерированных классов кода. Сгенерированные классы кода являются результатом компиляции кода 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 дополнительно касается типизации данных, исключений, сетевых протоколов, тайм-аутов связи и т. Д. Например: обычно на стороне сервера есть Portable Object Adapter (POA), который перенаправляет вызовы либо локальным сервантам. или (для балансировки нагрузки) на другие серверы. Спецификация CORBA (и, следовательно, этот рисунок) оставляет на усмотрение приложения различные аспекты распределенной системы, включая время жизни объекта (хотя семантика подсчета ссылок доступна для приложений), избыточность / переключение при отказе, управление памятью, динамическую балансировку нагрузки и приложения: ориентированные модели, такие как разделение семантики отображения / данных / управления (например, см. Модель – представление – контроллер ) и т. д.

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

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

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

Servants

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

Инкарнация - это действие связывания серванта с объектом 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 и типов значений. Код внутри методов объектов Valuetype по умолчанию выполняется локально. Если OBV был получен с удаленной стороны, необходимый код должен быть либо априори известен обеим сторонам, либо динамически загружен от отправителя. Чтобы сделать это возможным, запись, определяющая OBV, содержит базу кода, которая представляет собой разделенный пробелами список URL-адресов, откуда этот код должен быть загружен. OBV также может иметь удаленные методы.

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

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

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

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

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

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

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

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

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

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

VMCID (ID вспомогательного кодового набора поставщика)

Каждое стандартное исключение 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#160;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)

Местоположение Corba (CorbaLoc)

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

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

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

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

Продукт CORBA может дополнительно поддерживать "http:", Форматы "ftp:" и "file:". Их семантика состоит в том, что они предоставляют подробные сведения о том, как загрузить строковый 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 предоставляет механизм, обеспечивающий соответствие пользовательского кода именам методов, возвращаемым значениям, типам параметров и исключениям.

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

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

Отсутствие подробностей передачи данных

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

Сжатие

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

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

Хотя CORBA во многом соответствовала тому, как был написан код и построено программное обеспечение, оно было предметом критики.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если клиент находится за очень строгим межсетевым экраном или прозрачным прокси, серверная среда, которая разрешает только HTTP подключения к внешнему миру через порт 80, связь может быть невозможной, если рассматриваемый прокси-сервер не разрешает также метод HTTP CONNECT или SOCKS подключения. Когда-то было сложно даже заставить реализации использовать один стандартный порт - вместо этого они обычно выбирали несколько случайных портов. На сегодняшний день существующие ORB действительно имеют эти недостатки. Из-за таких трудностей некоторые пользователи все чаще стали использовать веб-службы вместо CORBA. Они обмениваются данными с помощью XML / SOAP через порт 80, который обычно остается открытым или фильтруется через прокси-сервер HTTP внутри организации для просмотра веб-страниц через HTTP. Однако последние реализации CORBA поддерживают SSL и могут быть легко настроены для работы с одним портом. Некоторые ORBS, такие как TAO, omniORB, а также поддерживают двунаправленный GIOP, что дает CORBA преимущество, заключающееся в возможности использовать обратный вызов, а не метод опроса, характерный для реализаций веб-сервисов. Кроме того, большинство современных межсетевых экранов поддерживают GIOP и IIOP и, таким образом, являются межсетевыми экранами с поддержкой CORBA.

См. Также

Разработка программного обеспечения

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

Программные технологии на основе компонентов

• Freedesktop.org D-Bus - текущая открытая межъязыковая кроссплатформенная объектная модель
• GNOME Bonobo - устаревшая межъязыковая объектная модель GNOME
• KDE DCOP - устаревшая система межпроцессного взаимодействия и взаимодействия компонентов программного обеспечения KDE
• KDE KParts - Структура компонентов KDE
• Компонентная объектная модель (COM) - Межъязыковая объектная модель только для Microsoft Windows
• DCOM (Distributed COM) - расширение, позволяющее COM работать в сетях
• Common Language Infrastructure - Текущая .NET межъязыковая кроссплатформенная объектная модель
• XPCOM (Cross Platform Component Object Model) - разработана Mozilla для приложений на основе на нем (например, Mozilla Application Suite, SeaMonkey 1.x)
• Системная объектная модель IBM SOM и DSOM - компонентные системы от IBM, используемые в OS / 2 и AIX
• Internet Communications Engine (ICE)
• Вызов удаленного метода Java (Java RMI)
• Платформа Java, Enterprise Edition (Java EE)
• JavaBean
• OpenAIR
• Удаленный вызов процедуры (RPC)
• Windows Communication Foundation (WCF)
• Software Communications Architecture (SCA) - компоненты для встроенных систем, кросс-языковые, кросс-транспорт, кроссплатформенность

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

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

Ссылки

Дополнительная литература

• "CORBA". Ток. Технические характеристики. OMG.
• Орфали, Роберт. Основное руководство по выживанию клиент / сервер. Джон Вили и сыновья. 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.
• Моубрей, Томас Дж.; Захави, Рон. 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. John Wiley Sons. ISBN 0-471-38935-8.
• Моубрей, Томас Дж.; Мальво, Рафаэль К. Шаблоны проектирования CORBA. Джон Вили и сыновья. ISBN 0-471-15882-8.
• Орфали, Роберт; Харки, Дэн; Эдвардс, Джери. Мгновенный CORBA. Джон Вили и сыновья. ISBN 0-471-18333-4.
• Хармон, Пол ; Моррисси, Уильям (1996). Ситуационная книга объектной технологии. Джон Вили и сыновья. ISBN 0-471-14717-6.

Внешние ссылки

В Wikibooks есть книга по теме: Программирование CORBA

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