Технология CORBA (Основные понятия технологии CORBA)

Содержание:

Введение

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

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

Клиенты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интерфейс ORB

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

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

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

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

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

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

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

В данном разделе приводится краткий обзор CORBA в том виде, как ее описание дается в спецификации OMG версии 3.0. Проанализировано основное назначение CORBA, которое формируется на основании поддержки разработки и развертывания сложных объектно-ориентированных прикладных систем.

2. Описание распределённой программной системы

2.1. CORBA – это машина удалённых запросов

В данном разделе представлено описание распределённой программной системы – машины удалённых запросов, реализованной с использованием технологии CORBA. Представленная программная система предназначена для решения следующих задач:

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

Машина удалённых запросов функционально состоит из трёх взаимодействующих объектных сервисов CORBA:

• сервис внешнего представления (Externalization Service) – является стандартным сервисом CORBA;
• транспортный сервис (Transport Service) – не является стандартным сервисом CORBA;
• сервис удаленных запросов (Remote Query Service) – не является стандартным сервисом CORBA^[7].

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

Текущие версии машины удалённых запросов используют свободно распространяемые реализации ORB независимых производителей – MICO или ТАО. В качестве языка программирования, для реализации сервисов использовался Visual C++ 6.0, обе упомянутые выше реализации CORBA поддерживают отображение на язык C++ – Стоит заметить, что все приведённые ниже IDL декларации интерфейсов, схемы взаимодействия сервисов и алгоритмы не зависят от конкретной реализации CORBA и языка программирования.

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

Сервис внешнего представления является стандартным сервисом CORBA. Его реализация в машине удалённых запросов базируется на стандартизированных IDL декларациях его интерфейсов и принципах его функционирования, представленных на официальном сайте разработчиков www.omg.org. Ниже приведено краткое описание интерфейсов сервиса внешнего представления.

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

Приложение, которое желает перевести объекты во внешнее представление (экс-тернализовать), должно выполнить следующие действия при инициализации:

Получить ссылку на объект типа Stream (объект данного типа может быть создан приложением методом createQ объекта StreamFactory, функциональность которого должна поддерживаться сервисом внешнего представления).

Вызвать метод externalize() объекта Stream, передав ему в качестве параметра ссылку на экстернализуемый объект типа Streamable. '

Приложение имеет возможность экстернализовать несколько объектов в один поток, для этого у объекта Stream существуют методы begin_context(), которые необходимо вызывать перед экстернализацией первого объекта и end.context(), вызываемый после экстернализации последнего объекта^[9].

Далее сам объект Stream отвечает за перевод переданных ему по ссылке объектов во внешнее представление. В частности, его функциональность должена включать в себя реализацию интерфейса StreamIO, предоставляющего базовые методы записи и чтения из потока. Именно ссылка на объект типа StreamIO передаётся в качестве аргумента в метод externalize_tojstream() каждого из экстернализуемых объектов типа Streamable, и они пользуются методами объекта SytreamIO для записи необходимой информации в поток.

Приложение, которое желает перевести объекты из внешнего представления (ин-тернализовать), должно выполнить следующие действия при инициализации:

Получить ссылку на объект типа Stream – поток, в котором сохранены объекты.

Вызвать метод internalize() объекта Stream, передав ему в качестве параметра ссылку на объект типа FactoryFinder – объект с интерфейсом CosLifeCycle::FactoryFinder (IDL декларация интерфейса включена в описание стандартного CORBA сервиса Object Lifecycle Service), содержит метод find-factories(), используемый для поиска фабрики Streamable объекта по её описанию.

Фабрики Streamable объектов должны поддерживать интерфейс StreamableFactoгу и используются для создания неинициализированных объектов при их чтении из потока. Реализация объекта типа FactoryFinder должна включать в себя механизм поиска нужной фабрики Streamable объектов по некоторому уникальному идентификатору key. Значение идентификатора Streamable объекта запаковывается в поток при его экстернализации, извлекается из потока перед его интернализацией, по извлечённому идентификатору ищется нужная фабрика, с помощью которой и создаётся неинициализированный Streamable объект (метод create.uninitialized() объекта типа StreamableFactory). В качестве идентификатора используется значение атрибута key самого Streamable объекта, получаемое при его экстернализации^[10].

