Файл: Технология CORBA (АНАЛИЗ ТЕСТОВ И ТЕХНОЛОГИЯ CORBA ).pdf

ВВЕДЕНИЕ

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

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

Основание: CORBA делает объект брокером запросов (Object Request Broker).

ORB контролирует взаимодействие объектов в распределенной сетевой среде. IIOP (Internet Inter-ORB Protocol) - это специальный протокол взаимодействия между ORB.

В адресном пространстве клиента функционирует специальный объект под названием plug (stub). Узнав запрос от клиента, он упаковывает параметры запроса в специальный формат и передает его на сервер, а точнее на скелет.

Скелет - это объект, работающий в адресном пространстве сервера. Получив запрос от клиента, он распаковывает его и передает на сервер. Кроме того, скелет конвертирует ответы сервера и передает их клиенту (пустые).

Для того, чтобы написать любое приложение CORBA используя технологию Java, необходимо иметь две вещи — это установленный пакет JDK1.5 и компилятор idlj (…\jdk1.5.0\bin\idlj.exe). JDK предоставляет набор классов для работы с CORBA объектами, а idlj производит отображение языка IDL в Java.

Цель данной работы – изучить технологию CORBA.

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

1. АНАЛИЗ ТЕСТОВ И ТЕХНОЛОГИЯ CORBA

1.1 Основные архитектурные принципы и задачи

CORBA (Common Object Request Broker Architecture) - это распределенная технология разработки приложений, ориентированная на интеграцию распределенных автономных систем.

В начале 1990-х годов кошмар кошмара был проблемой обеспечения возможности общения программ, работающих на разных машинах, особенно при использовании различного оборудования, операционных систем и языков программирования: либо сами программисты использовали сокеты и реализовали весь стек протоколов, либо их программы вообще не взаимодействовали. (Другие ранние версии промежуточного ПО были ограничены средами C и Unix и не подходят для использования в гетерогенных средах).

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

---

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

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

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

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

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

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

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

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

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

---

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

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

1.2 Брокер Объектных Заявок

Брокер Объектных Заявок (Object Request Broker – ORB) - промежуточное программное обеспечение, устанавливающее отношения клиент-сервер между объектами в распределенной компьютерной среде. ORB предоставляет механизмы, позволяющие объектам отправлять или получать запросы, отвечать на них и получать результаты, не беспокоясь о расположении других объектов в распределенной среде и способах их реализации. ORB отвечает за поиск реализации серверного объекта для исполнения заявки, подготовку реализации этого объекта для приема заявки и передачи данных, полученных в результате выполнения заявки.

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

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

Операционная совместимость брокеров интерпретируется ОМG как способность объекта клиента под управлением брокера-1 инициировать IDL-специфическую работу объекта сервера под управлением брокера-2 при условии, что брокер-1 и брокер-2 развивались независимо друг от друга. Другими словами, такие звонки должны быть независимы от того, поддерживают ли взаимодействующие объекты одни и те же или разные (возможно, разные) брокеры.

---

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

Рис. 1. Структура интерфейсов Брокера Объектных Заявок

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

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

1) генерация ссылок на удаленные объекты,

2) вызов методов, определенных в IDL,

3) обеспечение безопасности взаимодействия,

4) активация и дезактивация объектов,

5) установление соответствия между ссылками на удаленные объекты и фактическими копиями объектов,

6) регистрация объектов.

Спецификация OMG CORBA определяет базовый объектный адаптер, который должен быть реализован во всех брокерах запросов. Базовый объектный адаптер (BOA) представляет собой набор интерфейсов для создания ссылок на удаленные объекты, регистрации объектов, авторизации запросов и активации приложений. Базовым объектным адаптером является решение первичной задачи обеспечения связи между реализацией объекта и брокером запроса. Для организации взаимодействия между ORB и, например, системой управления базой данных, необходимо разработать объектный адаптер.

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

---

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

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

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

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

Имеется широкий спектр способов реализации конкретных ORB. Ниже приводятся примеры таких внедрений. Следует иметь в виду, что конкретный ORB может быть реализован несколькими способами одновременно.

1. ORB, входящие в состав клиентских и серверных приложений.

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

2. ORB, выполненный в виде сервера.

Для обеспечения централизованного сбора и управления всеми видами информации ORB может быть реализовано в виде отдельного приложения.

Взаимодействующие приложения устанавливают контакт с ORB с помощью обычных механизмов IPC.

3. ORB как часть системы.

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

---