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

CORBA поддерживает различные типы имен. Имена самого низкого уровня — это ссылки на объекты и символьные имена, поддерживаемые службой именова­ния CORBA. Кроме того, существует несколько расширенных механизмов име­нования, при помощи которых можно находить объекты по их свойствам. Далее мы рассмотрим базовую службу именования CORBA, особенно внимательно изучая ссылки на объекты. Что касается расширенных механизмов именования, доступных через службу обмена CORBA, мы отсылаем читателя к [326, 330].

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

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

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

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

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

В се современные системы CORBA поддерживают одинаковое, не зависящее от языка программирования представление ссылок на объекты, которое называ­ется межоперационной ссылкой па объект (Interoperable Object Reference, IOR). He так уж важно, использует или нет ORB формат IOR для своих внутренних нужд. Однако при передаче ссылки на объект другому брокеру ORB он делает это в формате IOR. Ссылка IOR содержит всю информацию, необходимую для идентификации объекта. Общий вид IOR представлен на рис. 9.10 вместе со спе­цифичной информацией для протокола НОР, которую мы далее рассмотрим в деталях.

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

Наиболее важная часть каждой ссылки IOR — так называемый теговый про-филъ (tagged profile). Каждый теговый профиль содержит всю информацию, необходимую для обращения к объекту. Если сервер объектов поддерживает несколько протоколов, информация о каждом из них будет содержаться в от­дельном теговом профиле. Детали профиля для ПОР также представлены на рис. 9.10.

Профиль для ПОР идентифицируется соответствующим полем тегового про­филя и состоит, в свою очередь, из пяти полей.

• Поле версии ПОР определяет версию протокола ПОР, использованную в дан­ном профиле.

• Поле хоста — это строка, идентифицирующая хост, на котором находится объект. Хост может быть задан либо в виде полного доменного DNS-име-ни (например, soling.csvu.nl), либо в виде IP-адреса хоста (например, 130.37.24.11).

• Поле порта содержит номер порта, с которого сервер объекта ожидает вхо­дящих сообщений.

• Поле ключа объекта содержит информацию, необходимую серверу для выделения запросов, предназначенных для данного объекта. Так, напри­мер, частью этого ключа, как правило, является созданный РОА идентифи­катор объекта. Этот ключ будет также идентифицировать РОА.

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

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

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

ORB клиента получает ссылку IOR, возвращенную ему службой именования, и для проверки идентификатора хранилища, содержащегося в IOR, может по­местить заместитель на клиента и вернуть указатель р на этот заместитель. Внут­ри себя ORB сохраняет сведения о том, что р соответствует IOR объекта.

Разные брокеры ORB имеют разную реализацию, но одинаковый сценарий работы. До передачи р клиенту клиентский брокер ORB проверяет теговые про­фили, входящие в IOR. Предположим, что объект вызывается по протоколу НОР. В этом случае клиентский брокер ORB может, используя адрес хоста и но­мер порта, найденные в IOR, установить с сервером объектов соединение по про­токолу TCP. В этот момент он и передает р клиенту.

Когда клиент обращается к одному из методов объекта, ORB клиента выпол­няет маршалинг запроса в сообщение Request протокола НОР. Это сообщение содержит ключ объекта для данного сервера, который также хранится в IOR.

Сообщение через соединение TCP передается на сервер, где пересылается адап­теру РОА, ассоциированному с ключом объекта. Далее РОА передаст запрос нужному слуге, где путем демаршалинга он будет преобразован в реальный вы­зов метода.

Согласно этому сценарию IOR непосредственно ссылается на объект, что приводит к так называемой прямой привязке (direct binding). Альтернативой пря­мой привязке является непрямая привязка (indirect binding), при которой постро­енный запрос сначала пересылается в хранилище реализаций. Хранилище реа­лизаций — это еще один процесс, идентифицируемый в IOR объекта. Он служит реестром, в котором может находиться и активизироваться перед получением за­проса указанный объект. На практике непрямая привязка используется в первую очередь для сохранных объектов, то есть объектов, управляемых РОА и соблю­дающих правила, обязательные для объектов длительного хранения.

Когда клиентский брокер ORB использует ссылки IOR, основанные на не­прямой привязке, он просто начинает процедуру привязки с хранилища реализа­ций. Хранилище уведомляет, что запрос на самом деле предназначен для другого сервера, и просматривает свои таблицы в поисках работающего сервера и его ме­стоположения. Если соответствующий сервер в данный момент не запущен, хра­нилище реализаций может запустить его, если он поддерживает возможность ав­томатического запуска.

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

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

Как и другие распределенные системы, CORBA имеет службу именования, кото­рая позволяет клиентам находить ссылки на объекты по символьным именам. Формально имя в CORBA — это последовательность компонентов имени, каж­дый из которых имеет вид пары (идентификатор, сорт), где идентификатор и сорт — строки. Обычно идентификатор используется для именования объекта строкой символов, например «steen» или «elke». Атрибут сорт — это просто ин­дикатор именованного объекта, похожий на расширение в именах файлов. Так, например, объект, названный «steen», может иметь сорт «dir», указывающий на то, что это объект каталога.

Не существует способа представить путь и имя в виде одной строки. Другими словами, CORBA не определяет разделитель между компонентами имени. Вме­сто этого имена можно передавать просто как последовательность компонентов имени. Представление последовательности зависит от используемого языка про­граммирования, но для клиента, пользующегося услугами службы именования, оно остается непрозрачным.

На структуру графа именования не существует ограничений. Каждый из уз­лов графа именования трактуется как объект. Контекст именования (naming context) — это объект, хранящий таблицу отображения компонентов имен в ссылки на объекты. Контекст именования, таким образом, это то, что в главе 4 мы называли направляющим узлом. Отметим, что ссылка на объект в контексте именования может ссылаться на другой контекст именования.

Граф именования не имеет корневого контекста. Однако каждый брокер ORB имеет исходный контекст именования, который в данных условиях представляет собой корень графа именования. Имена всегда разрешаются в соответствии с данным контекстом именования. Другими словами, если клиент хочет разре­шить имя, он должен вызвать метод resolve конкретного контекста именования. Если разрешение имени произошло успешно, он всегда возвращает ссылку либо на контекст именования, либо на именованный объект. В этом смысле разреше­ние имен происходит именно так, как было описано в главе 4, и здесь мы не бу­дем повторно приводить всю эту информацию.