Технология CORBA и особенности проектирования баз данных

Размещено на http://www.allbest.ru/

Российский Государственный Социальный Университет

Кафедра моделирования информационных систем и сетей

Реферат

по дисциплине базы данных

на тему:

«Технология CORBA и особенности проектирования баз данных»

Выполнила

студентка гр.АСУ-Д-4

Фудина М.С.

Проверил доцент

Агальцов В.П.

Москва 2011

Введение

архитектура объектный запрос база данные

CORBA(Common Object Request Broker Architecture)- Общая Архитектура Брокера Объектных запросов

Это стандарт, набор спецификаций, для промежуточного программного обеспечения объектного типа, возникающий в результате самого широкого обсуждения накопившихся реальных проблем, в котором участвуют и разработчики и потребители технологий. В результате такого обсуждения создается документ, предлагающий решение рассматриваемых вопросов на уровне существующих технологий и технологий ближайшей перспективы. Достоинством опережающей разработки спецификации по сравнению с реализацией является возможность для независимых разработчиков создавать потенциально совместимые продукты, не ограничивая свободы выбора языков, ОС, аппаратных платформ, и не диктуя выбора конкретного технологического решения.

CORBA является концепцией, а не ее реализацией. Когда мы говорим "COM", то понимаем под этим скорее набор конкретных средств - элементов операционной системы, библиотек, утилит и т.п., которые являются составной частью того, что называется Microsoft Windows. Под термином "CORBA" понимается именно сложная и развитая концепция, которая сформулированна на уровне специального языка описаний - IDL. Реализации же этой концепции могут сильно отличаться друг от друга по различным критериям, наиболее важным в том или другом случае. VisiBroker и Application Server, BEA WebLogic, Iona Orbix, Oracle Application Server и "картриджи" Oracle, IBM BOSS - все эти продукты используют те или иные возможности CORBA.

Под "стандартом" применительно к CORBA понимается то, что официально утверждено консорциумом OMG. Надо сказать, что это очень высокий уровень "легитимности", так как авторитет OMG в компьютерном мире чрезвычайно высок. OMG представляет собой некоммерческую организацию, являющуюся содружеством разработчиков программного обеспечения и его потребителей, объединивших свои усилия для создания спецификаций этой технологии. В настоящий момент в OMG состоит более 800 членов, включая всех сколько-нибудь серьезных производителей программного обеспечения (и даже c недавнего времени Microsoft). Первая спецификация CORBA появилась в 1991 г. Новые возможности официально считаются добавленными в CORBA в момент утверждения соответствующей спецификации. Как правило, в разработке спецификации участвуют крупнейшие специалисты в данной области. Разработка реализации - задача конкретной фирмы. Обычно от утверждения спецификации до появления высококачественной реализации проходит довольно много времени - иногда несколько лет. В настоящий момент стандартизовано отображение языка IDL на 6 языков программирования - Ada, C, C++, Cobol, Java и Smalltalk. Существуют также отображения на Pascal (точнее, Delphi), Perl, Python и еще несколько языков, но они не стандартизованы.

Объекты CORBA можно рассматривать как экземпляры (instances) некоторого метатипа, причем и метатип, и сами объекты существуют вне связи с конкретной программой на конкретном языке. Этот метатип в CORBA называется «интерфейсом».

Технология CORBA

Спецификация CORBA (Common Object Request Broker Architecture) разработана группой компаний Object Management Group и описывает основанный на объектах способ создания распределенных приложений, то есть как осуществляется взаимодействие объектов клиента и сервера. После инсталляции специального программного обеспечения сервер приложений и клиенты могут взаимодействовать, используя объекты и интерфейсы CORBA.

Программное ядро CORBA разработано для всех основных аппаратных и программных платформ. Объекты приложений CORBA, используя в качестве посредника ПО CORBA, взаимодействуют с другими объектами CORBA, используя для этого интерфейсы. Для поиска и организации взаимодействия объектов CORBA предназначено специальное ПО -- объектный брокер запросов и сетевой агент Smart Agent. В результате клиентские и серверные приложения CORBA, работающие на платформе Wintel, одинаково легко взаимодействуют с аналогичными приложениями CORBA, откомпилированными для операционных систем UNIX или AS400.

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

