Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Технология CORBA (Практическая реализация объектного адаптера)

Содержание:

Введение

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

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

Это стандарт, набор спецификаций для промежуточного программного обеспечения объектного типа, образующийся в результате самого широкого анализа аккумулированных реальных проблем, где принимают участие разработчики и потребители технологий [1, c.15]. По итогам данного обсуждения формируется документ, предлагающий решение исследуемых вопросов на базе присутствующих технологий и технологий ближайшей перспективы. Преимуществом опережающей разработки спецификации по сравнению с реализацией является возможность для независимых разработчиков формировать потенциально совместимые продукты, не ограничивая свободы выбора языков, операционных систем, аппаратных платформ, и не диктуя выбора определенного технологического решения.

Под термином CORBA подразумевается именно сложная и развитая концепция, образованная на уровне специального языка описаний – IDL. Реализации данной концепции способны значительно отличаться между собой по разнообразным признакам, значимых в той или иной ситуации. VisiBroker и Application Server, BEA WebLogic, Iona Orbix, Oracle Application Server и «картриджи» Oracle, IBM BOSS – данные продукты применяют какие-либо возможности CORBA [3, c.34].

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

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

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

Цель курсовой работы заключается в рассмотрении технологии CORBA.

Для реализации цели необходимо выполнить ряд задач, а именно:

- рассмотреть теоретические аспекты функционирования технологии CORBA;

- проанализировать практическую реализацию объектного адаптера.

Предметом исследования данной курсовой работы являются распределенные системы обработки информации.

Объектом исследования данной курсовой работы является технология CORBA.

Структура данной курсовой работы состоит из введения, двух глав, заключения, списка использованных источников.

1 Теоретические аспекты функционирования технологии CORBA

1.1 Описание технологии

Спецификация CORBA создана группой компаний Object Management Group и описывает базирующийся на объектах метод разработки распределенных приложений, т.е. как реализуется взаимодействие объектов клиента и сервера. После инсталляции специального программного обеспечения (далее – ПО) сервер приложений и клиенты способны взаимодействовать, применяя объекты и интерфейсы CORBA [5, c.72].

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

Соответственно, применение архитектуры 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 [9, c.18].

1.2 Интерфейс CORBA

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

Для применения CORBA-объекта в определенной программе недостаточно создать его или даже установить с ним связь. Функциональность CORBA-объекта недоступна для клиента до того момента, пока в программе не появится объект, дающий возможность получить доступ к методам, обозначенным в IDL-интерфейсе. Данный объект (реализованный на C++, Java, C, Cobol, Ada, Smalltalk или пр.) именуется «сервантом» [11, c.24].

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

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

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

Помимо всего прочего, интерес в технологии CORBA представляет объектная ссылка.

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

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

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

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

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

В данном подразделе целесообразно отразить пример применения технологии 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 [15, c.64].

Далее рассмотрим процесс разработки серверного приложения.

Файлы _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() используется нечасто. Создаваемый подобным образом объект обладает комплексом параметров, осложняющих его эффективное использование.

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

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

Объектная ссылка пишется в файл, откуда ее способно считать приложение-клиент. Данный способ скорее отражает принцип организации связи между клиентом и сервером, чем представляет какую-либо практическую ценность [17, c.39].

Необходимо помнить, что одно и тоже приложение способно являться как клиентом, так и сервером – CORBA в данном случае не определяет каких-либо ограничений.

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

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

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

2 Практическая реализация объектного адаптера

2.1 Описание РОА

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

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 [2, c.18].

Перед разработкой дочерних POA целесообразно образовать так называемый «менеджер» POA. Он несет ответственность за распределение клиентских запросов между сервантами, состоящими под управлением различных POA, а также за управление их (POA) циклом жизни. Фабрикой данного менеджера способен являться Root POA. При образовании дочерних объектных адаптеров необходимо указать менеджер POA в качестве аргумента. Если не был создан собственный менеджер, и вместо его имени при вызове метода создания POA был указан nil, то будет неявно создан и применен менеджер по умолчанию.

Процесс уничтожения объектных адаптеров осуществляется по установленному алгоритму – сперва дочерние POA, далее их «родители».

