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

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

9.1.C0RBA 551

из этих методов не возвращает значений и не имеет выходных параметров. Вто-

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

—

это интерфейс обратного вызова. Он содержит методы, кото-

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

ветствующего метода вызвавшему его клиенту для всех операций исходного

интерфейса.

В качестве примера рассмотрим объект, реализующий простой интерфейс

с единственным методом:

int adddn 1nt i. in 1nt j. out int k):

Предположим, что этот метод (который мы описали на IDL для CORBA) по-

лучает два неотрицательных целых числа

и j и возвращает 1+j в выходном пара-

метре к. Операция должна возвращать -1 в случае неудачного завершения. Пре-

образование исходного (синхронного) обращения к методу в асинхронное путем

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

нашей задачи мы предпочли удобство имен строгим правилам именования [331]):

void sendcb_add(in int i. in int j); // Вызывается клиентом

void replycb__add(in int ret__val. in int k); // Вызывается клиентским ORB

В действительности все выходные параметры спецификации исходного мето-

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

раметры операции обратного вызова. Точно так же если в исходном методе опре-

делялось возвращаемое значение, это значение передается в операцию обратного

вызова в качестве входного параметра.

Второй шаг заключается в простой компиляции созданного интерфейса. В ка-

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

зывать метод sendcb^add. Однако клиент должен сам предоставить реализацию

интерфейса обратного вызова, содержащего, в нашем примере, метод replycb__add.

Отметим, что эти изменения не влияют на реализацию объекта на сервере. Опи-

санную модель обратного вызова иллюстрирует рис. 9.5.

Вызов,

выполняемый

приложением

4. Вызов,

выполняемый

брокером ORB

3. Ответ сервера

Запрос к серверу

Рис. 9.5. Модель обратного вызова CORBA

для

асинхронного обращения к методам

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

опроса (polling model). Согласно этой модели клиенту предоставляется набор

операций для опроса своего брокера ORB на предмет наличия поступивших

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

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

обращения к методу в асинхронное отвечает клиент. И снова большую часть ра-

боты можно выполнять автоматически, отталкиваясь от спецификации соответ-

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

Рассмотрим вновь наш пример. Метод add превратится в следующие два опи-

сания методов (и снова для удобства мы используем свои правила именования):

void sendpoll_add(in 1nt 1. in 1nt j): // Вызывается клиентом

void replypoll_add(out int ret_val. out int k); // Тоже вызывается клиентом

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

зова состоит в том, что метод replypoll^add реализуется клиентским брокером

ORB.

Эта реализация может быть автоматически сгенерирована компилятором

IDL. Модель опроса приведена на рис. 9.6. И вновь мы считаем нужным отме-

тить,

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

ких изменений.

Вызов,

выполняемый

приложением

Клиентское приложение

Заместитель

клиента

ORB

клиента

Интерфейс

опроса

-4—

Вызов,

выполняемый

приложением

Ответ сервера

Запрос к серверу

Рис. 9.6. Модель опроса CORBA

для

асинхронного обращения к методам

В описанных здесь моделях мы не учли тот факт, что сообщения, пересылае-

мые между клиентом и сервером, в том числе и ответы на асинхронные обраще-

ния, в случае неработоспособности клиента или сервера сохраняются базовой

системой. К счастью, большинство моментов, связанных с сохранностью связи,

не оказывают влияния на эти модели асинхронных обращений. Все, что нам не-

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

—

это разрешить

временное хранение сообщений (будь то обращения или ответы) до момента

доставки. Этот подход, описанный в

[331],

аналогичен системе очередей сообще-

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

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

Ранние версии CORBA отдавали решение многих вопросов на откуп производи-

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

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

тов.

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

случае, если клиент и сервер используют один и тот же брокер ORB.

Эта проблема совместимости была решена путем введения стандартизованно-

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

версальным способом создания ссылок на объекты. Если вернуться к рис. 9.2,

9.1.C0RBA 553

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

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

обобщенный протокол

обмена между

ORB

{General

Inter-ORB

Protocol,

GIOP).

GIOP

—

это на самом деле заготовка (каркас) протокола. Предполагается, что

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

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

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

которые другие. Нас не особенно удивляет, что TCP удовлетворяет всем этим

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

Реализация GIOP поверх TCP называется

Интернет-протоколом обмена между

ORB

{Internet Inter-ORB

Protocol,

ПОР).

Протокол GIOP (включая ПОР и другие реализации GIOP) поддерживает

восемь типов сообщений, которые перечислены в табл. 9.3. Два наиболее важных

типа сообщений

—

это Request и Reply, которые вместе образуют часть реализа-

ции обращений к удаленным методам.

Таблица 9.3. Типы сообщений GIOP

Тип сообщения Источник Описание

