Технология CORBA и особенности проектирования баз данных
Информация - Компьютеры, программирование
Другие материалы по предмету Компьютеры, программирование
с использованием myPOA. Как уже говорилось, с каждым CORBA-объектом нужно сопоставить ключ - идентификатор, который позволяет однозначно идентифицировать этот объект. Давайте зададим этот идентификатор явно. Для этого вызовем метод, который позволяет создать этот идентификатор на основе строки:8
PortableServer::ObjectId_var objID =
PortableServer::string_to_ObjectId ("MyObject");
Следующие две команды создают сервант, а затем и CORBA-объект с указанным ObjectID:
MyInterfaceImpl servant;
myPOA->activate_object_with_id (objID, &servant);
Наконец, для начала обработки запросов от клиента вы должны активизировать менеджер POA:>activate();
Практику, когда для каждого CORBA-объекта при запуске приложения создается свой сервант, нельзя признать удачной - так можно съесть любое количество ресурсов. Ранее говорилось, что разработчик может создавать CORBA-объекты и без создания сервантов. Сделать это очень просто:
myPOA->create_reference_with_id(
objID, "IDL:MyInterface:1.0");
Сопоставить с таким объектом сервант можно позднее, причем самыми различными способами.
Временные и долгоживущие объекты
В CORBA есть команды создания объектов, но нет команды их уничтожения. Сделано это потому, что крайне трудно найти конкретный компонент CORBA, который взял бы на себя труд надежного и безопасного уничтожения объектов. В результате этого, под уничтожением объекта понимается некоторая последовательность действий, которые приводят к тому, что ни один клиент по имеющимся у него объектным ссылкам не может получить доступ к CORBA-объекту.
Рассмотрим, что происходит в случае временного объекта, созданного ранее с помощью вызова метода _this(). Объектная ссылка на этот объект, переданная клиенту через файл, содержит в себя имя хоста, на котором было запущено создавшее объект приложение, использованный порт TCP/IP, уникальный идентификатор объекта и уникальный. Это означает, что клиент может использовать имеющуюся у него объектную ссылку только до тех пор, пока серверное приложение запущено и в нем живет создавший объект объектный адаптер.
При остановке и последующем запуске этого же приложения на том же компьютере будет создан новый CORBA-объект - его собственный идентификатор и идентификатор его POA будут отличаться от тех, данные для которых находятся в старой объектной ссылке. Это означает, что по ней получить доступ к старому объекту в принципе невозможно. В этом случае и говорят, что CORBA-объект больше не существует. Клиент может выбросить имеющуюся у него объектную ссылку - она больше никогда не понадобится.
В случае использования долгоживущих объектов дело обстоит сложнее. Даже если объект создан с помощью POA, который предназначен для создания и управления persistent-объектами, это не значит, что после остановки серверного приложения клиент сможет вызвать удаленные методы по имеющейся у него объектной ссылке. В простейшем случае, никаких проблем не будет, если серверное приложение опять запущено вручную на том же хосте и с использованием того же порта TCP/IP.
Свойства POA
Возможность явного указания того, является ли CORBA-объект временным или долгоживущим - это только одна из стандартных возможностей POA. Определяется она следующим образом:
module PortableServer
{
enum LifeSpanPolicyValue { TRANSIENT, PERSISTENT };
interface LifeSpanPolicy : CORBA::Policy
{attribute LifeSpanPolicyValue;
};
Вот список всех остальных:
Режим управления заданием идентификатора объекта (IdAssignmentPolicyValue). Возможные значения - USER_ID или SYSTEM_ID. В первом случае идентификатор объекта задает сам пользователь, во втором - он автоматически генерируется POA.
Режим поддержки одним сервантом нескольких CORBA-объектов (IdUniquenessPolicyValue). Возможные значения - UNIQUE_ID (один сервант является инкарнацией только одного CORBA-объекта) и MULTIPLE_ID (один сервант может обслуживать несколько объектов).
Режим разрешения неявной активации (ImplicitActivationPolicyValue). Возможные значения - IMPLICIT_ACTIVATION (неявное создание CORBA-объекта, например, с помощью _this(), разрешено) и NO_IMPLICIT_ACTIVATION (необходимо создавать CORBA-объекты явно).
Режим создания и управления сервантами (RequestProcessingPolicyValue). Здесь нужно дать более подробные пояснения.
В принципе, возможны только два режима создания сервантов: серванты создаются в программе либо явно (как в ранее рассмотренных примерах), либо в процессе поступления клиентских запросов - возможно, даже для обслуживания одного-единственного запроса. POA обеспечивает поддержку обоих режимов.
Во-первых, POA может содержать так называемый Active Object Map (AOM), т.е. массив указателей на уже созданные серванты. Индексом этого массива является значение Object ID. В этот массив могут попадать как серванты, созданные явно программистом, так и серванты, динамически созданные самим объектным адаптером.
В случае динамического создания сервантов предусмотрено два отдельных режима - Activation-режим и Location-режим. Названия их, на мой взгляд, выбраны очень странным образом. Activation-режим заключается в том, что при поступлении клиентского запроса POA сначала ищет подходящий сервант в AOM, и только если таковой не найден, этот сервант динамически создается POA, а затем указатель на него помещается в AOM. Location-режим не смотрит в AOM - AOM вообще не поддерживается в этом режиме - а создает сервант для обслуживания пришедшего вызова, а затем уничтожает его.
Процесс динамического создания сервантов заключается в том, что POA вызывает некие написанные программистом функции. Естественно, такие функции необходимо зарегистрировать в POA - для этого предусмотрены специальные команды.
<