Основу архитектуры CORBA составляет объектный брокер запросов VisiBroker for C++ ORB V 3.3.2, который управляет взаимодействием клиентов и серверов в распределенной сетевой среде. Взаимодействие со средой и приложениями Delphi обеспечивает дополнительная библиотека orbpas50.dll.

Кроме ORB, набор программных средств, обеспечивающих работоспособность приложений CORBA, которые разрабатываются в Delphi, включает:

Basic Object Adaptor (BOA) -- служба, обеспечивающая регистрацию приложения-сервера в распределенной сетевой среде.

Smart Agent -- распределенная служба, обеспечивающая предоставление информации о запущенных в сетевой среде серверах CORBA.

Object Activation Daemon (OAD) -- специальное ПО, обеспечивающее автоматический запуск сервера CORBA (если он еще не запущен) при обращении к нему клиента CORBA.

Интерфейс

[2]Интерфейс в CORBA - это логически сгруппированный набор методов и атрибутов. Каждому интерфейсу присваивается имя, уникальное в пределах одной распределенной системы. В отличие от СОМ в CORBA нет бинарного стандарта интерфейсов. Вместо этого существует стандартный язык описаний IDL. Так уж получилось, что языки с названием IDL существуют в трех различных технологиях - OSF/DCE, Microsoft/COM и OMG/CORBA. Эти языки во многом похожи, поскольку предназначены для одного и того же, но OMG/IDL несколько отличается от своих «однофамильцев».

За его основу был взят язык C++, поэтому нам студентам, знакомым с C++, при работе с IDL будет достаточно удобно пользоваться данной технологией.

Сервант

Чтобы использовать CORBA-объект в конкретной программе недостаточно создать его или даже установить с ним связь. Функциональность CORBA-объекта недоступна для клиента до тех пор, пока в программе не создан объект, который позволяет получить доступ к методам, объявленным в IDL-интерфейсе. Этот объект (реализованный на C++, Java, C, Cobol, Ada, Smalltalk или некоторых других языках) и называется «сервантом».

В зависимости от используемого языка программирования, серванты реализуются по-разному. Для объектно-ориентированных языков сервант является экземпляром (instance) некоторого класса, методы которого реализуют нужную функциональность. Такой класс часто называют «классом реализации».

За время существования CORBA-объекта с ним может быть сопоставлено множество различных реализаций сервантов (но не более одного за раз). Более того, они могут содержаться в адресном пространстве различных приложений. Эти приложения могут быть даже запущены на различных компьютерах.

Можно сказать, что сервант является «инкарнацией» CORBA-объекта. Связь между сервантами и CORBA-объектами является хотя и строго формализованной, но очень гибкой. Сервант может быть создан раньше или позже CORBA-объекта; один сервант может «обслуживать» как один, так и несколько CORBA-объектов. Явное разделение циклов жизни CORBA-объектов и их сервантов (а именно серванты потребляют реальные ресурсы) - один из столпов, на которых базируется очень высокая масштабируемость CORBA-приложений.

Объектная ссылка

Единственная сложность, возникшая у меня с пониманием смысла термина «объектная ссылка», это то, что он используется в двух различных смыслах.

В понимании относительно данной технологии, объектная ссылка представляет собой закодированную информацию о CORBA-объекте. Она включает имя хоста, порта TCP/IP, так же уникальный идентификатор данного CORBA-объекта и множество другой информации, позволяющей клиенту установить связь с серверным объектом через границы языков программирования, операционных систем и аппаратных платформ. Операции с объектной ссылкой невозможны для клиента, за исключением того, что клиент может превратить ее в строку и записать в файл или базу данных. Впоследствии кто угодно может считать такую строку и преобразовать ее опять в объектную ссылку.

Во втором случае объектная ссылка - это переменная того или иного языка программирования, благодаря которой клиент осуществляет вызов удаленных методов.

Концептуально переменная типа «объектная ссылка» является указателем на так называемый «proxy-объект», который существует на стороне клиента и обеспечивает выполнение удаленных вызовов. Сам proxy-объект сделан недоступным для программиста; связано это с тем, что его создание - задача не клиентского приложения, а самого ORB'а. Логически с каждым proxy-объектом сопоставлена отдельная объектная ссылка, и под копированием объектной ссылки следует понимать создание как нового proxy-объекта, так и настроенного на него нового «указателя». Разумеется, в реальных реализациях физического копирования proxy-объекта не происходит - как всегда в таких случаях, используется механизм счетчика ссылок.

