Конференции ИВТ СО РАН

Тезисы докладов

В ТНЦ СО РАН создан распределенный электронный каталог, который содержит сегодня не более 8000 записей. Электронный каталог - это 5 библиографических баз данных, которые доступны по протоколу Z39.50, а также и через OPAC-систему. Все остальные информационные ресурсы находятся в закрытой части сети ТНЦ СО РАН и не доступны для поиска и извлечения данных через протокол Z39.50 или через OPAC.

Можно предположить, что со временем в ТНЦ СО РАН появятся информационные системы (далее ИС), которые управляют вновь создаваемыми информационным ресурсами - сводный библиографический каталог, электронная библиотека и цифровые депозитарии. Внешние информационные ресурсы (например реферативные журналы ВИНИТИ), доступ к которым осуществляется со стороны ТНЦ СО РАН, также рассматриваются нами как ИС.

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

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

* Поддержка сетевого протокола взаимодействия типа клиент/сервер;

* Поддержка абстрактной модели данных;

* Поддержка абстрактной системы запросов;

* Поддержка стандартных форматов обмена данными.

Список вышеприведенных положений характеризует ИС с точки зрения перспективы на то чтобы стать частью распределенной ИС. Мы понимаем распределенную ИС (далее просто система) как совокупностью одной или нескольких ИС, которые находятся в разных участках сети. Система может включать в себя дополнительные административные подсистемы: подсистема управления информационными ресурсами; подсистема рeрегистрация и аутентификация пользователей; единая точка доступа. Административные подсистемы являются факультативными для системы.

Функциональность системы подчинена простой логике выполнения задач поиска и извлечения информации, которую должна поддерживать каждая из ИС входящих в систему. Для обеспечения функциональности система использует стандартный сетевой протокол поиска и извлечения информации ISO 23950, который более известен как Z39.50.

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

В основе архитектуры системы лежит клиент/серверная модель взаимодействия программных приложений. Взаимодействие между обобщенным клиентом и обобщенным сервером основано на протоколе Z39.50, который описывает процедуры относящиеся к origin (клиент Z39.50) и процедуры относящиеся к target (сервер Z39.50) (процедуры обмена сообщениями между origin и target).

Для всех ИС, которые претендуют быть интегрированными в систему, предъявляется ряд требований, которые определяются в прикладном профиле Z39.50. Таким образом все компоненты системы являются ИС, которые включают в себя интерфейс на основе Z39.50 соответствующий прикладному профилю Z39.50.

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

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

В системе все приложения выполняют роль клиента Z39.50 или роль сервера Z39.50, а также есть приложения которые выполняют обе роли одновременно, например прокси-сервер Z39.50.

В соответствии с моделью протокола Z39.50 все ИС входящие в систему должны иметь service-provider или иначе - службу Z39.50, которая способна принимать и отвечать на запросы от одного или нескольких клиентов Z39.50.

Служба Z39.50 может быть определена как service-provider, который предоставляет коммуникационный путь между двумя service-user.

Для осуществления одновременного поиска и извлечения информации клиент Z39.50 может применять различные стратегии распределенного поиска, которые основаны на двух режимах сетевого взаимодействия клиентов Z39.50:

* синхронный - это когда клиент отправляет запросы к серверам каждой из ИС последовательно, один за другим, с ожиданием ответа от очередного сервера. Клиент в состоянии ожидания блокируется и не может выполнять другие операции по сети.

* асинхронный - это когда клиент отправляет запросы к серверам каждой из ИС последовательно, один за другим, но без блокирования в состоянии ожидания ответа от очередного сервера. Отправив запросы к серверам ИС и находясь в состоянии ожидания клиент получает ответы от серверов необязательно в том порядке, в котором были выполнены запросы (к примеру - один из серверов может ответить на запрос клиента "быстрее" чем другой, и в этом случае клиент получит ответ от "быстрого" сервера в первую очередь).

В архитектуру системы может быть включен прокси-сервер Z39.50, который обеспечивает транслирование запросов от клиента Z39.50 к серверу Z39.50. Наличие прокси-сервера Z39.50 предоставляет возможность применять в архитектуре системы гибкие решения. Например, "скрывать/открывать" сервера Z39.50 находящиеся за сетевым экраном или для равномерного распределения нагрузки на определенную ИС, если ИС представлена несколькими серверами Z39.50.

Z39.50 охватывает большой список деятельности человека где применяются информационно-поисковые системы. Регламентировать применение стандарта в той или иной области помогают прикладные профили Z39.50.

Разработчики стандарта не могли и не могут учесть все аспекты применения стандарта, разработчики информационных систем могут трактовать применение стандарта Z39.50 отличным друг от друга образом и наконец стандарт Z39.50 может применяться в таком окружении, что требуется по "новому взглянуть" на хорошо знакомые вещи, как это произошло с протоколом SRW/U. Все вышесказанное говорит о важности рассмотрения и поддержке профилей Z39.50.

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

