Файл: Технология CORBA (Теоретические аспекты).pdf

Стиль 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().

2.4 Массивы

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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