Отображение IDL на языки программирования

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

Фрагменты, реализующие некоторые задачи инфраструктуры CORBA, отображаются на языки программирования несколько иначе, чем стандартные IDL – объявления.

Скелет содержит сгенерированный класс (часто этот класс тоже называют скелетом). В этом классе есть все необходимое для взаимодействия серверного приложения с CORBA. Нет в нем реализации тех методов, которые программист объявил в IDL – декларации. Данный класс нужен только для того, чтобы на основе его создать производный класс (имя этого производного класса программист задает сам), который содержит все реализации.

Таким образом, задача создания серверной логики для данного типа CORBA – объектов разбивается на две части: системно-коммуникационная часть обеспечивается сгенерированным кодом в базовом классе, а прикладная часть записывается явно программистом в классе, производном от сгенерированного.

Нетрудно сообразить, что серванты являются экземплярами этого производного класса.

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

Опишем подробнее, что происходит на стороне клиента.

На базе IDL – объявления генерируется класс, который содержит реализацию всех методов, объявленных для данного интерфейса. Но реализация этих методов не имеет никакого отношения к бизнес – логике приложения. Задача этих методов – упаковка информации о вызове (имя метода, число, типы, значения его аргументов, тип возвращаемого результата, перечень возможных исключений и т.п.) и преобразование этой информации в вид, пригодный для передачи на сторону сервера по сети в соответствии с требованиями протокола GIOP (General Inter-ORB Protocol) – протокола обмена информацией CORBA.

Для выполнения реального вызова в процессе работы программы нужно создать экземпляр этого класса. Это делает не программист, а сама CORBA. Такая переменная (ее называют proxy-объект) создается автоматически в тот момент, когда в клиентское приложение попадает объектная ссылка CORBA. При создании proxy-объекта создается "указатель" на него, который и используется программистом для выполнения удаленных вызовов, которые физически являются локальными вызовами методов proxy-объекта. Тип этого указателя также генерируется автоматически на основе IDL – объявлений. Этот указатель имеет также название "объектная ссылка CORBA". Не следует ее путать с "объектной ссылкой CORBA", которая является результатом создания CORBA – объекта на стороне сервера.

Объектные адаптеры.

Основные задачи объектных адаптеров – OA:

Создание CORBA – объектов, и, следовательно, объектных ссылок уровня ORB IOR (Interoperable Object Reference). Создание объекта не обязательно связано с созданием серванта (это может быть выполнено и позднее). С каждым создаваемым объектом сопоставляются Object ID – уникальный ключ внутри фабрики объектов и Object Key - Object ID и идентификатор фабрики объектов.

Создание сервантов по указанию программиста, например в момент поступления запроса от клиентского приложения.

Управление созданными сервантами и направление к ним запросов клиентов.

Уничтожение сервантов. Это нетривиальная задача, так как следует убедиться в том, что сервант никому больше не нужен. В условиях многопоточных приложений это непросто. Обычно OA ведет счетчик объектных ссылок на каждый сервант.

Умение работать с OA нужно только «чистому» CORBA – программисту. Тем не менее, попытаемся кратко разобраться с некоторыми характеристиками работы объектных адаптеров.

Политика нитей. Определяется, каким образом обрабатываются запросы. Варианты ответов: один за другим, запросы клиентов к серванту могут поступать в конкурентном режиме из различных потоков.

Политика продолжительности жизни. Создаваемые серванты могут быть временными (прекращать существование по окончании работы серверного приложения, создавшего его) или долгоживущими.

Политика уникальности объектного идентификатора. Можно разрешить (или запретить) режим работы, при котором на один сервант может ссылаться несколько объектных ссылок. Это удобно применять в том случае, если есть много долгоживущих объектов, состояние которых хранится в БД (для каждого объекта в отдельной записи), тогда удобно применять в качестве ключа значение Object ID для серванта, который не имеет состояния, но в случае необходимости извлекает всю необходимую информацию из БД.

Политика назначения идентификатора определяет, кто назначает ID создаваемому объекту, сама фабрика объектов или программист.