"Технология CORBA"

Содержание:

ВВЕДЕНИЕ

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

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

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

Предмет исследования: распределенные системы обработки информации.

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

Глава 1. Распределенные системы

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

Распределенная система – это набор независимых компьютеров, представляющийся их пользователям единой объединенной системой.

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

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

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

Глава 2. Распределенные системы объектов

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

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

Видимая часть объекта называется его интерфейсом. Интерфейс объекта представляет собой протокол сообщений, используемых для запроса функциональности. Совокупность интерфейсов определяет поведение объекта. Интерфейс объекта состоит из имени объекта и набора методов. Методы состоят из двух частей: описание (signature) и реализация (implementation). описание состоит из имени метода, имен и типов параметров (в том числе возвращаемое значение) и исключений (exceptions). Реализация метода – это код, выполняемый для осуществления нужной операции.

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

Поведение объекта – это контракт, который предлагается потребителю. Именно контракт объекта гарантирует то, что вызов одного из его методов в соответствии с описанием приводит к определенному результату или исключению. Контракт состоит из описания и необходимых предусловий (pre-conditions), инвариантов (invariants) и постусловий (post-conditions). Инварианты – это условия, которые всегда остаются истинными. предусловия – условия, правильность которых должна быть обеспечена перед вызовом метода. Постусловия – условия, правильность которых проверяется после вызова метода, и подтверждают правильность выполнения контракта.

Провайдером (поставщиком) контракта является сервер. Потребителем контракта является клиент. Клиент запрашивает сервис у сервера. Клиент вызывает метод у провайдера. Иногда это называют посылкой сообщения от клиента к серверу. [4]

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

Комбинация объектно-ориентированного подхода и идеологии клиент-сервер вбирает в себя лучшее из двух областей:

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

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

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

Глава 3. CORBA

Первые спецификации CORBA появились в начале 90-х годов. Основной целью OMG (некоммерческая организация, Object Management Group) при разработке CORBA было создание распределенной системы, способной преодолеть большинство проблем межоперационной совместимости при интеграции сетевых приложений.

Базовая спецификация состоит из более чем семисот страниц, и более тысячи страниц описывают службы, построенные на этой основе. Различные реализации CORBA имеют собственные расширения, всё складывается из предпочтений конкретного производителя.

3.1 Глобальная архитектура

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

Рисунок 3.1.1 Глобальная архитектура CORBA

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

Кроме объектов, являющихся частями конкретных приложений, так же в модель входят средства CORBA (CORBA facilities) – это сочетания внутренних служб CORBA. CORBA facilities делятся на две группы: горизонтальные средства (horizontal facilities) и вертикальные средства (vertical facilities). Более подробная информация о группах представлена в таблице 3.1

Таблица 3.1 Группы средств CORBA

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

3.2 Объектная модель

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

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

Общая организация системы CORBA отображена на рисунке 3.2.1. Будем считать, что система CORBA организована в виде набора клиентов и серверов объектов.

Рисунок 3.2.1 Организация системы CORBA

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

С точки зрения процесса, брокер ORB сам по себе предоставляет лишь некоторые услуги:

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

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

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

В случаях, когда статически определенные интерфейсы недоступны клиенту, CORBA предоставляет клиентам интерфейс динамического обращения (Dynamic Invocation Interface, DII), который позволяет создавать запросы в ходе выполнения приложений. DII предлагает базовую операцию Invoce, которая получает в качестве параметров ссылку на объект, идентификатор метода и список входных значений, а возвращает в результате список выходных переменных, предоставленный вызывающей стороной.

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

3.3 Хранилища интерфейсов и реализаций

Хранилище интерфейсов (interface repository) предоставляется CORBA для хранения всех определений интерфейсов. Требуется это для того, чтобы во время исполнения процесс мог определить, как выглядит интерфейс, для обеспечния динамического создания запросов с обращениями.

Когда компилируется определение интерфейса, компилятор IDL назначает идентификатор хранения (repository identifier) – основное средство извлечения определения интерфейса из хранилища.

CORBA обычно предлагает также хранилище реализаций (implementation repository), которое содержит все необходимое для реализации и активизации объектов.

Хранилище реализаций тесно связано с организацией и реализацией серверов объектов. Задача адаптера объектов – активизировать объекты путем их запуска в адресном пространстве сервера таким образом, чтобы к их методам можно было обращаться. Получив ссылку на объект, адаптер объектов связывается с хранилищем реализаций, чтобы найти ту реализацию, которая требуется.[1]

3.4 Службы CORBA

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

Список служб приведен в таблице 3.4.1

Таблица 3.4.1 Службы CORBA

