CORBA как технология

Введение

В настоящее время совершается переход от статичной централизованной структуры информационных систем (ИС) к динамичной гибкой структуре, основанной на системах получения и обработки информации, построенных с помощью современных технологий и распределенных в вычислительных сетях компонент. К таким технологиям относятся, например, J2EE, .NET и CORBA.

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

Актуальность и недостаточная разработанность вышеназванных проблем послужили основанием для рассмотрения данной темы.

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

Предметом исследования является назначение и функциональные возможности технологии CORBA.

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

Для достижения поставленной цели необходимо решить следующие задачи:

– рассмотреть историю появления технологии CORBA;

– рассмотреть архитектуру технологии CORBA;

– выделить ключевые моменты языка IDL;

– рассмотреть порядок действий при создании CORBA-системы;

– выделить преимущества и недостатки технологии CORBA.

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

Использование методов позволило обеспечить достоверность и обоснованность выводов.

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

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

В первой главе ставятся на рассмотрение основы технологии CORBA.

Во второй главе анализируются особенности создания CORBA-систем.

В заключении приводятся выводы по проведенному исследованию.

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

Основное внимание при написании работы уделялось следующим литературным источникам:

1. Дирк Слама, Джейсон Гарбис, Перри, Рассел. Корпоративные системы на основе CORBA: Уч.пос. / Пер. с англ. - М.: Издательский дом «Вильямс», 2000. - 368с.
2. Карпеев Д. О. Технология построения защищенных распределенных приложений: учеб. пособие [Электронный ресурс]. – Электрон. текстовые, граф. данные (1,26 Мб) / Д. О. Карпеев, С. С. Куликов. – Воронеж: ФГБОУ ВПО «Воронежский государственный технический университет», 2015.
3. Моргунов А. Ф. Информационные технологии в менеджменте: учебник для СПО / А. Ф. Моргунов. – М.: Издательство Юрайт, 2018. – 266 с. – (Серия: Профессиональное образование)
4. Свистунов А.Н. Построение распределенных систем на Java: учебное пособие / А.Н. Свистунов. — М.: Интернет-Университет Информационных Технологий: БИНОМ. Лаборатория знаний, 2011. – 279 с: ил., табл. – (Основы информационных технологий).
5. Схиртладзе А. Г. Проектирование единого информационного пространства виртуальных предприятий: учебник / А. Г. Схиртладзе, А. В. Скворцов, Д. А. Чмырь. – Изд. 2-е, стер. – М.; Берлин: Директ-Медиа, 2017. – 616 с.: ил.

Приведенная литература является надежными источниками информации в связи с тем, что она утверждена для использования в ВУЗах.

В данной работе эта литература послужила основным источником сведений по теме работы, так как содержит наиболее полное описание информации по теме исследования, материал авторами подается конкретно по теме.

1 Основы технологии CORBA

1.1 История появления технологии

В начале 1990-х гг. были проблемы обеспечения возможности общения программ, выполняемых на разных машинах, особенно, если использовались разные аппаратные средства, операционные системы и языки программирования: либо программисты использовали сокеты и сами реализовывали весь стек протоколов, либо их программы вовсе не взаимодействовали.

Для решения данной проблемы в 1989 г. был создан консорциум OMG (Object Management Group), основной задачей которого стала разработка и продвижение объектно-ориентированных технологий и стандартов. Это некоммерческое объединение, разрабатывающее стандарты для создания корпоративных платформо-независимых приложений.

Концептуальной инфраструктурой, на которой базируются все спецификации OMG, является Object Management Architecture (OMA). В состав OMA входят разнообразные стандартизованные или в настоящий момент стандартизируемые OMG службы, сервисы, программные образцы и шаблоны (CORBAservices, horizontal and vertical CORBAfacilities), язык определения интерфейсов распределенных объектов IDL (Interface Definition Language), стандартизованные или стандартизируемые отображения IDL на языки программирования и, наконец, объектная модель CORBA.

Главной особенностью CORBA является использование компонента ORB (Object Resource Broker – брокер ресурсов объектов) для создания экземпляров объектов и вызова их методов. Данный компонент формирует «мост» между приложением и инфраструктурой CORBA (рисунок 1).

Рисунок 1 - Основные понятия технологии CORBA