The Bath Profile

Zthes

SRW/U

GEO

Z39.50 OAI Gateway Profile

Агентство по поддержке Z39.50 проводит регистрацию коммуникативных форматов и схем данных используемых в Z39.50, список которых можно найти на сайте агентства.

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

RUSMARC

MARC21

XML

Необходимо отметить, что каждый из серверов Z39.50 способен представить искомые записи в синтаксисе определение через ASN.1 -- GRS-1 (Generic Record Structure) [ссылка на GRS-1], а также специальные записи в синтаксисе OPAC, Explain, Extended Service и т.д. [ссылка на Appendix 5: REC: Record Syntax]. Записи представленные в ASN.1 нотации не получили широкого распространения и в основном используются для решения внутренних технических задач (например задачи Explain, Extended Service Z39.50).

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

MARC21XML

DCMES

ZeeRex

Ранее было отмечено, что cистема есть совокупность ИС. Грамотное размещение служб Z39.50 ИС в сети, еще не залог успешно построенной системы, так как в ней нет автоматического учета и контроля информационных ресурсов, нет разграничения прав доступа, нет единой точки доступа. Наличие подобных подсистем необходимо для проектов направленных на использование распределенных информационных ресурсов. Мы называем такие подсистемы - административными подсистемами.

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

Основные задачи подсистемы

* Регистрация Z39.50 баз данных;

* Поддержание в актуальном состоянии описаний Z39.50 баз данных.

Подсистема строится на базе технологии ZeeRex. Все описания баз данных создаются в соответствии со схемой данных ZeeRex, которые удерживает типовой Z39.50 сервер системы. Все описания собираются в отдельной выделенной специализированной базе данных - мета база данных.

Мета база данных (от греч. meta - между, после, через) - это Z39.50 база данных, которая удерживает описательную информацию о Z39.50 базах данных системы. Такая база данных не участвует в процессе распределенного поиска и используется неявно приложениями.

Мета база данных поддерживается в актуальном состоянии с помощью асинхронно работающего приложения программы-робота. Программа-робот периодически опрашивает все известные ей сервера на предмет изменений конфигурации баз данных и появления новых. Для того, чтобы зарегистрировать новую базу данных или новый сервер необходимо сделать так, чтобы они попали в список опроса программы-робота. Список опроса это фактически список уникальных элементов состоящих из значений host, port и программа-робот во время опроса не опрашивает один сервер дважды. Например, если добавляется новая база данных на уже зарегистрированном сервере, то программа-робот при очередном опросе получит ее описание в виде ZeeRex либо Explain записи, которая, в дальнейшем, будет помещена в специализированную базу данных.

Если же необходимо добавить новый сервер, или изменить сетевой адрес уже существующего, то для этого применяется специальная схема. Суть которой состоит в том, что необходимо добавить краткую форму ZeeRex описания вновь создаваемого Z39.50 ресурса на любом из зарегистрированных серверов. Программа-робот при очередном опросе обнаружит эту запись и извлечет все ZeeRex описания баз данных с искомого сервера.

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

Замечание: Необходимо отметить, что изложенный подход реализует одно-ранговую сеть Z39.50 ресурсов, иными словами любой из типовых серверов консорциума, может удерживать специализированную базу данных и для иерархической организации ресурсов необходимо вводить дополнительные механизмы, которые выходят за рамки ZeeRex.

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

Для системы распределенных в сети ИС разумно использовать единое решение для идентификации и аунтефикации пользователей и программных приложений, которое совместимо с Z39.50.

Управление доступом Z39.50 (access control) может быть использовано для аунтефикации на основе имени пользователя и пароля, на основе открытого ключа, а также на основе алгоритмической аунтефикации. Стандарт Z39.50 определяет три формата для управления доступом:

* promt-1 (User/Password)

* des-1 (DES)

* krb-1 (Kerberos)

Потенциально в системе могут приценятся несколько методов для аунтефикации, и Z39.50 приложения могут быть органично интегрированы с ними. В том случае если используется нестандартные методы для аунтефикации в ИС, то и в этом случае Z39.50 предоставляет возможность использовать такой нестандартный механизм благодаря возможности определить формат управления доступом как EXTERNAL (внешний, без предопределенной заранее структуры).

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

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

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

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

Единая точка доступа - это компромисс между сложностью и простотой для систем с открытым интерфейсом доступа. Без потери общности мы можем "скрыть" за прокси-сервером Z39.50 все сервера системы и представить систему как единственную сущность - сервер Z39.50. В этом случае мы получим единую точку доступа по протоколу Z39.50.

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

Ваши комментарии Обратная связь

[Головная страница] [Конференции]

© 1996-2000, Институт вычислительных технологий СО РАН, Новосибирск
© 1996-2000, Сибирское отделение Российской академии наук, Новосибирск