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

Введение

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

В данной работе рассматривается одна из ведущих технологий создания распределённых систем – CORBA, предложенная крупнейшим в мире консорциумом разработчиков программного обеспечения Object Management Group (OMG). Представлено описание распределённой программной системы – машины удалённых запросов, разработанной на основе стандарта CORBA, в виде набора взаимодействующих объектных сервисов CORBA (CORBA Object Services).

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

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

Предмет исследования – создание распределенных приложений на основе технологии CORBA.

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

Целью работы является – рассмотреть некоторые вопросы разработки программного обеспечения на основе объектных моделей, необходимого для предварительного анализа и исправления ошибок в сочетании с CORBA.

Основными задачами данной работы являются:

• рассмотреть основные понятия и функции технологии CORBA;
• перечислить и охарактеризовать принципы и общую схему технологии CORBA.

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

1.1. Основные функции и задачи технологии CORBA

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

CORBA – это стандарт создания распределенных систем, предложенный консорциумом разработчиков программного обеспечения Object Management Group (OMG), который затрагивает все вопросы, имеющие отношение к этой проблеме^[1].

Слово CORBA, является, аббревиатурой от Common Object Request Broker Architecture (стандартная архитектура брокера объектных запросов), что, по словам самих разработчиков OMG, обозначает «открытую, не зависимую от поставщика архитектуру и инфраструктуру, позволяющую использовать различные приложения для совместной работы в сетях. Используя стандартный протокол IIOP, CORBA – приложения, разработанные любым производителем программного обеспечения, работающие практически на любой аппаратной платформе, операционной системе или сети, могут взаимодействовать с другими CORBA-приложениями того же или другого поставщика также на практически любой платформе, операционной системе или сети, созданными с использованием самых различных языков программирования».

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

Стандарт CORBA исчерпывающе описывает взаимодействие между приложениями на основе объектных интерфейсов. Основой совместимости CORBA-приложений является ORB. Приложение с помощью ORB может предоставлять во внешний мир объектный интерфейс, структура которого описана с помощью языка описания интерфейса IDL (Interface Definition Language), а также обращаться к другим приложениям, совместимым с CORBA, через предоставленный этими приложениями объектный интерфейс. Таким образом, приложение может служить как сервером (в традиционном смысле этого слова), и как клиентом, как одновременно, так и по отдельности^[2].

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

На основе данного описания интерфейса, ORB первого приложения, строит необходимую инфраструктуру, позволяющую обращаться к объектам других приложений, как будто эти объекты являются объектами данного приложения. При этом, если ORB взаимодействующих приложений стандартны и поддерживают общий протокол обмена, их взаимодействие не зависимо от языка программирования, на котором приложения написаны^[3].

Именно протокол обмена диктует, насколько далеко могут быть разнесены общающиеся между собой приложения, совместимые с CORBA. Приложения могут выполняться в одном адресном пространстве (в виде, например, подключаемых библиотек), либо на одном компьютере, в многозадачной среде, либо на разных компьютерах, общаясь через сеть^[4].

Стандарт определяет протоколы GIOP (General Inter- ORB Protocol), который описывает пакетный способ общения и является основой других пакетных протоколов, IIOP (Internet Inter-ORB Protocol) – пакетный протокол, основывающийся на GIOP и предназначенный для использования в сетях на основе протокола TCP/IP, и другие протоколы. Кроме определения правил взаимодействия приложений и структуры самого ORB, стандарт' CORBA описывает набор стандартных сервисов (Object Services), то есть приложений, предоставляющих стандартный интерфейс, с помощью которого совместимое с CORBA приложение может выполнять те или иные задачи.

Стандарт CORBA не требует обязательного наличия всех стандартных сервисов в том или ином воплощении ORB, но однозначно определяет структуру и способ использования сервиса, если таковой имеется в конкретной реализации ORB^[5].

Для написания приложения, совместимого с CORBA, используется одно из стандартных отображений CORBA на язык (mapping). Стандарт определяет отображения CORBA на Java, C++, Smalltalk и другие языки. Различные реализации ORB включают в себя отображения на различные языки, различные наборы сервисов и протоколов. Собственные реализации ORB есть у таких известных производителей, как BorlandT, SybaseT, OracleT и других. Имеются также реализации ORB независимых производителей, как коммерческие, так и свободно распространяемые. В число последних входят MICO и ТАО, включающие в себя, среди прочего, отображение CORBA на C++. Ниже более подробно рассмотрены основные элементы стандарта CORBA. Всю документацию по стандарту CORBA можно бесплатно получить в электронном виде на сайте www.omg.org[6].

1.2. Архитектурные принципы реализации приложений

В данном разделе приводится краткий обзор CORBA в том виде, как ее описание дается в спецификации OMG версии 3.0. Требования этого документа могут в различной степени удовлетворяться фактическими реализациями брокеров объектных запросов. На рисунке 1.1 изображен запрос, посылаемый клиентом реализации объекта. Клиент – это сущность, которая хочет выполнить операцию с объектом, а Реализация – это совокупность кода и данных, которые в действительности реализуют объект.

Рис. 1.1. Клиент посылает запрос реализации объекта

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

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

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

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

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

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

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

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

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

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

Рис. 1.4. Реализация объекта получает запрос

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

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

Рис. 1.5. Репозитории интерфейсов и реализаций

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

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

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

Клиенты

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

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