В 1997 г. консорциум OMG опубликовал спецификацию CORBA 2.0. В ней определялись стандартный протокол и отображение для языка C++, а в 1998 г. было определено отображение для Java. В результате разработчики получили инструментальное средство, позволяющее им относительно легко создавать неоднородные распределенные приложения.

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

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

1.2 Архитектура CORBA

На рисунке 2 изображен запрос, посылаемый клиентом реализации объекта. Клиент — это сущность, которая хочет выполнить операцию с объектом, а Реализация – это совокупность кода и данных, которые в действительности реализуют объект.

Рисунок 2 - Клиент посылает запрос реализации объекта

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

На рисунке 3 изображена структура брокера объектных запросов. Его интерфейсы показаны на рисунке штрихованными прямоугольниками, стрелки обозначают, вызывается ли брокер или сам выполняет вызов.

Рисунок 3 - Интерфейсы брокера объектных запросов

Чтобы сделать запрос, Клиент может использовать Динамический интерфейс вызова (Dynamic Invocation Interface),один и тот же, вне зависимости от интерфейса целевого объекта, или IDL заглушку (stub),специфичную для интерфейса целевого объекта. Клиент также может напрямую взаимодействовать с брокером для получения некоторых функций.

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

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

Для выполнения запроса клиент должен иметь доступ к объектной ссылке (IOR-Interoperable Object Reference), знать тип объекта и ту операцию, которую он хочет выполнить. Клиент инициирует запрос, вызывая подпрограммы заглушки, специфичные для конкретного объекта, или создавая запрос динамически (рисунок 4).

Рисунок 4 - Клиент выполняет запрос (динамически или через заглушку)

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

Рисунок 5 - Реализация объекта получает запрос

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

Рисунок 6 - Репозитории интерфейсов и реализаций

Информация о реализации объекта предоставляется во время инсталляции и хранится в репозитории реализации, а затем используется в процессе доставки запроса.

1.2.1 Брокер объектных запросов (ORB)

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

1.2.2 Клиенты

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

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

1.2.3 Реализации объектов (Object implementation)

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

1.2.4 Объектные ссылки (IOR)

Объектная ссылка – это информация, необходимая для определения конкретного объекта внутри ORB. Как для клиента, так и для реализации объектная ссылка представляется так, как диктует связывание соответствующего языка программирования, таким образом, они изолированы от конкретного представления ссылки.

Объектная ссылка, переданная клиенту, действительна только на время жизни клиента. Различные брокеры должны предоставлять одно и то же представление объектной ссылки для данного языка программирования (это позволяет одной и той же программе получать доступ к объекту по ссылке независимо от используемого брокера). Кроме того, для удобства брокер может предоставлять другие способы доступа к объекту. Существует особенная объектная ссылка, не указывающая ни на один объект.

1.2.5 Язык описания интерфейсов (IDL)

Язык IDL определяет типы объектов путем спецификации их интерфейсов. Интерфейс состоит из списка операций и их параметров. Несмотря на то, что IDL предоставляет каркас для описания объектов, которыми манипулирует ORB, нет необходимости в том, что брокер имел доступ к исходному коду на IDL. Брокер может работать с эквивалентной информацией в виде заглушек подпрограмм и репозитория интерфейсов.

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

1.2.6 Связывание языков программирования с IDL

Различные объектно-ориентированные и не объектно-ориентированные языки программирования могут получать доступ к CORBA-объектам по-разному. Для объектно-ориентированных языков, скорее всего, предпочтительно видеть CORBA-объекты как объекты языка программирования. И даже для не объектно-ориентированных языков скрытие фактического представления объектных ссылок и методов внутри брокера представляется удобным. Связывание того или иного языка программирования с IDL должно быть одинаковым для всех реализаций ORB. Связывание языка включает определение специфичных для языка типов данных и интерфейсов процедур для доступа к объекту через ORB. Оно включает структуру интерфейса клиентской заглушки (для объектно-ориентированных языков не обязательно), интерфейс динамического вызова, скелетон реализации, объектные адаптеры и интерфейс для обращения напрямую к брокеру.

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

1.2.7 Клиентские заглушки (client stubs)

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

1.2.8 Динамический интерфейс вызова (Dynamic invocation)

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

