Брокер объектных запросов¶

Брокер объектных запросов (англ. Object Request Broker, ORB) — это программная прослойка (middleware), обеспечивающая взаимодействие между распределёнными объектами в гетерогенной среде. ORB выступает в роли посредника, который позволяет объектам, написанным на разных языках программирования, работающим на разных операционных системах и расположенным на разных узлах сети, вызывать методы друг друга так, как если бы они находились в одном адресном пространстве. Основная функция брокера — локализация объекта-получателя, передача запроса, маршалинг (упаковка) и демаршалинг (распаковка) параметров, а также возврат результата или исключения.

¶История

Концепция брокера объектных запросов возникла в конце 1980-х — начале 1990-х годов как ответ на необходимость интеграции разнородных систем в рамках корпоративных информационных сред. До появления ORB разработчики были вынуждены использовать низкоуровневые протоколы (сокеты, RPC) или проприетарные решения, что затрудняло создание масштабируемых и переносимых распределённых приложений.

Ключевым этапом стала спецификация CORBA (Common Object Request Broker Architecture), разработанная консорциумом Object Management Group (OMG) в 1991 году. CORBA определила стандартный протокол GIOP (General Inter-ORB Protocol) и его реализацию для TCP/IP — IIOP (Internet Inter-ORB Protocol). В 1990-е годы CORBA стала доминирующей технологией для построения распределённых систем в таких областях, как телекоммуникации, авиастроение и банковское дело.

В конце 1990-х — начале 2000-х годов с развитием веб-технологий и появлением Java RMI (Remote Method Invocation), DCOM (Microsoft), а затем и веб-сервисов (SOAP, REST) популярность CORBA-совместимых ORB начала снижаться. Тем не менее, принципы, заложенные в ORB, легли в основу более современных протоколов, таких как gRPC, и продолжают использоваться в специализированных отраслях (например, в системах управления реального времени).

¶Архитектура и принцип работы

¶Основные компоненты

Типичный ORB включает следующие элементы:

Ядро ORB (ORB Core) — обеспечивает транспортный уровень, отвечает за установление соединения, передачу сообщений и управление потоками.
Интерфейсный репозиторий (Interface Repository) — хранит метаданные о типах, методах и исключениях, доступных для удалённого вызова.
Адаптер объектов (Object Adapter) — связывает ORB с конкретными реализациями объектов, управляет их жизненным циклом.
Заглушки (Stubs) — клиентские прокси-объекты, которые скрывают детали сетевого взаимодействия. На стороне клиента заглушка преобразует вызов метода в сообщение (маршалинг).
Скелетоны (Skeletons) — серверные прокси-объекты, которые принимают сообщение, демаршализуют параметры и вызывают соответствующий метод на реальном объекте.

¶Процесс вызова удалённого метода

Клиентский код вызывает метод на локальном объекте-заглушке.
Заглушка упаковывает имя метода, параметры и контекст вызова в формат, определённый протоколом ORB (например, CDR — Common Data Representation для CORBA).
Ядро ORB на стороне клиента отправляет сообщение по сети серверу.
На серверной стороне ядро ORB принимает сообщение и передаёт его скелетону.
Скелетон распаковывает параметры и вызывает соответствующий метод на реальном объекте.
Результат (или исключение) упаковывается и отправляется обратно клиенту.
Заглушка на стороне клиента распаковывает результат и возвращает его вызывающему коду.

¶Классификация

Брокеры объектных запросов можно классифицировать по нескольким признакам.

¶По стандарту

CORBA-совместимые ORB — реализуют спецификации OMG (например, TAO, omniORB, MICO). Обеспечивают максимальную переносимость и интероперабельность.
Проприетарные ORB — разработаны для конкретных платформ или языков (например, DCOM от Microsoft, Java RMI, .NET Remoting).
Современные протоколы с ORB-подобной архитектурой — gRPC (основан на Protocol Buffers и HTTP/2), Apache Thrift, Ice (ZeroC).

¶По языку реализации