Служба	Описание
Служба коллекций	Средства группирования объектов в списки, очереди, множества и т. п.	Предоставляет возможность группировать объекты в списки, очереди, стеки, множества и т. д. В зависимости от природы группы имеются различные механизмы доступа. Так, например, списки можно просматривать поэлементно при помощи механизма, обычно называемого итератором. Имеются также и средства поиска объектов по заданному ключевому значению. В принципе служба коллекций близка к тому, что в объектно-ориентированных языках программирования именуется библиотекой классов.
Служба запросов	Средства для декларирования запросов к наборам объектов	Предоставляет данные для создания коллекций объектов, к которым можно обращаться, используя декларативные языки запросов. Запрос может возвращать ссылку на объект или коллекцию объектов. Служба запросов добавляет к службе коллекций возможность создания расширенных запросов. Она отличается от службы коллекций тем, что последняя предполагает возможность создания коллекций различ­ных типов.
Служба параллельного доступа	Средства обеспечения параллельного доступа к совместно используемым объектам	Предоставляет расширен­ный механизм блокировок, который клиент может применять при доступе к общим объектам. Эта служба может использоваться для реализации транзакций, которые выделяются в отдельную службу.
Служба транзакций	Простые и вложенные транзакции для вызова методов различных объектов	Позволяет клиенту определять цепочки обращений к методам нескольких объек­тов в виде единой транзакции. Эта служба поддерживает простые и вложенные транзакции.
Служба событий	Средства асинхронного взаимодействия на основе механизма событий	Обычно клиенты обращаются к методам, после чего ожидают получения результата этого обращения. Для поддержания возможности асинхронного взаимодействия CORBA предоставляет службу событий, с помощью которой клиент и объект могут прерывать работу при наступлении определен­ного события.
Служба уведомлений	Расширенные средства асинхронного взаимодействия на основе механизма событий	Дополнительные средства для асинхронного взаимодействия пре­ доставляет отдельная служба уведомлений
Служба внешних связей	Средства маршалинга и демаршалинга объектов	Занимается маршалингом объ­ектов таким образом, чтобы их можно было сохранить на диск или передать по сети. Ее можно сравнить со средствами сериализации Java, позволяющими запи­сывать объекты в поток данных в виде последовательности байтов.
Служба жизненного цикла	Средства создания, удаления, копирования и перемещения объектов	Предоставляет возможности создания, уничтожения, копирования и перемещения объектов. Ключевая концепция здесь – объект-фабрика (factory object), представляющая собой специальный объект, используемый для создания других объектов. Практика показывает, что отдельной службы требует только создание объектов. Уничтожение же, копирование и перемещение объектов часто удобнее определять внутри самих объектов. Причина – на эти операции влияет состояние объекта, то есть способ их осуществления зависит от объекта.
Служба лицензирования	Средства для присоединения к объекту лицензии	Позволяет разработчикам присоеди­нять к их объектам лицензии и поддерживать определенные правила лицензирования. Лицензии определяют права клиента на использование объекта. Так, например, лицензия, присоединенная к объекту, может указывать, что объект разрешается использовать одновременно только одному клиенту. Другая лицеи-ЗИЛ может обеспечивать автоматическую деактивацию объекта по истечении определенного времени.
Служба именования	Средства именования объектов в пределах системы	Для объектов, имеющих осмысленные имена, CORBA поддерживает отдель­ную службу именования, которая занимается отображением этих имен на идентификаторы объектов.
Служба свойств	Средства присоединения к объекту пар (атрибут, значение)	Основные средства описания объектов собра­ны в отдельной службе свойств. Эта служба позволяет клиентам ассоциировать с объектами пары (атрибут, значение). Отметим, что эти атрибуты не являются частями состояния объекта, а используются именно для его описания. Другими словами, они предоставляют информацию об объекте, не являющуюся его частью.
Служба обмена	Средства публикации и поиска служб, нужных объекту	Позволяет объектам рекламировать то, что они могут делать (посредством их интерфейсов), а клиентам производить поиск нужных им служб, используя специальный язык, поддерживающий описание ограничений.
Служба сохранности	Средства длительного хранения объектов	Содержит средства сохранения информации на диске в виде объектов хранения. Наиболее важно, что при этом предполагается прозрачность хранения – клиенту не нужно явно переда­вать данные между диском и оперативной памятью.
Служба отношений	Средства выражения отношений между объектами	Средства для явного определения отношений между двумя или более процессами предлагаются службой отношений, которая, в сущности, поддерживает организацию объектов в соответствии с концептуальной схемой, подобно схемам отношений между объектами в базах данных.
Служба защиты	Механизмы создания защищенных каналов, авторизации и аудита	Реализация этой службы напоминает системы защиты SESAME и Kerberos. Служба защиты в CORBA поддерживает средства аутентификации, авторизации, аудита, защищенной связи и администрирования.
Служба времени	Предоставление текущего времени с заданной ошибкой	Возвращает текущее время с некоторой заданной ошибкой.

3.5 Связь

В CORBA предусмотрено три модели связи или модели обращения к объектам, различающиеся по типам запроса: синхронный, односторонний, отложенный синхронный. Обобщим эти модели в таблице 3.5.1

