IDL Interface Definition Language
OMG определяет IDL как средство для описания интерфейсов, к которым обращаются клиенты и которые должны быть реализованы на стороне сервера. Объявления интерфейсов, написанные на OMG IDL, полностью определяют интерфейс и задают параметры каждой операции.
CORBA по определению не привязана ни к языкам программирования, ни к операционным системам, ни к транспортным протоколам, ни к двоичным структурам объектов. Совместимость CORBA – приложений, написанных на разных языках программирования с помощью программных инструментов различных производителей и работающих в разных операционных средах, обеспечивается строгой стандартизацией языка IDL и схемы его отображения на конкретные языки программирования.
IDL – декларативный язык, похожий на С++. Помимо объявлений IDL описание может содержать директивы препроцессора (которые полностью взяты из С++).
Классический CORBA – проект начинается с создания его IDL –объявлений.
После создания необходимого набора IDL-деклараций и помещения их в один или несколько файлов с расширением IDL происходит следующее. Эти файлы обрабатываются специальным компилятором, результатом работы которого является набор сгенерированных файлов, часть которых используется на стороне сервера, а часть – на стороне клиента. Файлы на стороне сервера определяют структуру серверных объектов, поэтому их обычно называют «скелетами» sceleton. Задача программиста – нарастить этот скелет, то есть дописать текст процедур. Файлы на стороне клиента образуют образуют так называемую заглушку (stub). Заглушка содержит полностью готовый к выполнению код, который превращает вызовы клиентом локальных методов заглушки в вызов соответствующих им удаленных методов реальных серверных объектов.
Базовые типы языка IDL: целое, беззнаковое целое и т.п., строка, логическое значение, перечисление (совокупность именованных констант), тип – любой (any). Заметим, что строки бывают двух видов: ограниченные и неограниченные.
Особо выделяется тип octet, который предполагает передачу данных от сервера к клиенту без всяких преобразований. Данные других типов при переходе от сервера к клиенту могут пересекать границы операционных систем и аппаратных платформ. При этом может происходить, например, перекодировка символов из ASCII в EBCDIC или изменение порядка байтов внутри целых чисел.
В IDL особо выделяются сконструированные типы данных. К ним относят массивы (arrays), последовательности (sequence), структуры (struct) и объединения (union). Сконструированные типы описываются при помощи инструкции typedef.
IDL позволяет задавать многомерные массивы. При создании массива обязательно говорить typedef. Массив может содержать произвольное количество размерностей, любое число элементов, элементы массива могут быть разных типов. При описании массива следует явно (то ест ь числом) указать количество элементов в каждой размерности.
Последовательности IDL во многом похожи на массивы. Разница заключается в том, что размерности массива должны быть указаны явно, а длина последовательности может быть произвольной, изменяющейся.
Структура - именованная совокупность полей любого типа. Структура не может содержать ни методов, ни определений типов – только данные. Структура может содержать вложенные структуры.
Объединение. Семантика объединений IDL такая же, как и в С++: объединение можно трактовать как структуру, все поля которой расположены, начиная с одного и того же адреса. В любой момент времени активным является поле только одного и того же типа. В качестве типов полей могут использоваться любые типы IDL. Объединение всегда содержит признак, говорящий о том, поле какого типа используется в настоящий момент. Часто этот признак называют дискриминатором. Дискриминатор может иметь только один из так называемых «интегральных» типов: char, Boolean, перечисление, целое.
Исключения CORBA.
Исключения не являются полноценным типом. Например, их невозможно передавать в качестве аргументов при вызове методов, нельзя создавать в структурах поле типа «исключение», нельзя использовать вложенные исключения. Исключения в CORBA примитивнее, чем в С++ или в JAVA, поскольку требуется делать их отображения на языки программирования, которые не используют модель исключительных ситуаций.
Различают два вида исключений: системные и определенные пользователем. Перечень всех системных исключений дается в спецификации CORBA. Любое системное исключение всегда содержит два поля: код исключения и признак завершенности операции (говорит о том, на каком этапе выполнения удаленного запроса возникла ошибка). Исключения, определенные пользователем, используются в тех случаях, когда исключительная ситуация возникла не в связи с системой, а в связи с логикой приложения.
Интерфейсы CORBA. Определить интерфейс – значит определить тип серверного объекта. На IDL невозможно создать экземпляр.
Передача параметров.
Спецификация CORBA предполагает три вида передачи параметров: in, out, inout.
in - параметр передается от клиента серверу, за выделение и освобождение памяти отвечает клиент. Предполагается, что реализация метода не пытается изменить этот параметр, если это возможно.
out – параметр передается от сервера клиенту. За выделение памяти отвечает сервер, за освобождение - клиент.
inout – параметр создается и инициализируется клиентом, затем передается на сервер. После того, как сервер использовал его начальное значение, он может уничтожить объект и создать новый, с другим значением, хотя это и не обязательно. За освобождение памяти отвечает клиент.
Наследование интерфейсов – мощная концепция. Главное – она позволяет объявлять в IDL методы с аргументом типа "объектная ссылка", указывая в качестве типа такого аргумента базовый интерфейс (в соответствии с некоторой иерархией, таких иерархий может быть несколько!).
Обеспечение информации об удаленных объектах подразумевает их хранение в базах данных CORBA – репозитариях интерфейсов. Каждая запись такой базы должна иметь уникальный ключ, называемый репозитарным идентификатором (RID). Уникальность этого ключа должен обеспечить разработчик системы. В репозитариях хранится практически та же информация, что и в IDL –файлах. Начиная с версии CORBA 2.0, требуется взаимодействие различных ORB, что повлекло ведение нескольких форматов RID.
CORBA-объекты и серванты.
Итак, создав IDL – объявления, мы построили тип будущих CORBA –объектов. Требования, предъявляемые к серверному объекту:
Особенности поведения серверного объекта определяются на уровне самой технологии. То есть объект не может быть ни переменной какого-то конкретного языка программирования (в отличие от серверного объекта Java-технологии), ни двоичным объектом, специфическим для конкретной аппаратной реализации или ОС (как серверные объекты COM).
Серверный объект в общем случае должен иметь состояние, то есть обеспечивать сохранность информации между вызовами. Это означает, в частности, что все серверные объекты, даже одного типа, отличаются друг от друга.
Серверный объект должен иметь возможность существовать дольше, чем работает создавшее его приложение. Остановка приложения (с возможностью его последующего запуска) не должна в общем случае приводить к уничтожению конкретного серверного объекта.
Из этого следует, что для обеспечения этих требований серверный объект должен быть просто совокупностью информации и потенциальных возможностей, предоставляемых в рамках технологии CORBA. Он не существует как некоторая реальность, которая имеет размер или находится в оперативной памяти или в базе данных по некоторому адресу. Это – логическое понятие, смысл которого таков: пока не создан ни один CORBA – объект удаленное взаимодействие приложений просто невозможно. Если объект создан, для клиента возникает потенциальная возможность получить доступ к той функциональности, которая определяется интерфейсом объекта, с помощью средств CORBA. Важно при этом, что взаимодействие будет именно с этим объектом, а не с другим объектом этого же типа.
Создание CORBA – объекта – это активное действие – вызов некоторого метода, входящего в API CORBA. При этом создается логический CORBA – объект и физическая ссылка на него. Объектная ссылка (или объектная ссылка уровня ORB) представляет собой последовательность октетов, в которых закодирована вся необходимая информация о созданном CORBA – объекте. В нее входят:
Вид сетевого протокола (одного или нескольких), который может быть использован для доступа к данному объекту.
Параметры приложения, создавшего CORBA – объект, с учетом особенностей сетевого протокола. Например, если в качестве транспортного протокола используется TCP/IP, то такими параметрами будут IP-адрес хоста, на котором запущено серверное приложение, и номер порта, который используется им для CORBA – взаимодействия.
Имя фабрики CORBA – объектов (объектного адаптера), который создал данный объект.
Уникальный идентификатор объекта в данной фабрике.
Репозитарный идентификатор CORBA – интерфейса, который является типом данного CORBA – объекта.
И другое.
Объектная ссылка и CORBA – объект – это не синонимы. Как обычно для любых объектно-ориентированных языков, на один и тот же объект может существовать несколько ссылок.
Клиентское приложение может успешно выполнить вызов серверного объекта в следующем случае:
На нужном хосте запущено серверное приложение, причем это приложение слушает «правильный» порт, содержит фабрику объектов, создавшую указанный в запросе COBRA – объект, активизировало этот объект.
Уничтожение CORBA – объекта выражается в том, что при попытке вызова клиентом данного CORBA – объекта возникает стандартное системное исключение CORBA OBJECT_NOT_EXIST. Возбуждение этой исключительной ситуации – задача прикладного серверного приложения.