Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

ВВЕДЕНИЕ

Технология 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 в составе операционной системы возможны различные виды оптимизации, такие как отказ от кодирования и декодирования данных, если клиент и сервер расположены на одной машине.

4. ORB на базе библиотек.

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

1.3 Язык определения интерфейсов

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

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

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

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

| - или

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

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

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

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

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

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

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

На сегодняшний день OMG определила отображения IDL в C, C++ и Smalltalk. В настоящее время завершается разработка стандарта картирования IDL для языка ада. Эта работа не из легких. Таким образом, обсуждение и принятие отображения IDL только на языке С++ заняло более двух лет напряженной работы, подтвердив важность технологии стандартизации OMG.

1.4 Сетевая и объектная модели CORBA

Интероперабельность брокеров поддерживается Универсальным Межброкерным Протоколом (General Inter-ORB Protocol, сокращенно GIOP). GIOP является универсальным, поскольку он не зависит от конкретной сетевой транспортной среды и может быть отображен в любой транспортный протокол, поддерживающий виртуальные соединения. Одно из таких отображений - отображение GIOP в протокол TCP/IP - определено CORBA 2.0 в качестве Межброкерного Протокола Internet (Internet Inter-ORB Protocol, сокращенно IIOP). Назначение протокола GIOP/IIOP заключается в том, чтобы поддержать сети брокеров в рамках Internet и за ее пределами.

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

Спецификация GIOP включает:

1) определение Общего представления данных (Common Data Representation - CDR), являющегося, по существу, коммуникационным синтаксисом, отображающим значения типов данных OMG IDL в формат передачи данных между брокерами и межброкерными мостами (агентами);

2) форматы передаваемых между агентами сообщений GIOP, которые введены для поддержки объектных заявок, установления местоположения реализаций объектов и управления транспортными соединениями;

3) определение ограничений на допустимый сетевой транспорт GIOP.

Протокол IIOP, который можно считать специализацией GIOP, определяет дополнительно, как агенты открывают соединения TCP/IP и используют их для передачи сообщений GIOP. GIOP трактует транспортное соединение как асимметричное. Определяются две различных роли использования соединения: роль клиента и роль сервера. Клиент образует соединение и посылает объектные заявки, сервер принимает заявки и посылает ответы. Сервер не может посылать объектных заявок. Соединение может использоваться совместно многочисленными клиентами в одном брокере для посылки независимых заявок различным объектам в определенном брокере или сервере. Допускается асинхронная посылка заявок при их произвольном чередовании в соединении.

В передаваемых сообщениях допускается любой порядок байт (в зависимости от архитектуры процессора), заданный отправителем сообщения. Получатель сообщения должен изменить этот порядок по своему усмотрению. Значения основных типов IDL (char, octet, short, unsigned short, long, unsigned long, float, double, boolean, enum) выравниваются по границе естественных полей. Кодирование строящихся типов IDL (структура, соединение, массив, последовательность, строка) задается, что не налагает дополнительных требований к выравниванию по отношению к заданным для базовых типов.

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

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

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

1.5 Основные объектные службы и универсальные средства CORBA

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

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

Сервис жизненного цикла - Life Cycle Service определяет операции создания, копирования, перемещения и удаления компонентов на шине.

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

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

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

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

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

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

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

Служба сервиса запросов обеспечивает поддержку запросов на объекты. Это подмножество SQL, основанное на расширенных спецификациях SQL3 и языке запросов объектов (OQL).

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

Данный сервис поддерживает некоторую модель композиционно-неиспользуемого использования на любом этапе своего жизненного цикла.

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

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

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

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

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

Известно, что услуги OMG не являются независимыми друг от друга. Некоторые из них могут быть созданы на базе других сервисов. Как рекомендует OMG, на рисунке 1 приведен график зависимости одного сервиса от другого.

Универсальные средства предоставляют поддержку интерфейсов высокого уровня и делятся на два типа: горизонтальные и вертикальные.

Рис. 2. Граф зависимостей служб, специфицированных OMG

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

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

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

- информационное моделирование (определяет правила, по которым осуществляется структурирование и доступ к информации),

- хранение и извлечение информации (определяет использование баз данных и систем каталогизации),

- обмен информацией,

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

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

4) Инструменты управления задачами. Предполагается, что этот набор будет представлен четырьмя спецификациями: услуги по организации документооборота, услуги агентов, услуги по управлению объектами, услуги по автоматизации объектов.

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

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

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

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