В текущей реализации машины удалённых запросов интерфейс сервиса внешнего представления расширен модулями CosStorage и ExternalizationStorage с интерфейсами:

• CosStorage::Storage – представляет собой низкоуровневое хранилище байт, с базовыми операциями по работе с ним.
• CosStorage::StorageInput – итератор для доступа к данным, хранимым в объекте Storage.
• CosStorage: :StorageFactory – фабрика, используемая для создания объектов типа Storage.
• ExternalizationStorage::StorageStream – CosExternalization::Stream с хранением данных в виде CosStorage::Storage.
• ExternalizationStorage::StorageStreamFactory – фабрика, используемая для создания объектов типа StorageStream.

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

Транспортный сервис предоставляет внешний интерфейс согласно стандарту CORBA и использует другие сервисы CORBA для выполнения внутренних функций: сервис внешнего представления (Externalization Service) используется для получения внешнего представления передаваемого объекта. Поэтому при запуске транспортного сервиса одним из его обязательных входных параметров является IOR объекта типа StreamFactory,созданного сервисом внешнего представления.

При инициализации транспортный сервис создаёт объект типа TransportService и вспомогательные объекты, в соответствии со спецификацией сервиса и реализующие его функциональность^[11].

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

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

Сервис удаленных запросов предоставляет внешний интерфейс согласно стандарту CORBA и использует другие сервисы CORBA для выполнения внутренних функций: транспортный сервис (Transport Service) используется для транспортировки внешнего представления запроса, а сервис внешнего представления (Externalization Service) используется для получения внешнего представления запроса и результата* с целью дальнейшей передачи через транспортный сервис.

Сервис удалённых запросов при запуске получает в качестве одного из входных параметров IOR объекта типа TransportService, созданного транспортным сервисом. Далее, используя полученную ссылку,' создаёт и регистрирует в транспортном сервисе объект типа Consumer, тем самым приобретая возможность получать объекты через транспортный сервис, и объекты типа StreamableFactory, необходимые для выполнения операций перевода из внешнего во внутреннее представление передаваемых и получаемых объектов. После чего создаёт объект типа RemoteQueryMachine и вспомогательные объекты, в соответствии со спецификацией сервиса и реализующие его функциональность^[12].

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

Приложение, которое взаимодействует с сервисом удаленных запросов, должно выполнить следующие действия при инициализации:

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

Зарегистрировать объекты типа QueryListener, предназначенные для удаленного исполнения запросов, посредством метода RemoteQueryMachine::register_listener().

Зарегистрировать объекты типа StreamableFactory, необходимые для выполнения операций перевода из внешнего во внутреннее представление, в объекте типа TransportService, ссылка на который может быть получена при помощи метода RemoteQueryMachine::get_transport().

Эти действия требуются для приложения, которое будет получать запросы от сервиса, выполнять эти запросы, а также получать результаты запросов^[13].

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

2.2. Общая схема системы

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

CORBA определяется с помощью формализованной спецификации, написанной на языке IDL. Появлению очередной версии предшествуют четко организованный процесс адаптации нового стандарта, который обычно завершается быстрее, чем аналогичные процедуры в ISO. В результате CORBA может похвастаться значительным числом реализаций. Первоначальный вариант спецификации появился в 1991 году, и уже в 1992-м был выпущен коммерческий продукт – брокер объектных запросов DEC ObjectBroker^[14].

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

Различные брокеры запросов взаимодействуют между собой по протоколу General Inter ORB Protocol (GIOP). В связи с активным переносом в среду Web критически важных корпоративных приложений наибольший интерес представляет реализация протокола GIOP на базе TCP/IP – протокол Internet Inter ORB Protocol (IIOP).

Ниже представлена схема взаимодействия сервисов машины удалённых запросов внутри одного сервера системы и между несколькими серверами, разнесёнными в сети (Рис. 2.1).

Ядро CORBA, включающее Брокер Объектных Запросов и Объектные Адаптеры, обеспечивает механизмы, позволяющие объектам взаимодействовать между собой, не заботясь о положении в распределенной среде и способе их реализации, обеспечивает механизмы управления циклом жизни CORBA-объектов и их реализаций^[15].