1.2.9 Скелетон реализации (Server skeleton)

Для каждого конкретного связывания языка программирования и, возможно, в зависимости от конкретного объектного адаптера, будет создан определенный интерфейс к методам, реализующим некоторый тип объектов. При этом реализация объекта предоставляет подпрограммы, удовлетворяющие интерфейсу, а ORB вызывает эти подпрограммы через скелетон.

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

1.2.10 Динамический интерфейс скелетона

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

Динамические скелетоны могут быть вызваны как клиентскими заглушками, так и динамическим интерфейсом вызова на стороне клиента, причем результат должен быть одинаковым.

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

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

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

1.2.12 Интерфейс ORB

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

1.2.13 Репозиторий интерфейсов

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

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

1.2.14 Репозиторий реализаций

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

Репозиторий реализаций используется также для хранения дополнительной информации, связанной с реализациями объектов (отладочная информация, административный контроль, выделение ресурсов, безопасность и т.д.).

Выводы по 1 главе.

В начале 1990-х гг. были проблемы обеспечения возможности общения программ, выполняемых на разных машинах. Для решения данной проблемы в 1989 г. был создан консорциум OMG, основной задачей которого стала разработка и продвижение объектно-ориентированных технологий и стандартов.

Главной особенностью CORBA является использование компонента ORB (Object Resource Broker – брокер ресурсов объектов) для создания экземпляров объектов и вызова их методов.

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

2 Особенности создания CORBA-системы

2.1 Основы языка IDL

Для описания синтаксиса языка в спецификациях стандарта CORBA используется нотация, аналогичная EBNF (Extended Backus-Naur Format – Расширенный формат Бэкуса-Наура).

::= – является по определению

| – или

< > – нетерминальный символ, представляемый заключенным в скобки понятием

«текст» – литерал

* – возможность повторения предшествующей синтаксической конструкции нуль или более раз

+ – возможность повторения предшествующей синтаксической конструкции один или более раз

{ } – заключенные в скобки синтаксические конструкции рассматриваются как единая конструкция

[ ] – заключенная в скобки синтаксическая конструкция является необязательной.

При отображении IDL в различные языки программирования CORBA требует, чтобы конструкции IDL были адекватно отображены:

– все базовые и конструируемые типы;

– ссылки на объекты и константы, определяемые в IDL;

– вызовы операций;

– исключительные ситуации;

– доступ к атрибутам;

– сигнатуры операций в виде, определенном ORB (интерфейс динамического вызова).

Реализация отображения дает возможность программисту иметь доступ ко всем функциям ORB в виде, удобном для соответствующего языка программирования. Все реализации ORB должны следовать стандарту OMG отображения для конкретного языка программирования.

Язык определения IDL позволяет независимо от используемого языка программирования создать универсальное описание интерфейса будущей системы (рисунок 7).

Рисунок 7 - Пример описания интерфейса на языке IDL

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

2.2 Порядок действий при создании CORBA-системы

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

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

Добиться хороших результатов в создании программ на основе CORBA можно, придерживаясь определенного порядка действий:

– объектно-ориентированный анализ и моделирование;

– описание и трансляция объектов;

– создание сервера;

– создание клиента;

– отладка объектов.

1) Объектно-ориентированный анализ и моделирование.

CORBA – объектно-ориентированная технология, потому в первую очередь необходимо осуществить объектную декомпозицию и представить систему в виде взаимодействующих между собой классов. Чтобы модель была понятна и разработчикам, нужно задокументировать ее. Построить IDL-описания по UML-модели поможет пакет Rational Rose.

2) Описание и трансляция интерфейсов.

Готовая модель системы содержит классы, которые должны быть описаны с помощью языка IDL. Далее это описание можно транслировать с помощью IDL-компилятора в базовые исходные тексты на конкретном языке программирования (заглушки и скелетоны) или добавить IDL-описания в репозиторий интерфейсов.

3) Создание сервера.

Сервер – это программа, предоставляющая некий сервис, удаленные объекты в случае с CORBA. Серверы CORBA могут активизироваться самостоятельно, будучи запущенными системным администратором либо при загрузке операционной системы. Также программист может зарегистрировать серверы CORBA с помощью утилит, после чего специальный демон будет отслеживать входящие запросы программ-клиентов и активизировать нужные серверы автоматически. Для этой цели в VisiBroker for C++ имеется OAD (Object Activation Daemon), в VisiBroker for Java – OADJ.

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