Очень важно отчетливо понимать, что копирование (или уничтожение) объектных ссылок на стороне клиента влияет исключительно на клиентское приложение. Неправильное ведение счетчика ссылок в самом худшем случае приведет к продолжению физического существования в клиентском приложении ненужного proxy-объекта. Никакого отношения к серверному объекту эти действия не могут иметь в принципе. И создание, и уничтожение сервантов или серверных CORBA-объектов - задача серверного приложения. Философия CORBA состоит в том, чтобы клиент посылал сообщения «установить связь с существующим объектом» и «разорвать с ним связь», а не «создать серверный объект» и «уничтожить его». Разумеется, клиент может инициировать создание Corba-объектов вызвав у удаленного объекта специально предусмотренный для этого программистом (автором объекта) метод.

Создание простейшего объекта и его использование

[3]Как ни важно понимание теоретических аспектов CORBA, все же пример использования во многих случаях способен сказать больше, чем самые пространные рассуждения. В качестве демонстрации этапов создания CORBA-приложения напишем простейший пример. Сервер создает объект, реализующий операцию сложения двух целых чисел. Клиент устанавливает связь с серверным объектом, а затем вызывает этот его единственный метод, выводя результат на экран. В примере используется язык C++.

Первый этап создания CORBA-приложения - написание всех необходимых IDL-деклараций. В нашем случае IDL-код может выглядеть так:

interface MyInterface {

long Summa (in long op1, in long op2);

};

Следующий шаг - это генерация файлов на стороне клиента и сервера с помощью компилятора idl2cpp. В качестве входа компилятор получает список idl-файлов. В нашем случае это единственный файл, содержащий вышеприведенное описание. Для файла с именем, например, SimpleIDL.idl будут сгенерированы файлы SimpleIDL_c.hh, SimpleIDL_c.cpp (для использования на стороне клиента) и SimpleIDL_s.hh, SimpleIDL_s.cpp .

Создание серверного приложения

[4]Файлы _s.* содержат код, который позволяет связать серверное приложение с CORBA. Для нас наибольший интерес представляет сгенерированный класс POA_MyInterface. Этот класс содержит объявление чисто виртуальной (абстрактной) функции Summa:

class POA_MyInterface : ...

{

public:

...

virtual CORBA::Long Summa(CORBA::Long _op1,

CORBA::Long _op2)

throw(CORBA::SystemException) = 0;

...

};

Поскольку класс POA_MyInterface является только основой для серверного приложения, его часто называют «скелетом» или даже «скелетоном» (skeleton).

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

class MyInterfaceImpl : public POA_MyInterface

{

public:

MyInterfaceImpl () {}

CORBA::Long Summa(CORBA::Long _op1,

CORBA::Long _op2)

throw(CORBA::SystemException);

};

CORBA::Long MyInterfaceImpl::Summa(CORBA::Long _op1,

CORBA::Long _op2)

throw(CORBA::SystemException)

{

return _op1 + _op2;

}

Класс реализаций MyInterfaceImpl часто создается автоматически, например, с помощью экспертов, входящих в состав Borland C++ Builder или Java Builder.

Теперь осталось написать код функции main():

#include <fstream.h>

#include <corba.h>

#include "MyInterfaceImpl.h"

#pragma argsused

main(int argc, char* argv[])

{

try

{

// Инициализация взаимодействия с CORBA

CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);

// Создание серванта будущего CORBA-объекта

MyInterfaceImpl* servant = new MyInterfaceImpl;

// Создание временного (transient)

// CORBA-объекта и получение объектной ссылки

CORBA::Object_ptr oRef = servant->_this();

// Преобразование объектной ссылки в строку

CORBA::String_var str = orb->object_to_string (oRef);

// Запись в файл

ofstream oref_file ("MyORef.ior");

oref_file.write (str, strlen(str)+1);

oref_file.close();

cout << "Waiting for client requests...";

// Цикл ожидания запросов клиентов

orb->run();

}

catch(const CORBA::Exception& e)

{

cerr << e << endl;

return(1);

}

return 0;

}

Некоторые пояснения. Создание серверного объекта с помощью метода _this() применяется довольно редко. Получаемый таким образом объект имеет совокупность характеристик, крайне затрудняющих его использование. В разделе, посвященном объектным адаптерам, будет рассказано, как создавать «нормальные» CORBA-объекты.