3) Интегрированные автоматизированные производственные инструменты. Позволяет интегрировать бизнес-функции предприятия с компьютерами. Объединенные функции могут также включать управление процессами разработки, контроль качества, финансовые и маркетинговые операции.

4) Распределенные инструменты эмуляции процесса. Сервисы данной спецификации должны служить основой для быстрого построения и эксплуатации эмулируемой модели.

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

6) Бухгалтерское оборудование. Включает все виды коммерческих операций: обмен валюты, управление платежами, управление продажами и т.д.

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

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

Альтернативные подходы, наиболее ярко выраженные в политике Microsoft и Sun, не соответствуют современным тенденциям в развитии технологий, согласно которым диктат одного производителя (даже с лучшими намерениями) в целом создает больше проблем, чем решает. Речь идет не только о технологиях. Примером тому может служить операционная система Windows, в которой пользователей больше, чем в других странах мира вместе взятых, и большинство людей рассматривают это как вынужденный выбор.

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

Проблема с монопольными стандартами заключается в протекционистской политике владельца стандарта, которая проявляется и на других смежных рынках, в случае с Microsoft - это ОС. Расширение продвижения COM на платформе Windows делает перенос этого стандарта на другие платформы экономически невыгодным, вынуждая разработчика вступать в намеренно проигрышную конкуренцию с Microsoft.

CORBA - это концепция, а не ее реализация. Когда мы говорим "COM", мы понимаем его как набор специфических инструментов - элементов операционной системы, библиотек, утилит и т.д., которые являются частью того, что называется Microsoft Windows. Под термином "CORBA" понимается сложное и разработанное понятие, сформулированное на уровне специального языка описаний - IDL. Реализация этой концепции может сильно отличаться друг от друга по различным критериям, наиболее важным в том или ином случае. VisiBroker (разработки Visigenic/Borland/Inprise/Corel) и сервер приложений, BEA WebLogic, Iona Orbix, Oracle Application Server и "картриджи" Oracle, IBM BOSS - все эти продукты используют те или иные возможности CORBA.

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

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

2. СОЗАДНИЕ CORBA ПРИЛОЖЕНИЯ В J++BUILDER

2.1 Написание интерфейса

Создание приложения CORBA на Java начинается с написания интерфейса для удаленного объекта с использованием языка описания интерфейса (Interface Definition Language, IDL).

Создадим файл hello.idl

module HelloApp