Request Клиент

Reply Сервер

LocateRequest Клиент

LocateReply Сервер

Cancel

Request Клиент

CloseConnectlon Оба

MessageError Оба

Fragment Оба

Содержит обращение

Содержит отклик на обращение

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

Содержит информацию о местоположении объекта

Указывает на то, что клиент более не ожидает ответа

Указывают на завершение соединения

Содержат информацию об ошибке

Часть (фрагмент) более длинного сообщения

Сообщение Request содержит запрос, полученный после завершения марша-

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

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

ловок. Каждое сообщение Request также содержит собственный идентификатор

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

Сообщение Reply содержит возвращаемые значения и выходные параметры

(также подвергнутые маршалингу), ассоциируемые с ранее вызванным методом.

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

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

нии Request.

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

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

Такому запросу соответствует посылка сообщения LocateRequest. Хранилище реа-

лизаций отвечает на этот запрос посылкой сообщения LocateReply, которое обыч-

но идентифицирует текущий сервер объекта, к которому можно обратиться.

Сообщение

Cancel

Request может быть послано клиентом серверу в том случае,

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

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

LocateRequest. Отмена запроса означает, что клиент не намерен более ждать от-

вета сервера. Клиент может отменить посланный запрос по различным причи-

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

Важно отметить, что отмена запроса не означает, что соответствующее обраще-

ние вообще не будет выполнено. Справляться с ситуацией должно приложение

клиента.

В GIOP клиент всегда устанавливает соединение с сервером сам. Серверы

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

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

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

не сообщение CloseConnection.

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

этом сообщением MessageError. Это сообщение содержит заголовок сообщения

GIOP,

вызвавшего ошибку. Такой же подход принят в сообщениях ICMP прото-

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

что-то идет не так. В этом случае заголовок IP-пакета, вызвавшего ошибку, воз-

вращается в форме данных сообщения ICMP.

И, наконец, GIOP позволяет разбивать различные сообщения с запросами

и ответами на

части.

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

ентом и сервером больших объемов данных. Отдельные фрагменты пересылают-

ся в виде специальных сообщений Fragment, определяющих исходное сообщение

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

9.1.3. Процессы

CORBA выделяет два типа процессов

—

клиентские и серверные. Одна из основ-

ных задач CORBA

—

сделать клиентские приложения как можно проще. Базовая

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

существующих служб, реализованных на серверах.

Серверы, со своей стороны, изначально открыты для различных реализаций и

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

объектов. К сожалению, эта минимальная поддержка также приводит к пробле-

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

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

объектов. Ниже мы подробно рассмотрим клиентское и серверное программное

обеспечение CORBA.

Клиенты

Как говорилось ранее, клиентское программное обеспечение CORBA сведено к

минимуму. Спецификация объекта на языке IDL просто компилируется в замес-

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

в сообщения Request протокола ПОР, а затем

—

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

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

звавшему метод клиенту.

9.1.C0RBA 555

Заместители в CORBA не выполняют других задач, кроме соединения кли-

ентских приложений с соответствующим брокером ORB. Вместо того чтобы ге-

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

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

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

лизации своих интерфейсов на стороне клиента, он должен либо предоставить

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

да разработчикам, вооруженным компилятором IDL. Так, например, реализация

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

специфическую для объекта стратегию кэширования на стороне клиента. Разу-

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

реносимости и прозрачности распространения.

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

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

поддержку. Например, вместо того чтобы предлагать объекту кэширование, реали-

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

ширование обычным образом выполнит клиентский брокер ORB. И вновь долж-

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

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

пилятором IDL вместе с существующим клиентским брокером ORB, который не

требовал бы адаптации клиентского программного обеспечения. В CORBA эта

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

хватчик {interceptor) —

это механизм перехвата обращений на пути от клиента к

серверу и при необходимости их изменения «на лету». В сущности, перехват-

чик

—

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

серверу и соответствующим образом перерабатывает ответное послание сервера.

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

альности будет активизирован, зависит от объекта или сервера, указанного в за-

просе.

Перехватчик в CORBA может находиться на одном из двух логических уров-

ней, что показывает рис. 9.7. Перехватчик

уров}1Я

запросов (request-level inter-

ceptor)

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

До того как запрос попадет в ORB, он пройдет через перехватчик, который мо-

жет модифицировать этот запрос. Со стороны сервера перехватчик уровня за-

просов располагается между ORB и адаптером объекта.

В противоположность этому

перехватчик

уровня

сообщений (message-level

in-

terceptor)

располагается между ORB и базовой сетью. Типичный пример пере-

хватчика уровня сообщений

—

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

щений GIOP типа Fragment на стороне отправителя и их сборкой на стороне

получателя.

