Таненбаум Э. Распределенные системы. Принципы и парадигмы

Подождите немного. Документ загружается.

9.1.

CORBA 541

Подобно многим другим системам, родившимся в недрах комитетов, CORBA

перенасыщена описаниями разнообразных свойств и средств. Базовая специ-

фикация состоит из более чем 700 страниц, и еще 1200 страниц описывают раз-

личные службы, построенные на этой основе. Естественно, каждая реализация

CORBA имеет собственные расширения, поскольку всегда в спецификацию не

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

мер CORBA вновь иллюстрирует тот факт, что создание распределенной систе-

мы

—

дело безумно сложное.

Мы не станем обсуждать все, что включено в CORBA, взамен сосредото-

чившись только на тех аспектах, которые имеют значение для распределенных

систем и отличают CORBA от других распределенных систем объектов. Спе-

цификации CORBA можно найти в

[331],

а также по адресу http://www.omg.org.

Отличный обзор CORBA приведен в

[475].

А в [359] предлагается описание да-

же более детальное, чем исходная спецификация. Информацию по созданию

приложений на C++ с использованием CORBA можно найти в [25, 198].

9.1.1.

Обзор

Глобальная архитектура CORBA восходит к модели OMG, описанной в

[324].

Эта модель, приведенная на рис. 9.1, содержит четыре группы архитектурных

элементов, связанных с так называемым

брокером объектных

запросов (Object

Request

Broker,

ORB). ORB образует ядро любой распределенной системы CORBA;

он отвечает за поддержание связи между объектами и их клиентами, скрывая

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

системах ORB реализуется в виде множества библиотек, которые компонуются

приложениями клиента и сервера, предоставляя им базовые службы связи. Поз-

же,

когда мы будем обсуждать объектную модель CORBA, мы еще вернемся

к ORB.

Прикладные

объекты

Вертикальные

средства

(зависят

от конкретной

задачи)

Горизонтальные

средства

(общего

назначения)

Общие

объектные

службы

Брокер объектных запросов

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

Кроме объектов, которые являются частями конкретных приложений, в мо-

дель также входят так называемые

средства

CORBA (CORBA facilities), которые

представляют собой сочетания внутренних служб CORBA (которые мы обсудим

позже) и делятся на две различные группы.

Горизонтальные средства (horizontal

facilities) представляют собой высокоуровневые службы общего назначения, ко-

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

службы в настоящее время обслуживают пользовательский интерфейс, управле-

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

ние информацией, управление системой и управление задачами (которое требу-

ется для определения систем рабочих потоков). Вертикальные средства {vertical

facilities)

—

это высокоуровневые службы, предназначенные для конкретных пред-

метных областей, таких как электронная коммерция, банковское дело, производ-

ство и т. д.

Мы не будем детально рассматривать прикладные объекты и средства CORBA,

а сосредоточимся на базовых службах и ORB.

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

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

в главе 2. В этой модели реализация объектов происходит в адресном пространст-

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

что объекты должны быть реализованы исключительно как удаленные. Однако

фактически все системы на базе CORBA поддерживают только эту модель. Кро-

ме того, спецификации часто рекомендуют, чтобы распределенные объекты в

CORBA былР1 реализованы в форме удаленных объектов. Позднее, при обсужде-

нии объектной модели Globe, мы покажем, каким образом CORBA может в прин-

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

Объекты и службы описываются при помощи языка определения интерфей-

сов {Interface Definition Language, IDL) CORBA. Язык IDL в CORBA похож на

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

синтаксис описания методов и их параметров. Описать семантику IDL для CORBA

невозможно. Интерфейс — это набор методов, и объект сам определяет, какие

интерфейсы он реализует.

Спецификации интерфейса можно задать только при помощи IDL. Как мы

увидим в дальнейшем, в таких системах, как Distributed СОМ и Globe, интер-

фейсы определяются на более низких уровнях, в виде таблиц. Эти так называе-

мые бинарные интерфейсы {binary interfaces) по самой своей природе не зависят

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

правила отображения спецификации на языке IDL на существующий язык про-

граммирования. В настоящее время такие правила существуют для множества

языков, включая С, C++, Java, Smalltalk, Ada и COBOL.

