Исключения 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. Возбуждение этой исключительной ситуации – задача прикладного серверного приложения.