Мультиязычные — поддерживают несколько языков программирования (CORBA, gRPC, Thrift).
Одноязычные — ориентированы на один язык (Java RMI — только Java, DCOM — преимущественно C++/COM).

¶По способу взаимодействия

Синхронные — клиент блокируется до получения ответа от сервера.
Асинхронные — клиент может продолжать работу, получая результат через callback или polling.
Однонаправленные (one-way) — клиент отправляет сообщение и не ждёт ответа.

¶Применение

¶Корпоративные информационные системы

ORB традиционно использовались для интеграции унаследованных (legacy) систем с новыми приложениями. Например, в банковской сфере CORBA-ORB позволял связывать мэйнфреймовые приложения на COBOL с веб-интерфейсами на Java.

¶Системы реального времени

В авионике, управлении промышленными роботами и телекоммуникационном оборудовании применяются ORB с предсказуемым временем отклика. Пример — TAO (The ACE ORB), реализующий CORBA для систем реального времени.

¶Распределённые вычисления

В научных и инженерных расчётах ORB используются для организации вычислительных кластеров. Например, протокол Ice (Internet Communications Engine) применяется в симуляторах и системах моделирования.

¶Веб-сервисы и микросервисы

Современные реализации, такие как gRPC, широко применяются в архитектуре микросервисов. gRPC использует HTTP/2 для транспорта и Protocol Buffers для сериализации, что обеспечивает высокую производительность и строгую типизацию.

¶Примеры реализаций

¶TAO (The ACE ORB)

TAO — это реализация CORBA с открытым исходным кодом, ориентированная на системы реального времени. Разработана в Вашингтонском университете. Используется в авиационных системах (например, в Boeing 777) и в военных проектах.

¶omniORB

omniORB — высокопроизводительная реализация CORBA для C++ и Python. Отличается низким потреблением памяти и используется в научных проектах (например, в CERN).

¶gRPC

gRPC — современный фреймворк, разработанный компанией Google. Основан на Protocol Buffers и HTTP/2. Поддерживает множество языков (C++, Java, Go, Python, C#). Широко применяется в микросервисной архитектуре, в том числе в проектах Kubernetes и etcd.

¶Apache Thrift

Thrift — фреймворк для создания распределённых систем, разработанный в Facebook (продукт Meta, признанной экстремистской и запрещённой в РФ). Позволяет определять типы данных и интерфейсы в едином файле, генерируя код для разных языков.

¶Критика и ограничения

Сложность внедрения — CORBA-совместимые ORB требуют глубокого понимания распределённых систем, настройки интерфейсных репозиториев и адаптеров объектов.
Производительность — маршалинг и демаршалинг, а также накладные расходы на протокол (особенно в CORBA) могут быть значительными для высоконагруженных систем.
Проблемы с брандмауэрами — IIOP использует динамические порты, что усложняет настройку сетевой безопасности.
Устаревание — CORBA-технологии постепенно вытесняются более простыми и гибкими решениями, такими как REST и gRPC.

¶Интересные факты

Спецификация CORBA включала более 1500 страниц, что делало её одной из самых объёмных в области программной инженерии.
В 1990-е годы существовали попытки создания «универсального ORB» для операционной системы Windows, но проект COM+ (расширение DCOM) не получил широкого распространения за пределами платформы Microsoft.
Протокол IIOP лёг в основу стандарта RMI over IIOP, который позволял вызывать удалённые Java-объекты через CORBA-инфраструктуру.

¶Источники

Object Management Group. «The Common Object Request Broker: Architecture and Specification», Revision 3.3, 2012.
Henning, M., Vinoski, S. «Advanced CORBA Programming with C++». Addison-Wesley, 1999.
Schmidt, D. C. «Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects». Wiley, 2000.
Документация проекта gRPC. «gRPC: A High Performance, Open Source Universal RPC Framework». Google, 2015.
Документация Apache Thrift. «Apache Thrift: Cross-language Service Development Framework». Apache Software Foundation.

Заметили ошибку или не согласны с информацией в статье? Напишите нам support@bfometr.ru