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

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

Common Request Object Broker Architecture ( CORBA ) представляет собой стандарт определяется Object Management Group (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), написанными для этих языков.

Спецификация 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 () активирует объект без воплощения слуги, а воплощение слуги позже выполняется по запросу с помощью диспетчера слуг.

Портативный Объект адаптер (АПО) является объектом 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. Хотя это и не зависит от «зависимых от языка Enterprise Java Beans (EJB)», это более общая форма EJB, предоставляющая четыре типа компонентов вместо двух, определяемых EJB. Он предоставляет абстракцию сущностей, которые могут предоставлять и принимать услуги через четко определенные именованные интерфейсы, называемые портами .

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

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

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

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

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

Общий протокол InterORB (GIOP) [ править ]

GIOP является абстрактным протокол , по которому объект запроса брокеров (брокеры) связь. Стандарты, связанные с протоколом, поддерживаются Группой управления объектами (OMG). Архитектура 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: « corbaloc: » и « corbaname: ». Их цель - предоставить удобочитаемый и редактируемый способ указать место, где можно получить IOR.

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

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) ^[4] и OmniORB (реализация C ++ и Python с открытым исходным кодом) ^[5]) имеют параметры для настройки функций управления потоками и соединениями. Не все реализации ORB предоставляют одинаковые возможности.

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

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

Сжатие

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

Проблемы и критика [ править ]

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

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

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

Первоначальные спецификации CORBA определяли только IDL, а не формат on-the-wire. Это означало, что совместимость исходного кода была лучшей за несколько лет. В 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 CONNECT или SOCKS- соединения. Когда-то было сложно даже заставить реализации использовать один стандартный порт - вместо этого они обычно выбирали несколько случайных портов. На сегодняшний день существующие ORB действительно имеют эти недостатки. Из-за таких трудностей некоторые пользователи все чаще используют веб-службы вместо CORBA. Они общаются с использованием XML / SOAPчерез порт 80, который обычно остается открытым или фильтруется через прокси-сервер HTTP внутри организации, для просмотра веб-страниц через HTTP. Однако последние реализации CORBA поддерживают SSL и могут быть легко сконфигурированы для работы с одним портом. Некоторые ORBS, такие как TAO , omniORB и JacORB, также поддерживают двунаправленный GIOP, что дает CORBA преимущество, заключающееся в возможности использовать обратный вызов, а не метод опроса, характерный для реализаций веб-сервисов. Кроме того, большинство современных межсетевых экранов поддерживают GIOP и IIOP и, таким образом, являются дружественными к CORBA межсетевыми экранами.

См. Также [ править ]

Программная инженерия [ править ]

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

Компонентные программные технологии [ править ]

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

Привязки языков [ править ]

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

Ссылки [ править ]

Дальнейшее чтение [ править ]

• «КОРБА» . Текущий . Технические характеристики. 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 июня 2 005 .
• Болтон, Финтан. Чистая Корба . Самс Паблишинг. 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.

Внешние ссылки [ править ]

В Викиучебнике есть книга на тему: Программирование CORBA.

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