Теперь рассмотрим процесс создания объекта с применением РОА.

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

PortableServer::ObjectId_var objID =

PortableServer::string_to_ObjectId ("MyObject");

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

MyInterfaceImpl servant;

myPOA->activate_object_with_id (objID, &servant);

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

poaMngr->activate();

Практику, когда для каждого CORBA-объекта при запуске приложения образуется свой сервант, нельзя признать удачной – так можно потратить огромное количество ресурсов [4, c.72]. Разработчик способен образовывать CORBA-объекты и без создания сервантов. Сделать это несложно:

myPOA->create_reference_with_id(

objID, "IDL:MyInterface:1.0");

Сопоставить с таким объектом сервант можно позднее, причем разнообразными способами.

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

Рассмотрим, что происходит при временном объекте, созданного ранее с помощью вызова метода _this(). Объектная ссылка на этот объект, переданная клиенту через файл, включает имя хоста, на котором было запущено создавшее объект приложение, использованный порт TCP/IP, уникальный идентификатор объекта. Это свидетельствует о том, что клиент способен применять имеющуюся у него объектную ссылку лишь до тех пор, пока серверное приложение работает и в нем находится создавший объект объектный адаптер.

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

При применении долгоживущих объектов ситуация осложняется. Даже если объект разработан при помощи POA, необходимого для создания и управления persistent-объектами, это не значит, что после остановки серверного приложения клиент будет в состоянии вызвать удаленные методы по существующей объектной ссылке [6, c.76]. В простейшем случае каких-либо проблем не возникнет, если серверное приложение снова запущено «вручную» на том же хосте и с применением того же порта TCP/IP.

2.2 Свойства 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 (один сервант способен обслуживать несколько объектов) [6, c.81].

Режим разрешения неявной активации (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 вообще не поддерживается в таком режиме – а образует сервант для обслуживания пришедшего вызова и далее его уничтожает [10, c.61].

Процесс динамического создания сервантов состоит в том, что POA вызывает определенные написанные программистом функции. Естественно, данные функции нужно зафиксировать в POA – для такой ситуации предполагаются специальные команды.

Вместе с тем предусмотрен определенный вспомогательный, но в иногда очень удобный режим – «сервант по умолчанию». Смысл данного режима заключается в том, что программист явно создает один-единственный сервант и фиксирует его как сервант, являющийся инкарнацией всех CORBA-объектов. Например, для взаимодействия с базой данных программист создает сотни, тысячи или миллионы CORBA-объектов – по одному на каждую запись, а затем создает один сервант, не имеющий своего состояния, обслуживающий объекты в совокупности [10, c.75]. Состояние каждого 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).

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

После знакомства с объектными ссылками очевидно, что определение связи между клиентом и серверным объектом состоит в получении клиентом объектной ссылки на данный объект. Конечно, передача объектной ссылки через файл пусть и вероятна, но не способна считаться удобным и универсальным способом [12, c.82].

В CORBA используется 2 ключевых стандартных способа, дающих возможность сделать серверный объект доступным для клиента, т.е. передать клиенту объектную ссылку на данный объект. Один из таких способов касается применения Сервиса Имен (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 doublе и т.д.), так называемые «сконструированные» типы данных (массивы, структуры, объединения, последовательности и типы-значения) и объектные ссылки. Помимо всего прочего, поддерживаются «синонимы типов», образующиеся при помощи typedef.
  • Любой из данных типов может быть описан на языке IDL.
  • С каждым типом сравнены метаданные, т.е. признак типа и дополнительная информация, вид которой находится в зависимости от определенного типа. Как метаданные, так и объекты любого типа способны создаваться динамически, т.е. без помощи IDL.
  • Есть тип any, способный хранить данные любого типа [14, c.50].

Для увеличения переносимости 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 [16, c.80]. Поскольку идея во всех таких подходах одна – «завернуть» указатель на защищаемый ресурс в некоторую оболочку, которая и выполняет все необходимые действия – то компилятор 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++ игнорирует это различие, всегда следует иметь его в виду [16, c.94].

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

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().

2.4 Массивы

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

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