Результатом вызова метода _this() является объектная ссылка. Тип MyInterface определяет proxy-объект, MyInterface_ptr (или MyInterface_var) - указатель на него. Это первый вид объектной ссылки - на уровне приложения.

Вторая объектная ссылка - ссылка уровня ORB - появляется в результате ее преобразования к строке с последующей записью этой строки в файл. Вы можете ознакомиться с содержимым этого файла сразу после запуска серверного приложения.

Объектная ссылка записывается в файл, откуда ее может считать приложение-клиент. Разумеется, этот способ скорее демонстрирует принцип организации связи между клиентом и сервером, чем представляет какую-либо практическую ценность.

Обратите внимание на то, что одно и тоже приложение может быть как клиентом, так и сервером - CORBA в этом плане не накладывает никаких ограничений.

Управление объектами

Созданный в предыдущем примере объект (не сервант, а сам CORBA-объект) является объектом временным. Это означает, что он не может существовать дольше, чем существует компонент CORBA, который его создал. В рассмотренном примере этот компонент явно не присутствовал в программе, и такой способ создания CORBA-объекта часто называют «неявным». В реальных программах большинство CORBA-объектов создается другим путем. Данный раздел и посвящен рассмотрению связанных с этой темой вопросов.

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

Компонент CORBA, который отвечает за создание CORBA-объектов, их сервантов, поддерживает связь между ними и участвует в доставке вызова клиента нужному серванту, называется объектным адаптером.

Стандарт CORBA позволяет иметь и использовать несколько различных объектных адаптеров. В настоящее время существуют два стандартных объектных адаптера - BOA (Basic Object Adapter) и POA (Portable Object Adapter). Использование BOA признано устаревшим, так как это не позволяет обеспечить переносимость серверных CORBA-приложений, и мы о нем говорить не будем.

POA

В реальных CORBA-приложениях используется древовидная иерархия объектных адаптеров. В корне ее находится так называемый Root POA - объектный адаптер по умолчанию. Программист получает доступ к Root POA c помощью стандартного кода, используемого во многих случаях:

CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);

CORBA::Object_var rpObj =

orb->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

Приведем пример создания объекта с использованием myPOA. Как уже говорилось, с каждым CORBA-объектом нужно сопоставить «ключ» - идентификатор, который позволяет однозначно идентифицировать этот объект. Давайте зададим этот идентификатор явно. Для этого вызовем метод, который позволяет создать этот идентификатор на основе строки:8

PortableServer::ObjectId_var objID =

PortableServer::string_to_ObjectId ("MyObject");

Следующие две команды создают сервант, а затем и CORBA-объект с указанным ObjectID:

MyInterfaceImpl servant;

myPOA->activate_object_with_id (objID, &servant);

Наконец, для начала обработки запросов от клиента вы должны активизировать менеджер POA:

poaMngr->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