Считая, что система CORBA организована в виде набора клиентов и серверов

объектов, ее общую организацию можно понять из рис. 9.2.

Основой каждого процесса в CORBA на клиенте или на сервере является

ORB.

ORB лучше всего рассматривать как систему времени исполнения, кото-

рая отвечает за базовые функции связи между клиентом и объектом. Эти базо-

вые функции связи гарантируют обращение к серверу объектов и возвращение

клиенту ответов сервера.

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

торые услуги. Одна из этих услуг

—

обработка ссылок на объекты. Вид этих ссы-

лок обычно завргсит от конкретного брокера ORB. Поэтому любой брокер ORB

предоставляет операции для маршалинга и демаршалинга ссылок на объекты в

ходе обмена между процессами, а также операции для сравнения ссылок. Ссыл-

ки на объекты мы обсудим чуть позже.

9.1.

CORBA 543

Машина клиента

Приложение клиента

Статический

IDL-

заместитель

Интерфейс

динамического

обращения

Интерфейс

ORB

ORB клиента

Локальная ОС

Машина сервера

Реализация объекта

Адаптер

объектов

Скелетон

Динамический

интерфейс

каркаса

ORB сервера

Локальная ОС

Сеть

Рис. 9.2. Общая организация системы CORBA

Другие операции, предоставляемые брокером ORB,

—

начальный поиск дос-

тупных для процесса служб. Обычно он предоставляет данные для получения

начальной ссылки на объект, реализующий конкретную службу CORBA. Так,

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

знал, как на нее сослаться. Подобную задачу инициализации равно необходимо

решать и для других служб.

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

хоть что-нибудь еще. Обычно они видят только заглушки, обрабатывающие об-

ращения к соответствующим объектам. Клиентское приложение имеет замести-

тель,

предназначенный для реализации того же интерфейса, который использует

объект. Как мы показали в главе 2, заместитель — это клиентская заглушка,

единственное назначение которой

—

выполнить маршалинг (то есть упаковку)

обращения в запрос и переслать этот запрос серверу. После получения ответа

с сервера выполняется его демаршалинг (распаковка) и передача клиенту.

Отметим, что интерфейс между заместителем и ORB не должен быть стан-

дартизован. Поскольку CORBA предполагает, что все интерфейсы определены

на языке IDL, реализации CORBA предоставляют разработчикам компилятор

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

ентским и серверным брокерами ORB.

Однако бывают случаи, когда статически определенные интерфейсы просто

недоступны клиенту. В этом случае во время исполнения необходимо выяснить,

как выглядит интерфейс для конкретного объекта, чтобы иметь возможность по-

следовательно реализовать запрос с обращением к этому объекту. Для этой цели

CORBA предоставляет клиентам

интерфейс динамического обращения

{Dynamic

Invocation

Interface, DII), который позволяет создавать запросы в ходе выполне-

ния приложений. Так, в частнострт, DH предлагает базовую операцию Invoce, ко-

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

и список входных значений, а возвращает в результате список выходных пере-

менных, предоставленный вызывающей стороной.

Серверы объектов организованы в соответствии с тем описанием, которое мы

давали в главе 3. Как видно из рис. 9.2, система CORBA предоставляет адаптер

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

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

Реальный демаршалинг (распаковка данных запроса) на стороне сервера выпол-

няется заглушками, которые в CORBA называют скелетонами, однако возможно

также, что реализация объекта берет демаршалинг на себя. Как и в случае клиен-

та, серверные заглушки также могут компилироваться статически из описания

на языке IDL или иметь вид базового динамического скелетона. При использо-

вании динамического скелетона объект должен содержать правильную реализа-

цию обращения к доступным клиенту функциям. Чуть ниже мы еще вернемся к

серверам объектов.

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

Чтобы обеспечить динамическое создание запросов с обращениями, необходимо,

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

CORBA предоставляет хранилище

интерфейсов

(interface

repository),

в котором

хранятся все определения интерфейсов. Во многих системах хранилище интер-

фейсов реализуется в виде отдельного процесса, имеющего стандартный интер-

фейс сохранения и выдачи определений интерфейсов. Хранилище интерфейсов