Таблица 3.5.1 Модели обращений

Тип запроса	Семантика при ошибках	Описание
Синхронный	Максимум однажды	Отправитель блокируется до получения ответа или возникновения исключения
Односторонний	Доставка «с максимальными усилиями»	Отправитель продолжает работу, немедленно не ожидая ответа от сервера
Отложенный синхронный	Максимум однажды	Отправитель продолжает работу немедленно и может быть позднее заблокирован до получения ответа

3.6 Передача сообщений

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

3.6.1 Модель обратного вызова

В модели обратного вызова (callback model) клиент представляет собой объект, реализующий интерфейс, в котором содержатся методы обратного вызова. Базовая коммуникационная система может вызвать эти методы для передачи результата асинхронного обращения. Важная особенность этой модели состоит в том, что асинхронные обращения к методу не влияют на исходную реализацию объекта. Другими словами, преобразовать исходное синхронное обращение в асин­хронное – задача клиента; сервер делает обычный (синхронный) вызов. Построение асинхронного обращения выполняется в два этапа. Сначала исходный интерфейс, реализуемый объектом, заменяется двумя другими, реализуемыми исключительно программным обеспечением клиента. Один из интерфейсов содержит спецификацию методов, которые может вызывать клиент. Ни один из этих методов не возвращает значений и не имеет выходных параметров. Второй интерфейс – это интерфейс обратного вызова. Он содержит методы, которые могут быть вызваны брокером ORB клиента для передачи результатов соответствующего метода вызвавшему его клиенту для всех операций исходного интерфейса. Схема описанной модели показана на рисунке 3.6.1.1

Рисунок 3.6.1.1 Модель обратного вызова CORBA для асинхронного обращения к методам

3.6.2 Модель опроса

Согласно модели опроса (polling model) клиенту предоставляется набор операций для опроса своего брокера ORB на предмет наличия поступивших результатов. Как и в модели обратного вызова, за преобразование синхронного обращения к методу в асинхронное отвечает клиент. Большую часть работы можно выполнять автоматически, отталкиваясь от спецификации соответствующего метода в исходном интерфейсе, который реализован в объекте.[1]

Схема описанной модели показана на рисунке 3.6.2.1.

Рисунок 3.6.2.1. Модель опроса CORBA для асинхронного обращения к методам

3.7 Совместимость

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

Обратившись к рисунку 3.2.1 между клиентом и сервером связь обслуживается по стандартному протоколу, который в CORBA известен как обобщенный протокол обмена между ORB (General Inter-ORB Protocol, GIOP). [1]

Семантический уровень – IIOP (Internet Inter-ORB Protocol – Меж-ORB Протокол Интернет) используется для преобразования GIOP в TCP/IP. Такая комбинация GIOP и IIOP необходима для поддержки внешнего взаимодействия. Все поставщики ORB обеспечивают внешнюю совместимость этого протокола.

Однако один протокол не может использоваться для всех целей, поэтому существует возможность преобразования GIOP в другие протоколы (такие как IPX или SNA).

В случае, когда один набор интерфейсов не может обеспечить выполнение всех задач, в поле зрения попадают ESIOP (Environment Specific Inter-ORB Protocols – Inter-ORB протоколы, определяемые средой). Одним из ESIOP является протокол, базирующийся на DCE (distributed computing environment). В случае среды, когда протокол DCE может использоваться, DCE-CIOP (DCE Common Inter-ORB Protocol – Общий Inter-ORB Протокол DCE) играет роль склейки между ESIOP и TCP.[4]

3.8 Отказоустойчивость

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

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

Рисунок 3.8.1 Пример архитектуры отказоустойчивой системы CORBA

В этой архитектуре имеется несколько важных элементов. Наиболее важен менеджер репликации (replication manager), который отвечает за создание и управление группой реплицированных объектов. Менеджер репликации, кроме того, отвечает за замену реплики в случае ее отказа, гарантируя, таким образом, что число реплик не опустится ниже определенного минимума.

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

ЗАКЛЮЧЕНИЕ

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

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

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

1. Танненбаум Э., ван Стеен М. Распределенные системы. Принципы и парадигмы: – СПб.: Питер, 2003. – 877 с.
2. Интуит. Кросс-платформенные и многозвенные технологии. Лекция 2: Технология CORBA

https://www.intuit.ru/studies/courses/571/427/lecture/9705 (Дата обращения 01.03.2019)

1. Александр Цимбал. Сравнительный анализ технологий CORBA и COM http://www.interface.ru/fset.asp?Url=/borland/corbacom.htm (Дата обращения 01.03.2019)
2. http://www.interface.ru/fset.asp?Url=/borland/corba2.htm (Дата обращения 09.03.2019)
3. http://www.k-press.ru/cs/1998/4/corba/corba.asp (Дата обращения 01.04.2019)