Что такое ИДЛ?

Язык определения интерфейса (IDL) используется для настройки связи между клиентами и серверами в удаленных вызовах процедур (RPC). Было много вариантов этого, таких как Sun RPC, ONC RPC, DCE RPC и так далее.

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

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

+----------------+
| Client         |
|  +----------+  |         +---------------+
|  |   main   |  |         | Server        |
|  |----------|  |         |  +----------+ |
|  | stub_cli |----(comms)--->| stub_svr | |
|  +----------+  |         |  |----------| |
+----------------+         |  | function | |
                           |  +----------+ |
                           +---------------+

В этом примере вместо вызова function в той же программе main вызывает клиентскую функцию-заглушку (с тем же прототипом, что и function), которая отвечает за упаковку информации и ее передачу другому процессу по каналу связи.

Это может быть та же машина или другая машина, это не имеет большого значения — одно из преимуществ RPC — возможность перемещать серверы по желанию.

На сервере есть процесс «слушателя», который будет получать эту информацию и передавать ее на сервер. Заглушка сервера получает информацию, распаковывает ее и передает реальной функции.

Затем реальная функция делает то, что ей нужно, и возвращается к серверной заглушке, которая может упаковать возвращаемую информацию (как код возврата, так и любые переменные [out] или [in,out]) и передать ее обратно клиентской заглушке.

Затем клиентская заглушка распаковывает это и передает обратно main.

Фактические детали могут немного отличаться, но этого объяснения должно быть достаточно для концептуального обзора.

Фактический IDL может выглядеть так:

[   uuid(f9f6be21-fd32-5577-8f2d-0800132bd567),
    version(0),
    endpoint("ncadg_ip_udp:[1234]", "dds:[19]")
] interface function_iface {
    [idempotent] void function(
        [in] int handle,
        [out] int *status
    );
}

Вся эта информация вверху (например, uuid или endpoint) в основном представляет собой сетевую информацию, используемую для соединения клиента и сервера. Суть этого находится внутри раздела интерфейса, где показан прототип. Это позволяет компилятору IDL создавать function клиентские и серверные функции-заглушки для компиляции и связывания с вашим клиентским и серверным кодом для обеспечения работы RPC.

Microsoft действительно использует IDL (я думаю, что у них есть компилятор MIDL) для материалов COM. Я также использовал сторонние продукты с операционными системами MS, как DCE, так и ONC RPC.

Существует также язык интерактивных данных, который я использовал для научного анализа данных, но возможно, из контекста вам ясно, что это не то, что означает этот IDL.

IDL — это аббревиатура от языка определения интерфейса, несколько вариантов которого зависят от поставщика или группы стандартов. что определило язык. Цель IDL — описать интерфейс для некоторой службы, чтобы клиенты, желающие использовать службу, знали, какие методы и свойства интерфейса предоставляет служба. IDL обычно используется с двоичными интерфейсами, а языковой файл IDL описывает типы данных, используемые в двоичном интерфейсе.

Существует несколько различных стандартов для бинарных компонентов, как правило, COTS или Commercial Off The Shelf, и то, как клиент взаимодействует с двоичным компонентом, может различаться, хотя традиционно это какая-то версия удаленного вызова процедур или RPC. используется. Двумя такими стандартами являются Общая объектная модель Microsoft или стандарт COM и Общий брокер запросов объектов или стандарт CORBA. Существуют и другие стандарты для таких компонентов, как плагины Firefox. или подключаемые модули для других приложений, таких как сама Visual Studio, однако они не обязательно используют какую-либо форму языка описания интерфейса, используя вместо этого какой-либо комплект средств разработки программного обеспечения или SDK со стандартизированными и хорошо известными интерфейсами API.

То, что позволяет IDL, — это большая степень гибкости в возможности создавать компоненты, предлагающие услуги различных видов, которые из-за их бинарной природы могут использоваться с множеством разных языков программирования и множеством различных сред.

Microsoft использует диалект IDL с COM-объектами, и Microsoft IDL отличается от CORBA IDL, хотя есть сходство, поскольку они имеют общие языковые корни. Файл IDL содержит описание интерфейсов, поддерживаемых COM-объектом. COM позволяет создавать службы In Process (могут использовать RPC или прямые вызовы DLL) или службы Out of Process (использует RPC). Идея COM заключается в том, что клиенту нужно знать только идентификатор компонента вместе с интерфейсом, чтобы иметь возможность его использовать. Клиент запрашивает COM-объект, затем запрашивает объект класса из фабрики COM-объектов, который поддерживает интерфейс, который клиент хочет использовать, а затем использует COM-объект через этот интерфейс.

Microsoft предоставляет компилятор MIDL, который обрабатывает файл IDL для создания библиотеки типов, предоставляя пользователям COM-объекта информацию об интерфейсе и необходимые заглушки для маршалинга данных через интерфейс между клиентом и службой.

Маршалинг данных в основном означает, что заглушка берет данные, предоставленные клиентом, упаковывает их и отправляет службе, которая выполняет какое-то действие и отправляет данные обратно. Эта отправка и получение данных может осуществляться через какую-либо службу RPC или через прямые вызовы функций DLL. Ответ службы переводится в удобную для клиента форму и затем предоставляется клиенту. Таким образом, функция маршалинга представляет собой адаптер (см. шаблон проектирования адаптера) или мост (см. шаблон проектирования моста) между клиентом и службой.

Visual Studio, мой опыт работы с C++, содержит ряд мастеров, которые можно использовать для создания примера, чтобы вы могли поиграть с этим. Если вы заинтересованы, вы можете создать рабочее пространство, а затем в рабочем пространстве вы можете создать проект ATL для создания элемента управления, а затем простой диалоговый проект MFC для его проверки. Использование ATL для вашего COM-элемента управления скрывает довольно много деталей, которые вы сможете изучить позже, а простой диалоговый проект MFC предоставляет простой способ создания контейнера. Вы также можете использовать инструмент ActiveX Control Test Container, доступный в Visual Studio, для предварительного тестирования и проверки работы методов и свойств.

На веб-сайтах, таких как codeproject.com, также есть несколько примеров проектов. Например, вот один, использующий C для раскрытия всей уродливой сантехники, стоящей за COM, а вот с использованием C++ без ATL.

Это язык, который использовался в эпоху COM для определения интерфейсов в (предположительно) независимой от языка манере.

Он определяет интерфейс, который будет использоваться для связи с открытой службой в другом приложении.

Если вы используете SOAP, вы знаете о WSDL. WSDL — это еще одна форма IDL. IDL обычно относится к Microsoft COM или CORBA IDL.

IDL жизненно необходим в 2 случаях. 1. Создать прокси/заглушки dll для exe-серверов. 2. Создать библиотеку типов для серверов автоматизации.

Очень хорошая статья по основам IDL находится по адресу ссылка.

Для изучения IDL лучше читать собственные заголовочные файлы idl компиляторов, которые включены в подкаталог пакета VC++.