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

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

Сокращение	КОРБА
Положение дел	Опубликовано
Год начался	1991 год ( 1991 )
Последняя версия	3.4 февраль 2021 г ( 2021-02 )
Организация	Группа управления объектами
Веб-сайт	Корба .org

Общая архитектура брокера объектных запросов ( 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, через который приложение будет взаимодействовать с другими объектами. Вот как это реализуется на практике:

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:

Illustration of the autogeneration of the infrastructure code from an interface defined using the CORBA IDL

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

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

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

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

Версия	Дата версии	Основные моменты	IDL-версия Corba
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 (CCM)	-
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 г.	Добавление ЗИОП	-
3.4	февраль 2021 г.	Аннотации	4.2

Обратите внимание, что изменения IDL произошли с аннотациями (например, @unit, @topic), заменившими некоторые прагмы.

Слуги

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

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

The Адаптер переносимых объектов (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)

Основная статья: Общий протокол Inter-ORB

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

1. Интернет-протокол InterORB (IIOP). Интернет-протокол Inter-Orb представляет собой реализацию GIOP для использования через Интернет и обеспечивает сопоставление между сообщениями GIOP и уровнем TCP/IP .
2. Протокол SSL InterORB (SSLIOP) — SSLIOP — это IIOP поверх SSL , обеспечивающий шифрование и аутентификацию .
3. Протокол HyperText InterORB (HTIOP) — HTIOP представляет собой IIOP через HTTP , обеспечивающий прозрачный обход прокси-сервера.
4. Zipped 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 и 0xffffff зарезервированы для экспериментального использования. 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: ", " фтп: " и " 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 и Telefonica работали над расширением стандарта 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 является Интернет-протокол Inter-ORB или 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.
• Модель компонентных объектов (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 System Object Model SOM и DSOM – компонентные системы IBM, используемые в OS/2 и AIX.
• Механизм интернет-коммуникаций (ICE)
• Удаленный вызов метода Java (Java RMI)
• Платформа Java, Enterprise Edition (Java EE)
• JavaBean
• Под открытым небом
• Удаленный вызов процедур (RPC)
• Фонд связи Windows (WCF)
• Архитектура программных коммуникаций (SCA) - компоненты для встраиваемых систем, кросс-языковая, кросс-транспортная, кросс-платформенная.

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

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

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

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

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

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