Рис. 2.1. Схема взаимодействия сервисов машины удалённых запросов

Реализация машины удалённых запросов на основе технологии -CORBA в виде набора взаимодействующих сервисов CORBA позволила достигнуть среди прочего:

• Платформенной и языковой независимости. Реализация описанных выше сервисов на языке C++ легко переносима между операционными системами семейства Windows и Unix. Использование для описания интерфейсов сервисов языка IDL позволяет легко отображать их на большинство современных объектно – ориентированных языков программирования, переносимость клиентов и реализаций объектов между ORB различных производителей.
• Возможности создания серверных объектов по запросам клиента с обеспечением оптимального управления ресурсами серверов (оперативная память, сетевые соединения), возможность построения динамических связей между объектами в системе и динамического сопоставления с ними произвольных свойств^[16].

Функции CORBA – это функции промежуточного программного обеспечения объектной среды. Для того чтобы обеспечить взаимодействие объектов и их интеграцию в цельную систему, архитектура промежуточного уровня должна реализовать несколько базовых принципов^[17].

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

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

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

Интерфейс определяет набор методов, которые реализуют функции, присущие данному классу объектов. Интерфейс дает клиенту возможность только вызывать тот или иной метод, скрывая от него все детали его реализации. Клиент получает доступ к объекту только путем вызова метода, определенного в интерфейсе объекта. Это означает, что реальные действия выполняются в адресном пространстве объекта, возможно, удаленном по отношению к процессу клиента. Сокрытие деталей реализации и позволяет в конечном итоге добиться слаженного взаимодействия компонентов в независимости от того, где и на какой платформе они реализованы, и какой язык программирования для этого использовался^[18].

В обеих технологиях взаимодействие между клиентским процессом и сервером объекта, то есть процессом, который порождает и обслуживает экземпляры объекта, использует механизм объектный вариант вызова удаленной процедуры (RPC, remote procedure call).

Структура RPC – старейшей механизм из технологий промежуточного программного обеспечения. Механизм RPC реализует схему передачи сообщений, в соответствии с которой в распределенном клиент-серверном приложении процедура – клиент передает специальное сообщение с параметрами вызова по сети в удаленную серверную процедуру, а результаты ее выполнения возвращаются в другом сообщении клиентскому процессу^[19].

Для того чтобы реализовать эту схему, на стороне клиента и на стороне сервера поддерживаются специальные компоненты, носящие название клиентский и серверный суррогаты (client stub и server stub). Для того чтобы вызвать ту или иную функцию, клиент обращается к клиентскому суррогату, который упаковывает аргументы в сообщение-запрос и передает их на транспортный уровень соединения. Серверный суррогат распаковывает полученное сообщение и в соответствии с переданными аргументами вызывает нужную функцию, или нужный метод объекта, если речь идет об объектном варианте RPC.

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

Тем самым достигается возможность взаимодействия клиента и сервера на различных платформах^[20].

В данном разделе представлено описание распределённой программной системы – машины удалённых запросов, реализованной с использованием технологии CORBA и общая схема системы.

Заключение

Итак, CORBA является ведущей технологией построения распределенных объектных сред. Она имеет базовые принципы и множество различий в деталях реализации. На основе технологии CORBA создан солидный багаж проектов, что наглядно демонстрирует многочисленные «истории успеха» на Web-узле консорциума OMG и домашней страничке CORBA.

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

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

CORBA обеспечивает реальную многоплатформенность. Реализации CORBA многочисленны и принадлежат множеству производителей (с их полным списком и описанием продуктов можно познакомиться в Web по адресу www.corba.org/vendors). Эти продукты поддерживают обширный диапазон аппаратных платформ, в том числе мэйнфреймы, миникомпьютеры и Unix-системы. Однако разнообразие реализаций имеет и свои недостатки, прежде всего потенциальную проблему несовместимости.

