Файл: "Технология CORBA".pdf

Хранилище интерфейсов (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 изменили подход к реализации проекта на стремление к формализации как проекта в целом, так и его составных частей на как можно более высоком уровне абстракции. Это означает, что большая часть работы, требующей интеллектуальных усилий, должна быть выполнена не на этапе кодирования с использованием того или иного конкретного языка программирования, а на этапе создания спецификации проекта на специальном языке описания его составных частей.

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

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

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

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