Технология CORBA и особенности проектирования баз данных
Информация - Компьютеры, программирование
Другие материалы по предмету Компьютеры, программирование
?айлов. В нашем случае это единственный файл, содержащий вышеприведенное описание. Для файла с именем, например, SimpleIDL.idl будут сгенерированы файлы SimpleIDL_c.hh, SimpleIDL_c.cpp (для использования на стороне клиента) и SimpleIDL_s.hh, SimpleIDL_s.cpp .
Создание серверного приложения
[4]Файлы _s.* содержат код, который позволяет связать серверное приложение с CORBA. Для нас наибольший интерес представляет сгенерированный класс POA_MyInterface. Этот класс содержит объявление чисто виртуальной (абстрактной) функции Summa:
class POA_MyInterface : ...
{:
...CORBA::Long Summa(CORBA::Long _op1,::Long _op2)(CORBA::SystemException) = 0;
...
};
Поскольку класс POA_MyInterface является только основой для серверного приложения, его часто называют скелетом или даже скелетоном (skeleton).
Очевидно, что программисту необходимо создать производный от него класс, в котором функция Summa была бы определена. Это можно сделать, например, так:
class MyInterfaceImpl : public POA_MyInterface
{
public:() {}::Long Summa(CORBA::Long _op1,::Long _op2)(CORBA::SystemException);
};::Long MyInterfaceImpl::Summa(CORBA::Long _op1,::Long _op2)(CORBA::SystemException)
{_op1 + _op2;
}
Класс реализаций MyInterfaceImpl часто создается автоматически, например, с помощью экспертов, входящих в состав Borland C++ Builder или Java Builder.
Теперь осталось написать код функции main():
#include
#include
#include "MyInterfaceImpl.h"
#pragma argsused(int argc, char* argv[])
{
{
// Инициализация взаимодействия с CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
// Создание серванта будущего CORBA-объекта* servant = new MyInterfaceImpl;
// Создание временного (transient)
// CORBA-объекта и получение объектной ссылки
CORBA::Object_ptr oRef = servant->_this();
// Преобразование объектной ссылки в строку::String_var str = orb->object_to_string (oRef);
// Запись в файлoref_file ("MyORef.ior");_file.write (str, strlen(str)+1);_file.close();<< "Waiting for client requests...";
// Цикл ожидания запросов клиентов>run();
}(const CORBA::Exception& e)
{<< e << endl;(1);
}0;
}
Некоторые пояснения. Создание серверного объекта с помощью метода _this() применяется довольно редко. Получаемый таким образом объект имеет совокупность характеристик, крайне затрудняющих его использование. В разделе, посвященном объектным адаптерам, будет рассказано, как создавать нормальные CORBA-объекты.
Результатом вызова метода _this() является объектная ссылка. Тип MyInterface определяет proxy-объект, MyInterface_ptr (или MyInterface_var) - указатель на него. Это первый вид объектной ссылки - на уровне приложения.
Вторая объектная ссылка - ссылка уровня ORB - появляется в результате ее преобразования к строке с последующей записью этой строки в файл. Вы можете ознакомиться с содержимым этого файла сразу после запуска серверного приложения.
Объектная ссылка записывается в файл, откуда ее может iитать приложение-клиент. Разумеется, этот способ скорее демонстрирует принцип организации связи между клиентом и сервером, чем представляет какую-либо практическую ценность.
Обратите внимание на то, что одно и тоже приложение может быть как клиентом, так и сервером - CORBA в этом плане не накладывает никаких ограничений.
Управление объектами
Созданный в предыдущем примере объект (не сервант, а сам CORBA-объект) является объектом временным. Это означает, что он не может существовать дольше, чем существует компонент CORBA, который его создал. В рассмотренном примере этот компонент явно не присутствовал в программе, и такой способ создания CORBA-объекта часто называют неявным. В реальных программах большинство CORBA-объектов создается другим путем. Данный раздел и посвящен рассмотрению связанных с этой темой вопросов.
Объектные адаптеры
Компонент CORBA, который отвечает за создание CORBA-объектов, их сервантов, поддерживает связь между ними и участвует в доставке вызова клиента нужному серванту, называется объектным адаптером.
Стандарт CORBA позволяет иметь и использовать несколько различных объектных адаптеров. В настоящее время существуют два стандартных объектных адаптера - BOA (Basic Object Adapter) и POA (Portable Object Adapter). Использование BOA признано устаревшим, так как это не позволяет обеспечить переносимость серверных CORBA-приложений, и мы о нем говорить не будем.
В реальных CORBA-приложениях используется древовидная иерархия объектных адаптеров. В корне ее находится так называемый Root POA - объектный адаптер по умолчанию. Программист получает доступ к Root POA c помощью стандартного кода, используемого во многих случаях:
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);::Object_var rpObj =>resolve_initial_references("RootPOA");
PortableServer::POA_var rootPoa = PortableServer::POA::_narrow(rpObj);
Дочерние POA создаются с помощью обращения к уже созданным POA как к фабрикам. Имейте в виду, что дочерний POA не наследует свойств своего базового POA - набор свойств для каждого создаваемого объектного адаптера нужно указывать явно. Например, если вы хотите создавать долгоживущие объекты, то сначала нужно создать соответствующий POA.
Перед созданием дочерних POA желательно создать так называемый менеджер POA. Он отвечает за распределение клиентских запросов между сервантами, находящимися под управлением различных POA, а также за управление их (POA) циклом жизни. Фабрикой такого менеджера может являться Root POA. При создании дочерних объектных адаптеров вы указываете менеджер POA в качестве аргумента. Если вы не создали свой менеджер и вместо его имени при вызове метода создания POA указали nil, то будет неявно создан и использован менеджер по умолчанию.
Процесс уничтожения объектных адаптеров происходит в определенном порядке - сначала дочерние POA, затем их родители.
Создание объекта с использованием POA
Приведем пример создания объекта