Ряд продуктов позволяет сосуществовать объектам СОМ/CORBA. Взаимодействие объектов CORBA с OLE/COM определяется в спецификации CORBA, начиная с версии 2.0. Поддержку смешанной среды СОМ/CORBA обеспечивают в своих системах, например, компании Iona, Visual Edge и NobleNet. Так, Iona получила лицензию от Microsoft на использование технологии СОМ в системе СОМet, которая позволяет организовать «мост» между объектами в разных архитектурах. Непосредственную интеграцию СОМ, CORBA, RPC и Java обеспечивает анонсированная в начале этого года последняя версия системы Nouveau компании NobleNet^[21].

Список литературы

1. Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на C++, 2 4 изд. Пер. с англ. М.: Изд-во Бином, СПб.: Невский диалект, 2016.
2. Калиниченко JI.A., Когаловский М.Р. Стандарты OMG: язык определения интерфейсов IDL в архитектуре CORBA. СУБД. N 2. 2015.
3. Компоненты сетевого приложения. Клиент-серверное взаимодействие и роли серверов. [Электронный ресурс] URL: http://www.4stud.info/networking/lecture5.html (дата доступа 28.09.2018)
4. Механизм вызова удаленных процедур – RPC [Электронный ресурс] URL: http://delphiworld.narod.ru/base/rpc_protocol.html (дата доступа 28.09.2018)
5. Понятие клиент-серверных систем [Электронный ресурс] URL: http://bourabai.kz/dbt/client1.htm (дата доступа 28.09.2018)
6. Разработка распределённого Web-приложения [Электронный ресурс] URL: http://www.rsdn.ru/article/webdevelopment/49-57-distributedapps.xml (дата доступа 28.09.2018)
7. Слама Дирк, Гарбмс Джексон, Рассел Перри. Корпоративные системы на основе CORBA. М.: Издательский дом Вильямс, 2015.
8. Шевцов А.Н., Шырынханова Д.Ж. Разработка алгоритмов и приложения компонентной модели для анализа и исправления ошибок экзаменационного теста. Theoretical & Applied Science. «Development of Applied Mathematics», ISPC, 30.05.2017, Taraz, Kazakhstan. – №5, 2016. -p.77-83. [Электронный ресурс] URL: http://elibrary.ru/item.asp?id=20357857 (дата доступа 28.09.2018)
9. Шевцов А.Н., Смайлова У.М., Шырынханова Д.Ж. Некоторые алгоритмы предварительной обработки теста. Theoretical & Applied Science. «Results & Perspectives», ISPC, 30.09.2016, Florence, Italy. – №9, 2013. -p.51-58. [Электронный ресурс] URL: http://elibrary.ru/item.asp?id=20362250 (дата доступа 28.09.2018)
10. Цимбал А. Технология CORBA для профессионалов. СПб.: Питер, 2015.
11. Object Management Group. The Common Object Request Broker: Architecture and Specification. OMG Document Number 91.12.1. December 2015.
12. Object Management Group. Object Services Architecture. Revision 8.0. December 2014.
13. Object Management Group. Common Facilities Architecture. Revision 2.0. September 2015.
14. Object Management Group. Common Facilities Architecture. Revision 3.0. November 2016.
15. Object Management Group. Common Facilities Roadmap. Revision 3.1. January 2015.
16. Object Management Group. Common Object Services Specification Volumel (COSS1). March 2016.
17. Object Management Group. Object Management Architecture Guide. OMG Document Number 92.11.1. September 1. 2015.
18. Сравнение COM и CORBA [Электронный ресурс] URL: http://kunegin.com/ref3/corba5/12.htm (дата доступа 28.09.2018)
19. СОМ или CORBA [Электронный ресурс] URL: http://delphiworld.narod.ru/base/com_or_corba.html (дата доступа 28.09.2018)
20. PowerBuilder 5.0 – открытый инструментарий для создания сложных распределенных клиент-серверных приложений [Электронный ресурс] URL: http://www.osp.ru/data/www2/dbms/1996/05/97.htm (дата доступа 28.09.2018)

1. Калиниченко JI.A., Когаловский М.Р. Стандарты OMG: язык определения интерфейсов IDL в архитектуре CORBA. СУБД. N 2. 2015. ↑

2. Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на C++, 2 4 изд. Пер. с англ. М.: Изд-во Бином, СПб.: Невский диалект, 2016. ↑