typedef long MyLongArray[10][20];

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

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

Обработка ошибок – один из важнейших аспектов любой технологии программирования. Все современные системы и языки используют варианты одной модели, которая называется «обработка исключительных ситуаций с завершением». С ней хорошо знакомы программисты на 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 существует около тридцати так называемых «системных исключений». Системные исключения имеют одну очень интересную особенность – они в качестве поля содержат признак того, произошло ли исключение ДО выполнения каких-либо действий на стороне сервера, или оно произошло уже ПОСЛЕ.

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

Таким образом, была достигнута цель курсовой работы – рассмотрена технология CORBA.

Для реализации цели был выполнен ряд задач, а именно:

- рассмотрены теоретические аспекты функционирования технологии CORBA;

- проанализирована практическая реализация объектного адаптера.

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

1. Акперов, И.Г. Информационные технологии в менеджменте: Учебник / И.Г. Акперов, А.В. Сметанин, И.А. Коноплева. - М.: НИЦ ИНФРА-М, 2013. - 400 c.

2. Барский, А.В. Параллельные информационные технологии: Учебное пособие / А.В. Барский. - М.: Бином, 2013. - 503 c.

3. Гаврилов, М.В. Информатика и информационные технологии: Учебник для прикладного бакалавриата / М.В. Гаврилов, В.А. Климов. - Люберцы: Юрайт, 2016. - 383 c.

4. Дарков, А.В. Информационные технологии: теоретические основы: Учебное пособие / А.В. Дарков, Н.Н. Шапошников. - СПб.: Лань, 2016. - 448 c.

5. Максимов, Н.В. Современные информационные технологии: Учебное пособие / Н.В. Максимов, Т.Л. Партыка, И.И. Попов. - М.: Форум, 2013. - 512 c.

6. Панов, А.В. Разработка управленческих решений: информационные технологии: Учебное пособие / А.В. Панов. - М.: ГЛТ, 2012. - 151 c.

7. Румянцева, Е.Л. Информационные технологии: Учебное пособие / Е.Л. Румянцева, В.В. Слюсарь; Под ред. Л.Г. Гагарина. - М.: ИД ФОРУМ, НИЦ ИНФРА-М, 2013. - 256 c.

8. Светлов, Н.М. Информационные технологии управления проектами: Учебное пособие / Н.М. Светлов, Г.Н. Светлова. - М.: НИЦ ИНФРА-М, 2012. - 232 c.

9. Советов, Б.Я. Информационные технологии: учебник для прикладного бакалавриата / Б.Я. Советов, В.В. Цехановский. - Люберцы: Юрайт, 2016. - 263 c.

10. Советов, Б.Я. Информационные технологии: теоретические основы: Учебное пособие / Б.Я. Советов, В.В. Цехановский. - СПб.: Лань, 2016. - 448 c.

11. Сырецкий, Г.А. Информатика. Фундаментальный курс. Том II. Информационные технологии и системы / Г.А. Сырецкий. - СПб.: BHV, 2012. - 848 c.

12. Трайнев, В.А. Новые информационные коммуникационные технологии в образовании: Информационное общество. Информационно-образовательная среда. Электронная педагогика. Блочно-модульное построение информационных технологий / В.А. Трайнев. - М.: Дашков и К, 2013. - 320 c.

13. Федотова, Е.Л. Информационные технологии и системы: Учебное пособие / Е.Л. Федотова. - М.: ИД ФОРУМ, НИЦ ИНФРА-М, 2013. - 352 c.

14. Хлебников, А.А. Информационные технологии: Учебник / А.А. Хлебников. - М.: КноРус, 2014. - 472 c.

15. Черников, Б.В. Информационные технологии управления: Учебник / Б.В. Черников. - М.: ИД ФОРУМ, НИЦ ИНФРА-М, 2013. - 368 c.

16. Ясенев, В.Н. Информационные системы и технологии в экономике: Учебное пособие / В.Н. Ясенев. - М.: ЮНИТИ, 2014. - 560 c.

17. Информационные системы и технологии управления: Учебник / Под ред. Г.А. Титоренко. - М.: ЮНИТИ, 2013. - 591 c.