также может рассматриваться как часть CORBA, содействующая работе механиз-

мов проверки типов во время исполнения.

Когда компилируется определение интерфейса, компилятор IDL назначает

идентификатор

хранения

{repository

identifier) этого интерфейса. Этот иденти-

фикатор

—

основное средство извлечения определения интерфейса из хранили-

ща. Идентификатор по умолчанию порождается из имени интерфейса и его ме-

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

Если необходима уникальность, стандартный идентификатор можно изменить.

Учитывая, что все определения интерфейсов хранятся в хранилище интер-

фейсов в соответствии с их синтаксисом на языке IDL, становится возможным

организовать каждое определение стандартным образом. (В терминологии баз

данных это означает, что концептуальная схема, ассоциированная с хранилищем

интерфейсов, одинакова для всех хранилищ.) В результате хранилища интерфей-

сов в системах CORBA имеют одинаковые операции навигации среди определе-

ний интерфейсов.

Кроме хранилища интерфейсов система CORBA обычно предлагает также

хранилище

реализаций

{implementation

repository).

Концептуально хранилище реа-

лизаций содержит все необходимое для реализации и активизации объектов. По-

скольку подобная функциональность изначально связана с самим брокером ORB

и базовой операционной системой, создать стандартную реализацию было бы за-

труднительно.

Хранилище реализаций, кроме того, тесно связано с организацией и реализа-

цией серверов объектов. Как мы объясняли в главе

задача адаптера объектов

—

активизировать объекты путем их запуска в адресном пространстве сервера та-

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

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

реализацию, которая требуется.

Так, например, хранилище реализаций может поддерживать таблицу, указы-

вающую на возможность запуска нового сервера, и номер порта, который может

9.1.C0RBA

545

быть отведен новому серверу для прослушивания конкретным объектом. Храни-