Перехватчики видит только ORB, то есть именно ORB отвечает за активиза-

цию перехватчиков. Клиенты и серверы обычно не замечают перехватчиков, за

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

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

хватчиков CORBA можно найти в

[309],

а полную их спецификацию

—

[331].

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

Перехватчик уровня

запросов

Клиентское приложение

Заместитель

клиента

Запрос

Перехватчик уровня

сообщений

ORB

клиента

Локальная

ОС

К серверу

Рис. 9.7. Перехватчики в CORBA

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

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

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

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

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

ности единственное, что нам необходимо,

—

легко расширяемые брокеры ORB.

Перехватчики, предлагаемые CORBA, действительно обеспечивают обобщен-

ный механизм расширения, но тот ли это механизм, который нам нужен, еще во-

прос.

Дополнительную информацию о перехватчиках с точки зрения программ-

ной архитектуры можно найти в

[402].

Переносимый адаптер объектов

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

—

механизма реа-

лизации конкретных правил активизации группы объектов. Так, один адаптер

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

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

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

В основном адаптеры объектов не просто вызывают методы объектов. Как мож-

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

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

ривать программы как объекты. Адаптеры называют еще

оболочками

(wrappers).

В CORBA

переносимый

адаптер

объектов {Portable Object

Adapter, РОА)

—

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

объектом CORBA. РОА определяется так, чтобы серверный код можно было на-

писать без привязки к конкретному брокеру ORB.

Для поддержания переносимости между различными брокерами ORB CORBA

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

слугой. Слуга {servant)

—

это часть объекта, реализующая методы, к которым мо-

гут обращаться клиенты. Реализация слуги, естественно, зависит от используе-

мого языка программирования. Так, например, реализация слуги на 0++ или

9.1.C0RBA 557

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

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

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

екта.

Каким образом РОА использует слугу для построения образа объекта CORBA?

В первую очередь, в каждом адаптере РОА имеется следующая операция, кото-

рую мы описываем на IDL для CORBA:

Objectid act1vate_object(in Servant p^servant):

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

а в

качестве результата возвращает идентификатор объекта CORBA. Универсаль-

ного определения типа Servant не существует, он отображается на типы данных

выбранного языка программирования. Так, например, в C++ Servant отображает-

ся на указатель предопределенного класса ServantBase. Этот класс содержит не-

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

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

Идентификатор объекта, создаваемый РОА, возвращается операцией activate_

object. Этот идентификатор указывает на слугу и используется в качестве индек-

са в

карте активных объектов {active object

тар) РОА, как показано на рис. 9.8, а.

В этом случае РОА реализует отдельного слугу для каждого поддерживаемого

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

ботчик написал класс, дочерний для ServantBase, и назвал его My^Servant. Объект

C++, созданный в виде экземпляра класса My_Servant, может быть превращен в

объект CORBA так, как показано в листинге 9.1.

Карта активных

объектов

\ '

0ID1

0ID2

OID3

0ID4

OID5

OID6

nnvra

/ ^^

^ ^

1 Слуга

Слуга

Карта активных

объектов

1 У

А "^

lyra

Слуга

0ID1

0ID2

0ID3

0ID4

0ID5

0ID6

..^.^^^^

~—--^^

^^^

_,«j^

Слуга

Рис. 9.8. Отображение идентификаторов объектов CORBA

на

слуг.

РОА

поддерживает

несколько слуг

(а),

РОА

поддерживает одного слугу (б)

Листинг

9.1.

Преобразование объекта C++ в объект CORBA

My__Servant *my_object; // Объявление ссылки на объект C++

CORBA:

.'ObjectId^vaг old: // Объявление идентификатора CORBA

my_object « new MyServant: // Создание нового объекта C++

// Регистрация объекта C++ в качестве объекта CORBA

old = poa->activate_object(myobject):

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

В листинге 9,1 мы объявляем ссылку на объект C++. Для создания идентифи-

катора CORBA мы используем инструкцию

CORBA:

:ObjectId_var, где

CORBA —

тип

данных C++, предопределенный во всех стандартных реализациях CORBA на

языке C++. После этих объявлений создается истинный объект C++ my^object.

По терминологии CORBA этот объект соответствует слуге. Преобразование объ-

екта C++ в объект CORBA производится путем регистрации его в РОА (мы счи-

таем, что доступ к нему осуществляется через переменную роа). Результатом ре-

гистрации является идентификатор CORBA.

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

ция этого объекта C++ в РОА приведет к созданию такого же слуги, работающе-

го с другим состоянием этого класса. В тех случаях, когда РОА нужно поддержи-

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

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

Этот принцип продемонстрирован на рис. 9.8, б, на котором каждый идентифи-

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

нии к объекту идентификатор объекта неявно передается слуге. Таким образом,

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