{

readonly 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 - для этого предусмотрены специальные команды.

Наконец, предусмотрен некий вспомогательный, но в некоторых случаях очень удобный режим - так называемый «сервант по умолчанию». Суть этого режима состоит в том, что программист явно создает один-единственный сервант и регистрирует его как сервант, который является инкарнацией всех CORBA-объектов. Вот пример ситуации, когда такой подход вполне оправдан: для взаимодействия с базой данных вы создаете сотни, тысячи или миллионы CORBA-объектов - по одному на каждую запись, а затем создаете один сервант, не имеющий своего состояния, который обслуживает все эти объекты. Состояние каждого CORBA-объекта просто извлекается из соответствующей записи базы данных.

Итак, возможные значения опции RequestProcessingPolicyValue:

§ USE_ACTIVATE_OBJECT_MAP_ONLY - разрешено только явное создание сервантов с помещением указателей на них в AOM;

§ USE_DEFAULT_SERVANT - режим использования серванта по умолчанию;

§ USE_SERVANT_MANAGER - использование либо Activation-режима (если опция ServantRetensionPolicyValue, см. ниже, имеет значение RETAIN), либо Location-режима (если ServantRetensionPolicyValue имеет значение NON_RETAIN).

§ Режим обеспечения соответствия между сервантами и CORBA-объектами (ServantRetensionPolicyValue). Возможные значения - RETAIN (сохранять информацию о серванте в Active Object Map) и NON_RETAIN (использовать вновь создаваемый сервант только один раз).

§ Использование потоков (ThreadPolicyValue). Возможные значения - ORB_CTRL_MODEL (использовать потоковую модель, определяемую ORB'ом) и SINGLE_THREAD_MODEL (один поток обслуживает все запросы клиентов к сервантам данного POA).

Установка связи между клиентом и серверным объектом

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

Еще раз напомним: в CORBA клиент считает, что все необходимые серверные объекты уже существуют, поэтому он (логически) всегда использует команду «найти» и никогда - команду «создать».

В CORBA применяются два основных стандартных способа, позволяющих сделать серверный объект доступным для клиента, то есть, передать клиенту объектную ссылку на этот объект. Один из этих способов связан с использованием Сервиса Имен (Naming Service), второй - Трейдер-Сервиса.

Кроме стандартных служб, многие производители разрабатывают и поставляют свои собственные средства поиска. Для VisiBroker'а таким средством является Location Service, который базируется на использовании Smart Agent. Поскольку VisiBroker является одной из самых распространенных реализацией ORB, мы кратко рассмотрим и этот способ - более того, мы именно с него и начнем в силу простоты его использования.

Использование сконструированных пользователем типов данных

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

§ CORBA поддерживает базовые типы данных (octet, short, unsigned short, long, unsigned long, long long, unsigned long long, fixed, float, double, long double, boolean, char, wchar, string, wstring, enum и any), так называемые «сконструированные» типы данных (массивы, структуры, объединения, последовательности и типы-значения) и объектные ссылки. Кроме того, поддерживаются «синонимы типов», которые создаются с помощью typedef (вряд ли читатель, не знающий C/C++, добрался до этого места, а остальным не нужно объяснять, что это такое).

§ Каждый из этих типов может быть описан на языке IDL.

§ С каждым типом сопоставлены метаданные, т.е. признак типа и дополнительная информация, вид которой зависит от конкретного типа Как метаданные, так и объекты любого типа могут быть созданы динамически, т.е. без помощи IDL.

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

Обращаем ваше внимание на то, что часть информации в каждом из разделов относится к CORBA вообще, а часть - только к отображению IDL на C++.

Имена при отображении на C++

Для увеличения переносимости C++-программ на разные платформы и операционные системы (на уровне исходного кода) вместо конкретных имен типов C++ - short, unsigned long, wchar_t, char*, bool и пр. - используются typedef-алиасы, например, CORBA::Short, CORBA::ULong, CORBA::WChar, CORBA::String_ptr, CORBA::Boolean. Использование typedef-алиасов при создании CORBA-программ существенно упрощает их разработку, особенно потому, что наряду с такими алиасами широко используются и вспомогательные классы, например, CORBA::String_var. Типы, имена которых заканчиваются на _var или _out, являются чрезвычайно полезными и удобными, хотя почти всегда можно обойтись и без них.

Типы _ptr не представляют ничего интересного - это просто typedef-синоним для указателя:

typedef unsigned long CORBA::ULong;

typedef CORBA::ULong* CORBA::ULong_ptr;

Совсем другое дело - _var-классы.

_var-классы

_var-классы являются чисто сервисными классами - если не хотите, можете их не использовать, но дело в том, что использовать их чрезвычайно удобно. Эти классы являются оболочками вокруг типов, описанных на IDL. В сущности, их можно рассматривать как «разумные» указатели (smart pointer) - эти классы выполняют освобождение занятых ранее ресурсов при их уничтожении или при выполнении операций присваивания. Приведем пример использования строк: один вариант - в классическом стиле C++, другой - с использованием _var-класса CORBA.

Стиль C++:

f(char* Stringarg1, char* Stringarg2)

{

char* str = new char[strlen(Stringarg1) + 1];

strcpy (str, Stringarg);

...

// утечка памяти

str = new char[strlen(Stringarg2) + 1];

strcpy (str, Stringarg2);

delete[] str; // не забудьте вызвать явно!

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

Следующая проблема гораздо более серьезна - вы должны освободить явно выделенную динамическую память, т.е. вызвать операцию delete.

Программистам на C++ хорошо известны различные приемы, которые позволяют решить данную проблему - например, использование классов auto_ptr<> и string из STL. Поскольку идея во всех таких подходах одна - «завернуть» указатель на защищаемый ресурс в некоторую оболочку, которая и выполняет все необходимые действия - то компилятор idl2cpp просто генерирует такую оболочку. Это и есть _var-класс. Имейте в виду - _var-классы способны управлять различными ресурсами, а не обязательно памятью. Например, они часто используются для правильного ведения счетчика ссылок.

С использованием класса CORBA::String_var, тот же пример можно записать так:

Стиль CORBA для C++:

CORBA::String_var str = CORBA::string_dup ("My string");

str = CORBA::string_dup ("My anither string");

Никакой утечки памяти здесь не будет: память, занятая в первой строке, будет автоматически освобождена как часть операции присваивания, а память, занятая во второй строке, будет освобождена деструктором класса CORBA::String_var.

Var-классы выполняют и другие очень полезные сервисные функции.

Строки

Строки CORBA бывают двух видов - «неограниченные» (unbounded) и «ограниченные» (bounded). Различие между ними состоит в том, что ограниченные строки не могут быть больше явно указанной длины. Хотя большинство реализаций отображения строк IDL на C++ игнорирует это различие, всегда следует иметь его в виду.

Синтаксис задания строк очень прост:

typedef string MyAliasForString;

typedef string<20> BoundedString_20;

typedef wstring MyAliasForWideString;

Использовать typedef в общем случае необязательно - все зависит от того, в каком месте IDL-файла появляются такие объявления.

Компилятор idl2cpp генерирует классические типы данных C++ - char* или wchar_t*, и, кроме того, объектные оболочки вокруг указателей - _var- и _out-классы. Out-классы удобно использовать при работе с методами, которые возвращают результат через список аргументов этого метода.

Некоторые особенности имеет управление динамической памятью для строк. Использование new и delete может (потенциально) привести к рассогласованию средств, используемых прикладным приложением и ORB'ом. Чтобы избежать этой проблемы, нужно использовать не new, а CORBA::string_alloc() или CORBA::string_dup(), и не delete, а CORBA::string_free().

Массивы

Под массивом в CORBA понимается классический массив - набор данных однотипных элементов, размер которого известен заранее и не может быть изменен. Если вам нужны массивы переменной длины, то нужно использовать так называемые «последовательности».

IDL-синтаксис определения массива:

typedef long MyLongArray[10][20];

Для массивов использование typedef обязательно.

Массивы IDL очень похожи на строки IDL тем, что компилятор idl2cpp превращает их в обычные массивы C++. Как и для строк, для массивов генерируются вспомогательные классы-оболочки - _var- и _out, а также функции создания динамических массивов - имя_массива_alloc() и имя_массива_free(). Обе они не имеют аргументов - размер массива известен на стадии компиляции IDL-файла.

Обработка ошибок

Обработка ошибок - один из важнейших аспектов любой технологии программирования. Все современные системы и языки используют варианты одной модели, которая называется «обработка исключительных ситуаций с завершением». С ней хорошо знакомы программисты на C++, Java или Delphi. Кстати, термин «с завершением» в ее названии не значит, что программа будет завершена - просто в общем случае продолжить выполнение с той точки, где была возбуждена исключительная ситуация, невозможно.

Язык IDL позволяет программисту определить свои типы исключительных ситуаций и объявить, что тот или иной метод возбуждает некоторые из них:

exception MyException_1 {};

exception MyException_2

{

long code;

string description;

};

interface MyInterface

{

void MyMethod_1 ();

void MyMethod_2 () raises (MyException_1);

void MyMethod_1 () raises (MyExcpetion_1,MyException_2);

};

При отображении на C++ все происходит довольно естественным образом. Для исключений генерируются отдельные классы, и вы просто «отлавливаете» соответствующий тип исключения в операторе catch.

Впрочем, у системы обработки ошибок CORBA есть один серьезный недостаток - в ней не поддерживается наследование исключений. Другими словами, все ваши исключения совершенно не зависят друг от друга. Ничего не поделаешь - CORBA готова поддерживать языки без встроенной системы обработки исключений.

Кроме исключений, определенных пользователем, в CORBA существует около тридцати так называемых «системных исключений». Вы не должны включить ни одно из них в raises-список вашего метода, да в этом и нет необходимости - считается, что любой удаленный метод способен возбуждать любые системные исключительные ситуации.

Системные исключения имеют одну очень интересную особенность - они в качестве поля содержат признак того, произошло ли исключение ДО выполнения каких-либо действий на стороне сервера, или оно произошло уже ПОСЛЕ.

При отображении на C++ все классы исключений пользователя являются производными от стандартного класса CORBA::UserException, а все системные - от CORBA::SystemException, так что вы можете немного систематизировать обработку исключений.

Устойчивость к сбоям

Обеспечение устойчивости к сбоям - довольно слабое место CORBA с той точки зрения, что в настоящий момент оно слабо формализовано на уровне стандарта. Вследствие этого, в CORBA существуют отдельные фрагменты, но не комплексная система обеспечения такой устойчивости. Конечно, различные поставщики программного обеспечения предлагают те или иные решения , но они не являются переносимыми и не носят системного характера.

Существует документ, в котором намечены основные направления комплексной системы обеспечения устойчивости к сбоям, но ее доводка и реализация, видимо, займет немало времени.

Из сказанного не следует, что CORBA не обеспечивает некоторого уровня устойчивости. Его основой является явное отсутствие жесткой связи между клиентами и серверами. Сбой на клиенте крайне слабо отражается на состоянии сервера. Это означает, что проблемы на линиях связи или клиентских местах - это проблема отдельного клиента, а не снижение уровня работоспособности системы в целом.

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

Для решения клиентских проблем обычно применяется резервирование серверных объектов и серверов приложений. В CORBA эти подходы также оговорены, по крайней мере, на уровне концепции: клиент, в общем случае, не знает, и знать не должен, где находятся нужные ему серверные объекты. Крайне досадным обстоятельством является отсутствие качественных реализаций Сервиса Долговременного Хранения, который должен обеспечить прозрачное для разработчика сохранение состояния CORBA-объектов в долговременных хранилищах. Наличие такой реализации позволило бы выполнять автоматическое перенаправление вызовов клиентов к различным копиям объектов с состоянием. Впрочем, многие эксперты считают, что такая задача не решается вне рамок компонентной модели CORBA.

Повысить жизнеспособность распределенной системы может служба асинхронного обмена сообщениями. На сегодняшний день существует вариант конкретного решения, но он еще не утвержден OMG.

Вывод

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

-обеспечение функционирования систем в условиях информационной и реализационной неоднородности, распределенности и автономности информационных ресурсов;

-интеграция систем;

-реинженерия систем;

-миграция унаследованных систем;

-повторное использование неоднородных информационных ресурсов;

-продление жизненного цикла систем.

Применение данной открытой, независимой от постав-щика архитектуры и инфраструктуры, позволяющей использовать различные приложения для совместной работы в сетях, является весьма приемлемым для решения и разработки интересующих нас задач.

Четкая и основательная проработанность стандартов, их публичная доступность еще на этапе разработки и независимость от операционной среды в широком смысле слова, позволили CORBA стать, без преувеличения, одним из тех источников подходов и стандартов, на которых строится современное масштабируемое программное обеспечение.

Список использованных источников

1. Аншина М. Симфония CORBA. «Открытые системы» №3 1998 г.

2. Ахтырченко К. В., Леонтьев В. В. Распределенные объектные технологии в информационных системах. «СУБД» №5-6 1997 г.

3. Брюхов Д.О, Задорожный В.И, Калиниченко Л.А, Курошев М.Ю, Шумилов С.С Интероперабельные информационные системы: архитектуры и технологии. «СУБД» №4 1995 г.

4. Елманова Н. Распределенные вычисления и технологии Inprise. «Комьютер-Пресс» №1-5 1999 г.

5. Елманова Н. Оптимизация приложений С++Builder в архитектуре клиент/сервер. «Компьютер-Пресс» №4 1998 г.

6. Коржов В. Многоуровневые системы клиент-сервер. «Сети» №6 1997 г.

7. Орфали Р., Харкин Д., Эдвардс Д. Основы CORBA: Пер. с англ. - М.: МАЛИП, Горячая Линия - Телеком, 1999 г.

8. Калиниченко Л.А., Когаловский М.Р. Стандарты OMG: Язык определения интерфейсов IDL в архитектуре CORBA. «СУБД» №2 1996 г.

9. Калиниченко Л.А., Когаловский М.Р. Интероперабельность брокеров в стандарте CORBA 2.0. «СУБД» №3 1996 г.

Размещено на Allbest.ru