3. Цимбал А. Технология CORBA для профессионалов. СПб.: Питер, 2015. ↑

4. Сравнение COM и CORBA [Электронный ресурс] URL: http://kunegin.com/ref3/corba5/12.htm (дата доступа 28.04.2014) ↑

5. Object Management Group. The Common Object Request Broker: Architecture and Specification. OMG Document Number 91.12.1. December 2015. ↑

6. Object Management Group. The Common Object Request Broker: Architecture and Specification. OMG Document Number 91.12.1. December 2015. ↑

7. Калиниченко JI.A., Когаловский М.Р. Стандарты OMG: язык определения интерфейсов IDL в архитектуре CORBA. СУБД. N 2. 2015. ↑

8. Компоненты сетевого приложения. Клиент-серверное взаимодействие и роли серверов. [Электронный ресурс] URL: http://www.4stud.info/networking/lecture5.html (дата доступа 28.04.2016) ↑

9. Шевцов А.Н., Шырынханова Д.Ж. Разработка алгоритмов и приложения компонентной модели для анализа и исправления ошибок экзаменационного теста. Theoretical & Applied Science. «Development of Applied Mathematics», ISPC, 30.05.2013, Taraz, Kazakhstan. - №5, 2016. -p.77-83. [Электронный ресурс] URL: http://elibrary.ru/item.asp?id=20357857 (дата доступа 28.04.2016) ↑

10. Понятие клиент-серверных систем [Электронный ресурс] URL: http://bourabai.kz/dbt/client1.htm (дата доступа 28.04.2016) ↑

11. Object Management Group. Common Facilities Roadmap. Revision 3.1. January 2015. ↑

12. Object Management Group. Object Management Architecture Guide. OMG Document Number 92.11.1. September 1. 2015. ↑

13. Сравнение COM и CORBA [Электронный ресурс] URL: http://kunegin.com/ref3/corba5/12.htm (дата доступа 28.04.2014) ↑

14. СОМ или CORBA [Электронный ресурс] URL: http://delphiworld.narod.ru/base/com_or_corba.html (дата доступа 28.04.2014) ↑

15. Шевцов А.Н., Шырынханова Д.Ж. Разработка алгоритмов и приложения компонентной модели для анализа и исправления ошибок экзаменационного теста. Theoretical & Applied Science. «Development of Applied Mathematics», ISPC, 30.05.2013, Taraz, Kazakhstan. - №5, 2016. -p.77-83. [Электронный ресурс] URL: http://elibrary.ru/item.asp?id=20357857 (дата доступа 28.04.2016) ↑

16. Слама Дирк, Гарбмс Джексон, Рассел Перри. Корпоративные системы на основе CORBA. М.: Издательский дом Вильямс, 2015. ↑

17. Разработка распределённого Web-приложения [Электронный ресурс] URL: http://www.rsdn.ru/article/webdevelopment/49-57-distributedapps.xml (дата доступа 28.04.2017)

    Слама Дирк, Гарбмс Джексон, Рассел Перри. Корпоративные системы на основе CORBA. М.: Издательский дом Вильямс, 2015. ↑

18. PowerBuilder 5.0 - открытый инструментарий для создания сложных распределенных клиент-серверных приложений [Электронный ресурс] URL: http://www.osp.ru/data/www2/dbms/1996/05/97.htm (дата доступа 28.04.2014) ↑

19. Шевцов А.Н., Смайлова У.М., Шырынханова Д.Ж. Некоторые алгоритмы предварительной обработки теста. Theoretical & Applied Science. «Results & Perspectives», ISPC, 30.09.2016, Florence, Italy. - №9, 2013. -p.51-58. [Электронный ресурс] URL: http://elibrary.ru/item.asp?id=20362250 (дата доступа 28.04.2015) ↑

20. Разработка распределённого Web-приложения [Электронный ресурс] URL: http://www.rsdn.ru/article/webdevelopment/49-57-distributedapps.xml (дата доступа 28.04.2017) ↑

21. Слама Дирк, Гарбмс Джексон, Рассел Перри. Корпоративные системы на основе CORBA. М.: Издательский дом Вильямс, 2015. ↑