{

interface Hello

{

string sayHello();

oneway void shutdown();

};

Этот интерфейс описывает только два способа выключения и sayHello. И неважно, что с нами делают эти методы, главное - определить, что они собой представляют и каковы их входные и выходные параметры.

Далее следует запустить компилятор IDL-to-Java idlj:

idlj -fall Hello.idl

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

• HelloPOA.java java — абстрактный класс, который представляет собой ни что иное, как скелет сервера (skeleton) и обеспечивает функциональность сервера.

• _HelloStub.java — класс, реализующий заглушку (stub) клиента. Обеспечивает функциональность клиента.

• HelloHelper.java и HelloHolder.java — классы, предоставляющие вспомогательные функции для CORBA объектов.

• HelloOperations.java — класс, содержащий описание интерфейса hello на языке Java.

• Hello.java — класс-наследник HelloOperations, поддерживающий интерфейс org.omg.CORBA.Object.

2.2 Создание сервера

Теперь наша задача — написать класс, реализующий интерфейс hello. В нашем случае это будет HelloImpl. Обратите внимание, на то, что он является наследником класса HelloPOA. В HelloImpl реализованы методы, объявленные в Hello.idl.

Для упрощения задачи объявление методов можно взять из файла HelloOperations.java, сгенерированного jdlj.

class HelloImpl extends HelloPOA {

private ORB orb;

public void setORB(ORB orb_val) {

orb = orb_val;

}

// implement sayHello() method

public String sayHello() {

return "\nHello world !!\n";

}

// implement shutdown() method

public void shutdown() {

orb.shutdown(false);

}

Следующим шагом будет создание реальной серверной части приложения. Это будет класс HelloServer.

Он будет иметь только один способ - стандартную функцию main.

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

Рассмотрим подробнее эти этапы.

1. Создание и инициализация ORB. Производится вызовом статического метода init класса ORB

ORB orb = ORB.init(args, null);

2. Создание экземпляра класса удаленного объекта и регистрация его в ORB

HelloImpl helloImpl = new HelloImpl();

helloImpl.setORB(orb);

3. Получение контекста имен (NamingContext)

org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");

NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);

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

4. Регистрация имени удаленного объекта (HelloImpl)

String name = "Hello";

NameComponent path[] = ncRef.to_name( name );

ncRef.rebind(path, href);

Регистрация имени производится для того, чтобы клиент смог найти удаленный объект. Этой цели служит функция rebind(NameComponent[] nc, Object obj) интерфейса NamingContext.

5. Ожидание запросов от клиента

orb.run();

Теперь сервер готов к работе.

// HelloServer.java

import HelloApp.*;

import org.omg.CosNaming.*;

import org.omg.CosNaming.NamingContextPackage.*;

import org.omg.CORBA.*;

import org.omg.PortableServer.*;

import org.omg.PortableServer.POA;

import java.util.Properties;

class HelloImpl extends HelloPOA {

private ORB orb;

public void setORB(ORB orb_val) {

orb = orb_val;

}

// implement sayHello() method

public String sayHello() {

return "\nHello world !!\n";

}

// implement shutdown() method

public void shutdown() {

orb.shutdown(false);

}

public class HelloServer {

public static void main(String args[]) {

try{

// create and initialize the ORB

ORB orb = ORB.init(args, null);

// get reference to rootpoa & activate the POAManager

POA rootpoa =

POAHelper.narrow(orb.resolve_initial_references("RootPOA"));

rootpoa.the_POAManager().activate();

// create servant and register it with the ORB

HelloImpl helloImpl = new HelloImpl();

helloImpl.setORB(orb);

// get object reference from the servant

org.omg.CORBA.Object ref = rootpoa.servant_to_reference(helloImpl);

Hello href = HelloHelper.narrow(ref);

// get the root naming context

// NameService invokes the name service

org.omg.CORBA.Object objRef =

orb.resolve_initial_references("NameService");

// Use NamingContextExt which is part of the Interoperable

// Naming Service (INS) specification.

NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);

// bind the Object Reference in Naming

String name = "Hello";

NameComponent path[] = ncRef.to_name( name );

ncRef.rebind(path, href);

System.out.println("HelloServer ready and waiting ...");

// wait for invocations from clients

orb.run();

}

catch (Exception e) {

System.err.println("ERROR: " + e);

e.printStackTrace(System.out);

}

System.out.println("HelloServer Exiting ...");

}

2.3 Создание клиента

Перейдем к написанию кода для клиента.

Основные шаги написания клиентского приложения

Создание и инициализация ORB
Получение контекста службы имен (NamingContext)
Нахождение удаленного объекта
Вызов метода sayHello.
Вызов метода shutdown.

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

Третий пункт реализуется тоже достаточно просто. Создается объект NameComponent. Вызывается метод resolve(NameComponent[] path), который отыскивает по имени удаленный объект (стандартный CORBA-объект). При помощи метода narrow(org.omg.CORBA.Object obj) класса helloHelper (сгенерированного idlj компилятором) получаем объектную ссылку на интерфейс hello.

String name = "Hello";

helloImpl = HelloHelper.narrow(ncRef.resolve_str(name));

Теперь можно вызывать метод sayHello:

System.out.println(helloImpl.sayHello());

Метод shutdown завершает работы сервера.

helloImpl.shutdown();

//testClient.java import HelloApp.*;

import org.omg.CosNaming.*;

import org.omg.CosNaming.NamingContextPackage.*;

import org.omg.CORBA.*;

public class HelloClient

{

static Hello helloImpl;

public static void main(String args[])

{

try{

// create and initialize the ORB

ORB orb = ORB.init(args, null);

// get the root naming context

org.omg.CORBA.Object objRef =

orb.resolve_initial_references("NameService");

// Use NamingContextExt instead of NamingContext. This is

// part of the Interoperable naming Service.

NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);

// resolve the Object Reference in Naming

String name = "Hello";

helloImpl = HelloHelper.narrow(ncRef.resolve_str(name));

System.out.println("Obtained a handle on server object: " +

helloImpl);

System.out.println(helloImpl.sayHello());

helloImpl.shutdown();

} catch (Exception e) {

System.out.println("ERROR : " + e) ;

e.printStackTrace(System.out);

}

2.4 Компиляция и запуск приложения

Файлы HelloServer.java and HelloClient.java, Hello.idl и папка HelloApp, созданная idkj.exe должны храниться в одной папке.

Для компиляции клиента и сервера надо в командной строке набрать

javac *.java HelloApp/*.java

javac.exe находится в …\jdk1.5.0\bin.

Среда Eclipse не позволяет запускать CORBA-приложения. Для запуска

1. Запустить службу orbd - Object Request Broker Daemon (…\jdk1.5.0\bin\orbd.exe). Это делается, чтобы мы смогли получить ссылку на службу имен.

start orbd -ORBInitialPort 1050

Параметр -ORBInitialPort– номер порта, на котором будет работать сервер имен.

2. Запуск сервера

start java HelloServer -ORBInitialPort 1050 -ORBInitialHost localhost

Указывается порт, на котором работает сервер имен. Параметр -ORBInitialHost указывает хост, на котором работает сервер имен.

3. Запуск клиента

java HelloClient -ORBInitialPort 1050 -ORBInitialHost localhost

Для удобства компиляции и запуска можно создать bat-файл:

idlj -fall Hello.idl

javac *.java HelloApp/*.java

start java HelloServer -ORBInitialPort 1050 -ORBInitialHost localhost

java HelloClient -ORBInitialPort 1050 -ORBInitialHost localhost

ЗАКЛЮЧЕНИЕ

Следует отметить, что архитектура CORBA направлена на достижение поставленных целей - развитие прикладных систем:

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

- интеграции;

- Реинжиниринг;

- Миграция наследников;

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

- Увеличение жизненного цикла систем.

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

СПИСОК ЛИТЕРАТУРЫ

Белоусов В.Е., Дехтенко В.О., Белоусов А.В. Применение технологии CORBA в задачах проектирования систем управления // сборник научных трудов XX Международной научно-практической конференции. 2016
Калиниченко Л.А., Когаловский М.Р. Интероперабельность брокеров в стандарте CORBA 2.0//СУБД. -2013. -№ 3.
Кен Арнольд, Джеймс Гослинг, Дэвид Холмс. Язык программирования Java™.
Кирьянов С.К. Применение технологии CORBA для создания машины удаленных запросов // Вестник Нижегородского Университета им. Н.И. Лобачевского. Серия: Математическое моделирование и оптимальное управление. – 2014. - № 1. – С. 258-268
Маслобоев А.В., Шишаев М.Г. Распределенные системы и компьютерные технологии обработки информации: учеб. пособие. – Апатиты: Изд-во КФ ПетрГУ, 2009
Омельченко А.И. Особенности построения корпоративных информационных систем на основе технологии CORBA // Материалы VIII Международной научно-практической конференции. 2015
Сравнение COM и CORBA [Электронный ресурс] URL: http://kunegin.com/ref3/corba5/12.htm
СОМ или CORBA [Электронный ресурс] URL: http://delphiworld.narod.ru/base/com_or_corba.html
Механизм вызова удаленных процедур – RPC [Электронный ресурс] URL: http://delphiworld.narod.ru/base/rpc_protocol.html
PowerBuilder 5.0 - открытый инструментарий для создания сложных распределенных клиент-серверных приложений [Электронный ресурс] URL: http://www.osp.ru/data/www2/dbms/1996/05/97.htm
Разработка распределённого Web-приложения [Электронный ресурс] URL: http://www.rsdn.ru/article/webdevelopment/49-57-distributedapps.xml
Понятие клиент-серверных систем [Электронный ресурс] URL: http://bourabai.kz/dbt/client1.htm
Компоненты сетевого приложения. Клиент-серверное взаимодействие и роли серверов. [Электронный ресурс] URL: http://www.4stud.info/networking/lecture5.html
Шевцов А.Н., Шырынханова Д.Ж. Разработка алгоритмов и приложения компонентной модели для анализа и исправления ошибок экзаменационного теста. Theoretical & Applied Science. «Development of Applied Mathematics», ISPC, 30.05.2013, Taraz, Kazakhstan. - №5, 2013. -p.77-83. [Электронный ресурс] URL: http://elibrary.ru/item.asp?id=20357857

СОМ или CORBA [Электронный ресурс] URL: http://delphiworld.narod.ru/base/com_or_corba.html ↑
PowerBuilder 5.0 - открытый инструментарий для создания сложных распределенных клиент-серверных приложений [Электронный ресурс] URL: http://www.osp.ru/data/www2/dbms/1996/05/97.htm; Разработка распределённого Web-приложения [Электронный ресурс] URL: http://www.rsdn.ru/article/webdevelopment/49-57-distributedapps.xml ↑