Рисунок 1 - Процесс работы типичного CORBA-сервера

Инициализация ORB нужна для создания коммуникационного канала между клиентом и объектами.

Объектный адаптер в CORBA играет особую роль. Это, по сути, координатор действий. Если ORB не отличается интеллектом и просто выполняет транспортные функции, то объектный адаптер занимается сложной работой по запуску и экспорту объектов, а также заведует информацией, хранящейся в репозитарии реализаций (implementation repository) – специальном хранилище данных, которым пользуется демон активизации объектов. Если сравнивать ORB с системной шиной компьютера, то объектный адаптер нечто вроде драйвера платы расширения.

В спецификации CORBA упоминаются два типа объектных адаптеров — основной (BOA) и переносимый (POA).

4) Создание клиента.

Приложение, выполняющее роль клиента для объекта, намного проще, чем сервер. Хотя и для него установлена некоторая последовательность действий:

– инициализация ORB;

– получение ссылки на экземпляр CORBA-объекта;

– использование объекта.

2.3 Преимущества и недостатки технологии CORBA

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

Первый, самый очевидный плюс – это кроссплатформенность и независимость от языка. Можно собрать множество программистов и написать распределённую систему, которая будет работать под несколькими ОС одновременно, и при этом каждый программист сможет создавать её составные части на том языке программирования, который знает лучше всего.

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

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

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

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

Выводы по 2 главе.

Для описания синтаксиса языка в спецификациях стандарта CORBA используется нотация, аналогичная EBNF.

Язык определения IDL позволяет независимо от используемого языка программирования создать универсальное описание интерфейса будущей системы.

Добиться хороших результатов в создании программ на основе CORBA можно, придерживаясь определенного порядка действий: объектно-ориентированный анализ и моделирование; описание и трансляция объектов; создание сервера; создание клиента; отладка объектов.

Как и любая технология, CORBA имеет преимущества и недостатки. Несмотря на наличие недостатков, данную технологию продолжают успешно применять на практике.

Заключение

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

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

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

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

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

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

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

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

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

Список использованной литературы