вает идентифицированный объект.

Этот пример также иллюстрирует и другой важный момент: идентификатор

объекта CORBA однозначно ассоциирован с РОА. Когда в РОА регистрируется

слуга, РОА возвращает идентификатор объекта для этого слуги. С другой сторо-

ны,

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

тификатор, а уже потом передает его в РОА. Однако в обоих случаях этот иден-

тификатор будет спрятан в большой структуре данных, существующей в виде

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

и сервер, на котором этот адаптер РОА расположен.

Независимо от того, поддерживает РОА одного слугу на объект или одного

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

социировать с РОА. Правила могут быть самыми разными. Так, например, РОА

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

разными правилами может регламентироваться использование потоков выпол-

нения. Подробности можно найти в

[198].

Агенты

Чтобы способствовать использованию приложений-агентов, в CORBA принята

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

Вместо определения собственной модели агента, CORBA предоставляет стан-

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

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

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

агентов. Так, например, в CORBA Java-апплет может создать агента

Тс1

на плат-

форме D'Agents (мы описывали систему D'Agents в главе 3).

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

Система

агентов {agent system)

определяется как платформа, позволяющая создавать, вы-

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

9.1.C0RBA 559

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

глядит агент этой системы. Так, например, в профиле агента системы D'Agents,

определяется тип системы (D'Agents), поддерживаемый язык (например, Тс1) и

способ преобразования агента в последовательность байтов для передачи от сис-

темы к системе.

Агент всегда находится в специальном месте (place) в системе агентов. Это

место соответствует серверу, на котором располагается агент. Таких мест в сис-

теме агентов очень много. Другими словами, CORBA предполагает, что одна

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

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

ровку нескольких держателей агентов в одну административную единицу и воз-

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

системой агентов.

Системы агентов, в свою очередь, могут группироваться в регион {region),

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

системы агентов. Так, например, факультет университета может иметь несколь-

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

скольким хостам, или местам, и на каждом хосте могут работать несколько аген-

тов.

Эта модель демонстрируется на рис. 9.9.

Регион

I—1

...

Система

гентов

а?

У-

...

а?

Система

.-..г

гентов

(

...

;^истем£

гентов (

Связь с системами

других регионов

Стандартный интерфейс CORBA

Рис. 9.9. Общая модель агентов, систем агентов и регионов CORBA

Агент в CORBA рассматривается как сущность, собранная из набора классов

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

мы.

В любом случае можно дать реализации агента имя и передать это имя в сис-

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

его на другие машины.

Любая система агентов в CORBA должна реализовывать несколько стандарт-

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

запуска агента на исполнение, ведения списка существующих агентов, ведения

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

агента. Отметим, что реализация этих операций зависит исключительно от дан-

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

укладывалась в общую модель. Это означает, что если какая-то существующая

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

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

нуждена будет это делать.

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

пределах этого региона определять местоположения агентов, мест для них и сис-

тем агентов. Искатель также имеет набор стандартных операций для регистра-

ции и снятия с регистрации агентов, мест для них и систем агентов. В сущности,

искатель для данного региона

—

это не что иное, как просто служба каталогов.

Дополнительную информацию по мобильным агентам в CORBA можно най-

ти в

[329].

9.1.4. Именование

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

—

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

ния CORBA. Кроме того, существует несколько расширенных механизмов име-

нования, при помощи которых можно находить объекты по

PIX

свойствам. Далее

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

изучая ссылки на объекты. Что касается расширенных механизмов именования,

доступных через службу обмена CORBA, мы отсылаем читателя к [326, 330].

Ссылки на объекты

Основа CORBA

—

это способ организации ссылок на объекты. Когда клиент полу-

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

го объекта. Важно отличать ссылку на объект, которую использует клиентский

процесс для обращения к методу, от реализации ссылки в базовом брокере ORB.

Процесс (будь то клиент или сервер) может использовать только такую реа-

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

мирования. В большинстве случаев она принимает вид указателя на локальное

представление объекта. Эта ссылка не может быть передана из процесса А в про-

цесс

поскольку имеет смысл только в адресном пространстве процесса А. Что-

бы передать ссылку в другой процесс, процесс А должен сначала выполнить

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

ществляется брокером ORB. После завершения маршалинга ссылка может быть

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

Отметим, что процессы Л и 5 могут быть исполняемыми программами, написан-

ными на разных языках программирования.

В противоположность этим процессам обслуживающий их брокер ORB имеет

свое,

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

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

маршалинга передает процессу при обмене ссылками. Важно отметить, что когда

процесс использует ссылку на объект, обслуживающий его брокер ORB неявно

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

кому объекту на самом деле происходит обращение. Эта информация обычно пе-

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

ций объекта на языке IDL.