лище, кроме того, может иметь информацию об исполняемом файле (то есть

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

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

возникнуть, достаточно будет скомпоновать существующий сервер с некоторой

библиотекой, содержащей указанный метод или объект. И снова соответствую-

щая информация может содержаться в хранилище реализаций. Эти два примера

иллюстрируют, насколько в действительности тесно связано хранилР1ще с броке-

ром ORB и платформой, на которой он работает.

Службы CORBA

Важной частью структурной модели CORBA является набор служб CORBA.

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

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

пы служб CORBA очень похожи на типы служб операционных систем. Полный

список служб CORBA приведен в табл. 9.1. К сожалению, не всегда можно про-

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

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

позже сравнить их со службами DCOM и Globe.

Таблица

9.1.

Службы CORBA

Служба

Описание

Служба коллекций

Служба запросов

Служба параллельного

доступа

Служба транзакций

Служба событий

Служба уведомлений

Служба внешних связей

Служба жизненного

цикла

Служба лицензирования

Служба именования

Служба свойств

Служба обмена

Служба сохранности

Служба отношений

Служба защиты

Служба времени

Средства группирования объектов в списки, очереди,

множества и т. п.

Средства для декларирования запросов к наборам объектов

Средства обеспечения параллельного доступа к совместно

используемым объектам

Простые и вложенные транзакции для вызова методов различных

объектов

Средства асинхронного взаимодействия на основе механизма

событий

Расширенные средства асинхронного взаимодействия

на основе механизма событий

Средства маршалинга и демаршалинга объектов

Средства создания, удаления, копирования и перемещения

объектов

Средства для присоединения к объекту лицензии

Средства именования объектов в пределах системы

Средства присоединения к объекту пар (атрибут, значение)

Средства публикации и поиска служб, нужных объекту

Средства длительного хранения объектов

Средства выражения отношений между объектами

Механизмы создания защищенных каналов, авторизации

и аудита

Предоставление текущего времени с заданной ошибкой

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

Служба коллекций

{collection

service) предоставляет возможность группиро-

вать объекты в списки, очереди, стеки, множества и т. д. В зависимости от при-

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

можно просматривать поэлементно при помощи механизма, обычно называемо-

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

вому значению. В принципе служба коллекций близка к тому, что в объектно-

ориентированных языках программирования именуется библиотекой классов.

Имеется также и отдельная

служба запросов {query

service),

предоставляющая

данные для создания коллекций объектов, к которым можно обращаться, исполь-

зуя декларативные языки запросов. Запрос может возвращать ссылку на объект

или коллекцию объектов. Служба запросов добавляет к службе коллекций воз-

можность создания расширенных запросов. Она отличается от службы коллек-

ций тем, что последняя предполагает возможность создания коллекций различ-

ных типов.

Служба параллельного доступа {concurrency service)

предоставляет расширен-

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

объектам. Эта служба может использоваться для реализации транзакций, кото-

рые выделяются в отдельную службу.

Служба

транзакций

{transaction

service)

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

тов в виде единой транзакции. Эта служба поддерживает простые и вложенные

транзакции.

Обычно клиенты обращаются к методам, после чего ожидают получения ре-

зультата этого обращения. Для поддержания возможности асинхронного взаи-

модействия CORBA предоставляет службу

событий

{event

service),

с помощью

которой клиент и объект могут прерывать работу при наступлении определен-

ного события. Дополнительные средства для асинхронного взаимодействия пре-

доставляет отдельная

служба

уведомлений {notification sewice). Эту службу мы

детально обсудим чуть позднее.

Служба

внешних связей

{extemalization service)

занимается маршалингом объ-

ектов таким образом, чтобы их можно было сохранить на диск или передать по

сети. Ее можно сравнить со средствами сериализации Java, позволяющими запи-

сывать объекты в поток данных в виде последовательности байтов.

Служба

э/сизненного

цикла {life cycle service) предоставляет возможности

создания, уничтожения, копирования и перемещения объектов. Ключевая кон-

цепция здесь

— объект-фабрика

{factory object), представляющая собой специ-

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

[157].

Практика

показывает, что отдельной службы требует только создание объектов. Уничто-

жение же, копирование и перемещение объектов часто удобнее определять внут-

ри самих объектов. Причина

—

на эти операции влияет состояние объекта, то

есть способ их осуществления зависит от объекта.

Служба

лицензирования

{licensing service)

позволяет разработчикам присоеди-

нять к их объектам лицензии и поддерживать определенные правила лицензи-

рования. Лицензии определяют права клиента на использование объекта. Так,

например, лицензия, присоединенная к объекту, может указывать, что объект

разрешается использовать одновременно только одному клиенту. Другая лицеи-

9.1.

CORBA 547

ЗИЛ

может обеспечивать автоматическую деактивацию объекта по истечении оп-

ределенного времени.

Для объектов, имеющих осмысленные имена, CORBA поддерживает отдель-

ную

службу

именования

(naming

service),

которая занимается отображением этих

имен на идентификаторы объектов. Основные средства описания объектов собра-

ны в отдельной

службе свойств (property

service).

Эта служба позволяет клиентам

ассоциировать с объектами пары

(атрибут,

значение).

Отметим, что эти атрибуты

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

Другими словами, они предоставляют информацию об объекте, не являющуюся

его частью. С этими двумя службами связана

служба обмена (trading

service),

ко-

торая позволяет объектам рекламировать то, что они могут делать (посредством

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

специальный язык, поддерживающий описание ограничений.

Отдельная

служба сохранности (persistence service)

содержит средства сохра-

нения информации на диске в виде объектов хранения. Наиболее важно, что при

этом предполагается прозрачность хранения

—

клиенту не нужно явно переда-

вать данные между диском и оперативной памятью.

Перечисленные службы не предоставляют средств для явного определения

отношений между двумя или более процессами. Подобные средства предлагают-

ся

службой отношений (relationship

service),

которая, в сущности, поддерживает

организацию объектов в соответствии с концептуальной схемой, подобно схемам

отношений между объектами в базах данных.

Защита обеспечивается

службой защиты (security

service).

Реализация этой служ-

бы напоминает системы защиты SESAME и Kerberos. Служба защиты в CORBA

поддерживает средства аутентификации, авторизации, аудита, защищенной свя-

зи и администрирования. Ниже мы рассмотрим вопросы защиты более детально.

И, наконец, CORBA поддерживает

слуэн:бу времени

(time

service),

возвращаю-

щую текущее время с некоторой заданной ошибкой.

Как написано в

[359],

службы CORBA разрабатывались с использованием

объектной модели CORBA в качестве базовой. Это означает, что все службы

описаны на языке IDL для CORBA и что между описанием и реализацией ин-

терфейсов существует разница. Другой важный принцип построения состоит

том,

что службы должны быть просты и минимальны по объему. Далее мы об-

судим некоторые из этих служб более детально.

9.1.2. Связь

Исходно CORBA имеет простую модель связи: клиент обращается к методу объ-

екта и ожидает ответа. Эта модель разрабатывалась так, чтобы быть как можно

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

нительные методы взаимодействия.

связи с этим мы особо рассмотрим обраще-

ние к средствам в CORBA, обсудив также альтернативы подобного обращения к

объектам. Как мы увидим, расширения базовой модели обращения к объекту вы-

зываются необходимостью поддержания асинхронного взаимодействия. Эта не-

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

сообщений, которые мы обсуждали в главе 2.

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

Модели обращения к объектам

По умолчанию, когда клиент обращается к объекту, он посылает запрос соответ-

ствующему серверу объектов и блокируется до получения ответа. При отсутст-

вии ошибок эта семантика полностью соответствует обычному обращению к ме-

тодам, когда вызывающая и вызываемая стороны находятся в одном адресном

пространстве.

Однако при наличии ошибок все усложняется. В случае описанного выше

синхронного обращения клиент в результате получает исключение, указываю-

щее на незаконченность обращения. CORBA определяет, что в этом случае обра-

щение следует семантике «максимум однажды», которая предполагает, что вызы-

ваемый метод будет выполнен один раз или не будет выполнен вообще. Отметим,

что реализация должна поддерживать эту семантику.

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

даться ответа. Если возвращается правильный результат, CORBA гарантирует,

что метод был выполнен ровно один раз. Однако в том случае, когда ответ не

требуется, для клиента лучше просто вызвать метод и как можно быстрее про-

должить выполнение. Этот тип обращения соответствует асинхронному вызову

RPC,

который мы обсуждали в главе 2.

В CORBA такой тип асинхронных обращений именуется

односторонним

за-

просом

{one-way

request).

Метод может быть определен как односторонний толь-

ко в том случае, если он не возвращает результата. Однако в отличие от гаранти-

рованной доставки асинхронных вызовов RPC, односторонние запросы CORBA

предполагают наличие только службы доставки «с максимальными усилиями»

{best effort

delivery).

Другими словами, отправитель не получает никаких гаран-

тий того, что запрос будет доставлен серверу объектов.

Кроме односторонних запросов CORBA поддерживает также механизм так

называемого

отлооюенного синхронного запроса {deferred synchronous

request).

Та-

кой запрос, который фактически является вариантом одностороннего запроса,

позволяет серверу возвращать результат клиенту асинхронно. После того как

клиент посылает серверу свой запрос, он может, не дожидаясь ответа, сразу же

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

вительности доставлен серверу или нет.

Эти три различных модели обращения обобщены в табл. 9.2.

Таблица 9.2. Модели обращений в CORBA

Тип запроса Семантика Описание

при ошибках

Синхронный Максимум однажды Отправитель блокируется до получения

ответа или возникновения исключения

Односторонний Доставка Отправитель продолжает работу немедленно,

«с максимальными не ожидая ответа от сервера

усилиями»

Отложенный Максимум однажды Отправитель продолжает работу немедленно

синхронный и может быть позднее заблокирован

до получения ответа

9.1.C0RBA 549

Службы событий и уведомлений

Хотя модели обращений, предлагаемые CORBA, вполне покрывают задачи связи

в распределенной системе объектов, чувствуется, что одних обращений к объек-

там недостаточно. В частности, необходимо наличие службы, которая должна

просто сигнализировать о наступлении событий. Клиенты, узнав об этом собы-

тии, смогут выполнить соответствующие действия.

Результатом является определение

службы

событий {event

service).

Базовая

модель событий в CORBA очень проста. Каждое событие ассоциируется с еди-

ничным элементом данных, обычно представленным в виде ссылки на объект

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

поставщик {supplier)

и получает

потребитель

{consumer).

События доставляются

по каналу событий {event

channel)^

логически связывающего поставщика и по-

требителя, как показано на рис. 9.3.

Продвижение событий потребителям

[потребитель!

[потребитель]^ ^

Канал

событий

Поставщик)

j Поставщик!

Поставщик

Рис. 9.3. Логическая организация поставщиков и потребителей событий

в соответствии с моделью продвижения

На рисунке показана так называемая модель

продвижения

{push model). Со-

гласно этой модели при возникновении определенной ситуации поставщик гене-

рирует событие и продвигает его через канал событий, по которому событие до-

ставляется потребителям. Модель продвижения напоминает асинхронный режим

работы, который часто ассоциируют с событиями. На практике потребители пас-

сивно ожидают прихода события, полагая, что при возникновении события их

работа будут так или иначе прервана.

Альтернативная модель, также поддерживаемая CORBA,

—

это

модель

извле-

чения {pull model), продемонстрированная на рис. 9.4. Согласно этой модели по-

требители опрашивают канал событий, проверяя, не произошло ли ожидаемое

событие. Канал событий, в свою очередь, опрашивает поставщиков событий.

Опрос поставщиков

ожидании нового события

Потребитель]-

[Потребительг

Канал

событий

Поставщик

Рис. 9.4. Логическая организация поставщиков и потребителей событий

в соответствии с моделью извлечения

Хотя служба событий имеет простой и надежный способ распространения со-

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

тий необходимо, чтобы поставщики и потребители были соединены с каналом

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

событий. Это также означает, что если потребитель соединится с каналом после

того,

как событие произошло, это событие будет потеряно. Другими словами,

служба сообщений С ORB А не обеспечивает сохранности событий.

Очень важно, что потребители не в состоянии предпринять каких-либо мер

для фильтрации событий. Любое событие, в принципе, пересылается всем потре-

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

отдельные каналы событий для каждого из этих типов. Средства фильтрации

имеются в расширении

[325],

известном под названием службы уведомлений

{notification service). Помимо всего прочего эта служба содержит средства для

предотвращения распространения событий, в которых не заинтересован ни один

из потребителей.

И, наконец, распространение событий изначально ненадежно. Спецификация

CORBA указывает, что по вопросу доставки событий никаких гарантий не дает-

ся.

Как мы говорили в главе 2, существуют приложения, для которых надежная

доставка событий очень важна. Для таких приложений служба событий CORBA

не подходит и требуются другие способы взаимодействия.

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

Любое взаимодействие в CORBA, которое мы обсуждали до сих пор,

—

нере-

зидентное. Это означает, что сообщения сохраняются в базовых системах связи

лишь в процессе выполнения как отправителя, так и получателя. Как мы говори-

ли в главе 2, существует множество приложений, которые требуют сохранной

связи, то есть такой, при которой сообщение хранится в системе до тех пор, пока

не будет доставлено. При сохранной связи не имеет значения, выполняется или

нет после отправки сообщения отправитель или получатель, в любом случае со-

общение будет храниться столько, сколько необходимо.

Хорошо известна такая модель сохранной связи, как очереди сообщений.

CORBA поддерживает эту модель в виде дополнительной службы сообщений

(messaging

service).

Обмен сообщениями в CORBA отличается от других систем

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

сообщений вынуждены были соблюсти условие обязательности обращений к

объектам при любом взаимодействии. В случае обмена сообщениями эти ограни-

чения привели к появлению двух дополнительных видов асинхронного обраще-

ния к методам.

В модели

обратного

вызова

{callback

model) клиент представляет собой объ-

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

Базовая коммуникационная система может вызвать эти методы для передачи

результата асинхронного обращения. Важная особенность этой модели состоит

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

объекта. Другими словами, преобразовать исходное синхронное обращение в асин-

хронное

—

задача клиента; сервер делает обычный (синхронный) вызов.

Построение асинхронного обращения выполняется в два этапа. Сначала ис-

ходный интерфейс, реализуемый объектом, заменяется двумя другими, реализу-

емыми исключительно программным обеспечением клиента. Один из интерфей-

сов содержит спецификацию методов, которые может вызывать клиент. Ни один