1. Абрамов М. В., Шек В. М. Трехуровневая архитектура современных информационных систем // ГИАБ. 2003. №4. URL: https://cyberleninka.ru/article/n/trehurovnevaya-arhitektura-sovremennyh-informatsionnyh-sistem.
2. Аралин В.Н., Щербаков П.Д., Кирносенко С.И. Построение модульной системы автоматизации спектрографических экспериментов с использованием современных архитектур // Приволжский научный вестник. 2016. №2 URL: https://cyberleninka.ru/article/n/postroenie-modulnoy-sistemy-avtomatizatsii-spektrograficheskih-eksperimentov-s-ispolzovaniem-sovremennyh-arhitektur.
3. Ахаян Р. А. Macromedia ColdFusion: Пособие / Ахаян Р.А. - СПб:БХВ-Петербург, 2014. - 651 с.
4. Ахтырченко К. В. Применение технологии CORBA при построении распределенных информационных систем // СУБД. -1998. – № 1-2.
5. Ахтырченко К.В., Аристархов A.A. Опыт применения технологий CORBA, Java(RMI) при построении информационных систем с многозвенной архитектурой. М.: Научно-исследовательский вычислительный центр МГУ.
6. Баранова И. В., Майоров С. В. Формирование цифровой среды инновационно-ориентированной кластерной структуры // Вопросы инновационной экономики. 2017. №3. URL: https://cyberleninka.ru/article/n/formirovanie-tsifrovoy-sredy-innovatsionno-orientirovannoy-klasternoy-struktury.
7. Будилов В. А. Основы программирования для Интернета. – Спб.: БХВ-Петербург, 2003. – 736 с.: ил.
8. Букатов А. А., Шапиро В. А., Шаройко О. В. Технологические аспекты построения распределенных информационных и управляющих систем // Известия ЮФУ. Технические науки. 2002. №2. URL: https://cyberleninka.ru/article/n/tehnologicheskie-aspekty-postroeniya-raspredelennyh-informatsionnyh-i-upravlyayuschih-sistem.
9. Влацкая И. В., Сормов С. И. Управление и обработка информации в распределенных системах // Вестник ОГУ. 2010. №4 (110). URL: https://cyberleninka.ru/article/n/upravlenie-i-obrabotka-informatsii-v-raspredelennyh-sistemah.
10. Горбачевская Е. Н., Трубачев Е. С. Реализация информационной безопасности по технологии corba в корпоративных информационных системах // Вестник ВУиТ. 2012. №4 (20). URL: https://cyberleninka.ru/article/n/realizatsiya-informatsionnoy-bezopasnosti-po-tehnologii-corba-v-korporativnyh-informatsionnyh-sistemah.
11. Дирк Слама, Джейсон Гарбис, Перри, Рассел. Корпоративные системы на основе CORBA: Уч.пос. / Пер. с англ. - М.: Издательский дом «Вильямс», 2000. - 368с.
12. Иванников В. П., Дышлевой К. В., Манжелей С. Г., Соловская Л. Б., Шебуняев А. Б. Распределенные объектно-ориентированные системы // Труды ИСП РАН. 2000. №. URL: https://cyberleninka.ru/article/n/raspredelennye-obektno-orientirovannye-sistemy.
13. Калайда В. Т., Петров А. А. Концепция распределенной вычислительной системы с децентрализованным управлением // Доклады ТУСУР. 2011. №1 (23). URL: https://cyberleninka.ru/article/n/kontseptsiya-raspredelennoy-vychislitelnoy-sistemy-s-detsentralizovannym-upravleniem.
14. Карпеев Д. О. Технология построения защищенных распределенных приложений: учеб. пособие [Электронный ресурс]. – Электрон. текстовые, граф. данные (1,26 Мб) / Д. О. Карпеев, С. С. Куликов. – Воронеж: ФГБОУ ВПО «Воронежский государственный технический университет», 2015.
15. Кеменов А. Ф. Целесообразность применения web-служб в распределенных автоматизированных системах военного назначения // Программные продукты и системы. 2005. №2. URL: https://cyberleninka.ru/article/n/tselesoobraznost-primeneniya-web-sluzhb-v-raspredelennyh-avtomatizirovannyh-sistemah-voennogo-naznacheniya.
16. Кусов А. А. Проблемы интеграции корпоративных информационных систем // УЭкС. 2011. №28. URL: https://cyberleninka.ru/article/n/problemy-integratsii-korporativnyh-informatsionnyh-sistem.
17. Машнин Т. С. Web-сервисы Java. – Спб.: БХВ-Петербург, 2012. – 560 с.: ил. – (Профессиональное программирование)
18. Моргунов А. Ф. Информационные технологии в менеджменте: учебник для СПО / А. Ф. Моргунов. – М.: Издательство Юрайт, 2018. – 266 с. – (Серия: Профессиональное образование)
19. Пачеко Ксавье Delphi for .NET. Руководство разработчика: Пер. с англ. – М.: Издательский дом «Вильямс», 2005. – 960 с.: ил. – Парал. тит. англ.
20. Прокопова Т. В. Тенденции развития технологий создания информационных систем // Статистика и экономика. 2007. №3. URL: https://cyberleninka.ru/article/n/tendentsii-razvitiya-tehnologiy-sozdaniya-informatsionnyh-sistem.
21. Свистунов А.Н. Построение распределенных систем на Java: учебное пособие / А.Н. Свистунов. — М.: Интернет-Университет Информационных Технологий: БИНОМ. Лаборатория знаний, 2011. – 279 с: ил., табл. – (Основы информационных технологий).
22. Схиртладзе А. Г. Проектирование единого информационного пространства виртуальных предприятий: учебник / А. Г. Схиртладзе, А. В. Скворцов, Д. А. Чмырь. – Изд. 2-е, стер. – М.; Берлин: Директ-Медиа, 2017. – 616 с.: ил.
23. Тёмкина Т. А. Эволюция технологий интеграции информационных систем // T-Comm. 2011. №7. URL: https://cyberleninka.ru/article/n/evolyutsiya-tehnologiy-integratsii-informatsionnyh-sistem.
24. Хенинг Дж. SPEC CPU2000: определение производительности в новом тысячелетии // Открытые системы. – 2000. – № 7-8.