CC BY
81М.А.СЫСОЙКИНА*
ПРОТОКОЛ Z39.SC: ИСТОРИЯ СОЗДАНИЯ, ОСНОВНЫЕ ПОЛОЖЕНИЯ, ПРОБЛЕМЫ ПРИМЕНЕНИЯ
В последние два-три года в библиотечных кругах все чаще можно услышать разговоры о применении протокола 739.50 в области автоматизации библиотек, обработки информации, предоставления доступа к данным.
Сегодня все автоматизированные библиотечные системы используют в работе вычислительную технику, тем самым предоставляя различным пользователям (и читателям, и библиотекарям) весьма различные услуги по обработке информации. Протокол 739.50 на сегодняшний день становится все более распространенной технологией, обеспечивающей работу таких систем.
Люди, несведущие в информационных технологиях, ученые-обществоведы или иные научные работники часто теряются, услышав это словосочетание — «протокол 739.50». Попытаемся для начала разобраться в том, что означают эти слова по отдельности.
Протокол — это правила обмена информацией между компьютерами. Правила эти непосредственно не касаются конечного пользователя, но в тоже время обеспечивают его возможностью пользоваться каким-либо сервисом. В качестве примера можно привести протокол НТТР, известный, наверное, всем без исключения пользователям, когда-либо работавшим в сети Интернет. Протокол НТТР предлагает набор правил для обмена информацией во «всемирной паутине».
Сысойкина Мария Александровна - аспирантка кафедры информационных ресурсов Российского государственного гуманитарного университета.
Протокол Z39.50 определен соответствующим стандартом (ANSI Z39.50-1995, ISO/FDIS 23950). Не вдаваясь пока в детали работы протокола, можно сказать, что стандарт Z39.50 определяет такие правила взаимодействия компьютеров, которые позволяют унифицировать доступ к различным базам данных (БД). Иными словами, пользователь, использующий всего лишь одно приложение на компьютере-клиенте, может производить поиск информации в БД, имеющих самую разную структуру и форматы представления информации. БД могут храниться на удаленных компьютерах-серверах, находящихся в самых различных местах. Например, работник библиотеки или читатель сможет со своего рабочего компьютера искать, просматривать и обрабатывать информацию, хранимую на сервере, например, на другом континенте.
Конечно же, Z39.50 позволяет получать информацию и локально, т.е. в рамках одной библиотеки. Однако доступ к удаленным и распределенным хранилищам информации — это очень важное достоинство протокола.
История создания и развития протокола Z39.50
Z39.50 разрабатывался в Библиотеке конгресса США с начала 80-х годов.
В 1989 г. в рамках Библиотеки конгресса было создано специальное подразделение — Агентство поддержки Z39.50 (Z39.50 Maintenance agency), которое в настоящее время координирует работу различных групп, развивающих отдельные направления использования протокола и предлагающих новые версии стандарта, а также ведет реестр разработчиков программного обеспечения для протокола Z39.50.
Изначально протокол Z39.50 предназначался для обработки библиографической информации. Однако сейчас протокол достаточно развит, чтобы поддерживать различные данные — финансовую, химическую, техническую информацию, полные тексты и изображения.
Можно назвать целый ряд причин, послуживших стимулом к разработке протокола Z39.50. Главной причиной, наиболее сложной и общей, является тот факт, что в библиотечном сообществе, да и не только в нем одном, существует огромное количество информационно-поисковых систем, электронных каталогов, систем автоматиза-
ции, которые поддерживают абсолютно различные формы представления информации, формы хранения данных, способы доступа к информации. В этой большой проблеме можно выделить несколько составных частей.
Во-первых, очевидно, что различные БД имеют разную структуру хранения информации. Это означает, что записи БД (документы) могут иметь разные наборы полей, в каждом конкретном случае поля совершенно по-разному называются, одни и те же поля могут трактоваться по-разному, а следовательно, и наполняться данными по-разному в различных системах. Для примера рассмотрим поле, встречающееся в любой библиографической БД, — поле АВТОР. В связи с тем, что в различных БД информация хранится в соответствии с разными стандартами (а иногда и вовсе без всяких стандартов, просто так, как сочли удобным разработчики), в этом поле могут содержаться совершенно разные значения. Например, если документ БД состоит из полей, соответствующих полям записи MARC, то в этом поле, скорее всего, будет содержаться фамилия первого автора источника. Однако возможна такая ситуация, когда поля БД сформированы исходя из других соображений, и в поле АВТОР могут содержаться повторяющиеся значения, т.е. фамилия не только первого автора, а все фамилии авторов источника вместе. Подобная ситуация происходит и с другими полями, например, когда выделяется основное заглавие документа, а все остальные (подзаголовок, альтернативные заглавия и т.д.) заносятся в одно поле. Все это вносит определенные неудобства, как при поиске информации, так и на этапе ее выдачи пользователю.
Далее, в разных системах используются разные поисковые языки, т.е. правила составления запросов на поиск информации в БД.
Также различается и способ представления выдаваемой информации. Разные системы по-разному определяют выходной формат выдаваемой по запросу записи. Где-то записи могут выдаваться просто в виде списка, где-то форма записи выдается в виде каталожной карточки, а в некоторых, более серьезных системах существует возможность выбора выходного формата, и, затратив некоторые усилия, пользователь сможет выбрать нужный формат. В последнее время серьезные поисковые системы предлагают возможность выдачи информации в коммуникативных форматах — в форматах семейства MARC. Это большой плюс, так как формат MARC позволяет обмениваться информацией с другими системами.
Однако уже даже эти несколько перечисленных различий ведут к тому, что каждая система имеет свой собственный пользовательский интерфейс, строго ориентированный на используемые форматы хранения данных, поисковые языки и форму выдачи данных. В свою очередь, такие ограничения на доступ к информации приводят к тому, что пользователь для общения с каждой отдельной системой должен изучить ее интерфейс, разобраться в правилах составления запросов и, возможно, смириться с тем, что документы будут выданы не в требуемом формате, а в том, который поддерживается системой.
До появления Z39.50 основным протоколом доступа к распределенным хранилищам информации был протокол HTTP — основа «всемирной паутины» — World Wide Web. Однако HTTP — протокол общего назначения и не имеет практически никаких специализированных возможностей, позволяющих, например, унифицировать доступ к разнородной информации или создавать поисковые запросы к БД. Разумеется, эти проблемы решаемы и на базе протокола HTTP, однако для этого приходится применять различные дополнительные средства, языки программирования, библиотеки функций и т.д. Все это приводит к тому, с чего мы и начали: каждый разработчик находит собственное решение таких проблем, создавая систему доступными ему средствами, используя собственные механизмы, технологии и модели. В результате и получается, что отдельно взятая поисковая система имеет свою собственную структуру, собственные форматы хранения данных, зачастую не согласующиеся с существующими стандартами. То есть мы получаем информацию зачастую только в том виде, в котором она представлена в этой системе, и нет никаких гарантий, что мы сможем без потерь или дополнительных преобразований и сопоставлений использовать эту информацию в других системах и базах данных. Далее, на прикладном уровне мы имеем интерфейс, присущий только этой системе. Интерфейс включает в себя не только некие чисто визуальные элементы, но и правила взаимодействия, общения с системой. А правила эти напрямую зависят от особенностей хранения данных и способов доступа к ним. Самым очевидным примером правил общения с системой можно считать правила формулировки поисковых запросов к системе. В различных системах эти правила абсолютно разные. Это связано с тем, что в БД данных различаются наборы полей, разные системы предоставляют возможности поиска по различным логическим критериям и т.д. В общем, мы опять вернулись к тому, с чего и начинали: системы, постро-
енные без использования протокола Z39.50, разнородны и обособлены, что во многом затрудняет как работу с ними, так и дальнейшее использование предоставляемой ими информации.
Как же протокол Z39.50 справляется с этими трудностями? Не вдаваясь в глубокие технические подробности работы протокола, обозначим пока две основные особенности, отличающие протокол Z39.50 от других.
1. Модель представления информации, заложенная в протоколе, никак не зависит от источников информации, использующих этот протокол. Иными словами, протокол является некой абстрактной моделью представления информации на каждом этапе взаимодействия клиента и сервера. В результате и способ введения поисковых запросов, и формат выдачи информации унифицированы и внешне никак не зависят от конкретной системы и ее особенностей.
2. Протокол Z39.50 полностью обеспечивает сессионное взаимодействие клиента с сервером. Эта особенность заложена в самом протоколе и реализуется во всех его приложениях, будь то серверная система или программа-клиент.
Основные положения протокола Z39.5G
Основная идея представления информации при работе с протоколом Z39.50 лежит в абстрагировании от конкретной структуры какой бы то ни было базы данных. Для этого в стандарте описана некая абстрактная модель БД. Эта модель включает в себя полный набор элементов, необходимых для доступа и обработки информации, хранимой в БД. Абстрактная модель описывает в виде отдельных элементов не только, например, возможные поисковые поля или форматы выдачи информации, но и все выполняемые сервером операции. Каждый такой элемент однозначно описывается стандартом при помощи уникального идентификатора — OID (Object ID). Взаимодействие с каждой конкретной системой управления базами данных организовано путем обмена пакетами данных (APDU) — блоками информации, содержащими последовательности нужных элементов, обозначенных соответствующими идентификаторами. Более подробно мы рассмотрим такие APDU чуть дальше, когда будем говорить о сессионном взаимодействии.
Таким образом, абстрактная модель БД, представленная протоколом, отображается на конкретную модель существующей базы
данных. Задача разработчика системы состоит в том, чтобы правильно отобразить абстрактную модель данных протокола на существующую структуру БД и сопоставить соответствующие элементы.
В стандарте описаны следующие классы объектов: Контекст приложения (context), APDU, Атрибуты (attributeSet), Диагностика (diagnostic), Структура записей (recordSyntax), Синтаксис преобразований (transferSyntax), Отчет по ресурсам (resourceReport), Контроль доступа (accessControl), Расширенный сервис (extendedService), Пользовательская информация (userInfoFormat), Элементы (element-Spec), Варианты (variantSet), Схема данных (schema), Схема меток (tagSet). Каждый класс и все его объекты имеют свои OID. Например, в классе recordSyntax {1.2.840.10003.5} объекты имеют OID: Unimarc {1.2.840.10003.5.1}, USmarc {1.2.840.10003.5.10}, SUTRS {1.2.840.10003.5.101} и т.п.
В процессе извлечения записей из баз данных сами данные последовательно существуют в нескольких различных представлениях (1, 39):
1) внутреннее представление данных в конкретной СУБД — в таком виде данные хранятся;
2) внутреннее абстрактное представление сервера — в таком виде данные обрабатываются сервером;
3) внешнее представление — в таком виде данные отдаются клиенту.
В ответ на запрос пользователя выдать найденные записи сервер Z39.50 возвращает затребованное количество записей клиенту в необходимом формате внешнего представления. Форматы представления стандартизованы в классе RecordSyntax {Z39.50 5} и включают MARC-форматы ISO-2709 (Unimarc, Usmarc, CCF, SBN и т.д.), неструктурированный текстовый формат SUTRS, структурированные тэговые форматы (GRS-1, Summary), специальные форматы (HTML, XML, PDF, TIFF, GIF) и др. Структурированные форматы позволяют после передачи по сети полностью сохранить первоначальную структуру записи в отличие от других протоколов (http, ftp и др.), что является немаловажным в распределенных системах. Согласно стандарту, каждый Z-сервер обязан представлять информацию как минимум в формате SUTRS — в виде неструктурированного текста. Однако большинство достаточно развитых серверов не ограничивается этим. Очень многие сервера реализуют выдачу записей в MARC-форматах
— как правило, или Usmar, или Unimarc, или же Rusmarc, если мы имеем дело с отечественным сервером.
Поскольку извлекаемые записи могут иметь значительную длину, а их поля (элементы) могут иметь существенно различный тип данных, стандарт позволяет извлекать ограниченный список полей из записи. Список полей, допускающих одновременное присутствие во внешнем представлении записи, называется «набором элементов» (elementSet). Минимально допустимы два набора элементов — Full (F) и Brief (B).
Идеология максимального абстрагирования от структур реальных баз данных приводит к весьма изощренной схеме извлечения данных, описанной в стандарте Z39.50: записи из результирующих наборов отображаются в записи абстрактной базы данных через схему, определяющую абстрактную структуру записи в виде дерева элементов, специфицируемых метками (tag) из стандартных наборов (tagSet); затребованные элементы выбираются в нужной альтернативной форме (variant) из абстрактной записи и отображаются в экспортируемую структуру, определяемую форматом внешнего представления (recordSyntax). Все объекты описанной процедуры (schema, tagSet, elementSpec, variantSet, recordSyntax) определены в соответствующих классах с присвоением OID.
Теперь, когда мы имеем некоторое представление об абстрактной модели данных, описанной в стандарте, можно обратиться к особенностям общения клиента и сервера по протоколу Z39.50, и прежде всего, к возможностям сессионного взаимодействия.
Во-первых, разберемся с тем, что такое сессия. Формально определение сессии звучит приблизительно так:
«Сессией является последовательность функционально связанных поисковых сеансов (операций), направленная на получение логически целостного результата, каждый из которых выполняется в рамках отдельной сетевой трансакции».
Иными словами, сессия — это последовательность взаимосвязанных операций, причем каждая последующая операция выполняется только по завершении предыдущей и основана на ее результатах.
Протокол Z39.50, изначально ориентированный на информационно-поисковые задачи, функционально обеспечивает поддержку поисковой сессии. Поддержка многошагового поискового процесса осуществляется средствами Z-сервера, управляющего взаимодействием как на сеансовом, так и на сессионном уровне.
По стандарту Z39.50 сессионное взаимодействие клиентского и серверного приложений осуществляется по модели «запрос — ответ». Это значит, что каждый последующий запрос от клиента будет основываться на предыдущем ответе сервера. В ходе сессии на сервере хранится информация обо всех выполненных процессах и их результатах, и каждый новый процесс будет основываться на этой информации.
В стандарте определены следующие процессы (или операции): Init — инициализация сессии, Search — поиск, Present — выдача найденных записей, DeleteResultSet — удаление результата поиска, Scan — просмотр поисковых индексов БД, Sort — сортировка найденных записей, ExtendedServices — дополнительные возможности, Close — закрытие сессии.
В какой же последовательности выполняются эти операции?
Прежде всего, происходит процесс инициализации соединения. Клиентское приложение посылает серверу запрос на соединение, передавая при этом такие сведения о себе, как используемая версия протокола, максимальные размеры записей, допустимые операции и т.д. Такой запрос передается в соответствующем APDU — Ini-tializeRequest. В ответ сервер отправляет клиенту APDU InitializeRe-sponse, в котором пересылает клиенту тот же набор параметров, но уже со своими значениями. Таким образом, стороны «договариваются» о том, какие возможности протокола могут быть использованы в ходе сессии. После ответа сервера клиенту открывается новая сессия. В ходе этой сессии пользователь может формулировать и посылать серверу поисковые запросы, просматривать результат поиска, сортировать выдачу, просматривать поисковые индексы, удалять результаты поиска и т.д. Закрывается сессия либо по инициативе клиентского приложения, посылающего серверу APDU Close, либо самим сервером после долговременного отсутствия каких бы то ни было запросов от клиента.
Запрос на поиск отправляется клиентским приложением в APDU SearchRequest. Этот APDU включает в себя такую информацию, как база данных, в которой производится поиск, тип задаваемого запроса, сам запрос и некоторые другие параметры, касающиеся результирующего множества. Стандарт протокола Z39.50 поддерживает несколько типов запросов, но обязательным является тип 1 — запрос в обратной поисковой записи, именуемый в спецификации RPNquery. Поисковое выражение может содержать другой запрос,
указатель на результирующее множество или комбинацию атрибутов и поисковых терминов. Под атрибутами в данном случае понимается некий набор параметров, характеризующий правила поиска каждого термина. Наиболее распространен набор атрибутов Bib-1 {OID Z39.50 3 1}, включающий группу Use из 99 поисковых атрибутов (таких, как author, title, DatePublication и т.п.) и пять групп уточняющих атрибутов (Relation, Position, Structure, Truncation, Completeness). Примером развернутого в строку RPN-запроса может быть запрос на поиск записей, в которых автор начинается на «Кузн» и встречается в любой позиции поля:
@attr 1=1003 @attr 2=3 @attr 3=3 @attr 5=1 {Кузн},
где по Bib-1 @attr 1=1003 — соответсвует author, @attr 2=3 — равно, @attr 3=3 — любая позиция в поле, @attr 5=1 — усечение справа, Кузн — поисковый термин. Естественно то, что серверу передается не строка запроса, а древовидная RPN-структура, где каждая пара «ат-рибут=значение» представлена отдельным элементом. Такая организация системы запросов позволяет, с одной стороны, однозначно отобразить логику запроса, абстрагируясь от синтаксиса запроса конкретной СУБД, а с другой — абстрагироваться от поисковых полей конкретной базы данных, так как запрос формулируется всегда в терминах абстрактного набора атрибутов, например Bib-1. Кроме Bib-1, ориентированного на работу с библиографическими базами данных, сегодня стандартизованы и другие наборы атрибутов, например, STAS — 2 тыс. атрибутов для научно-технической информации, GEO
— 2 тыс. атрибутов для геоинформационных систем и др.
Запросы RPN (Type-1) — не единственно допустимый тип запросов в Z39.50. Стандарт 1995 г. (версия 3) допускает запросы Type-0
— запросы в синтаксисе конкретной СУБД, запросы Type-2 — запросы в синтаксисе Common Command Language (CCL — ISO 8777) и др. В настоящее время ведется обсуждение включения в Z39.50 запросов в синтаксисе SQL.
Ответом на поисковый запрос служит APDU SearchResponse, который содержит такую информацию, как количество найденных записей и номер следующей извлекаемой записи. Поскольку протокол рассчитан на сессионное взаимодействие, и каждое последующее действие выполняется только по результатам предыдущего, мы не можем сразу же просмотреть найденные записи. В APDU ответа на поиск найденные записи не передаются. Для этого нужно послать серверу запрос на выдачу нужных записей — PresentRequest.
При запросе на выдачу серверу передается имя результирующего множества, из которого мы просматриваем записи, номер записи, с которой начинается просмотр, количество выдаваемых записей, формат выдачи и набор элементов (все поля или только часть). Получив такой запрос, сервер обращается к результирующему множеству, выбирает нужные записи, преобразует их в требуемый формат и возвращает клиенту в АРБИ Ргезе^Кезроше.
Помимо рассмотренных операций поиска и выдачи существуют еще и другие возможности: сортировка найденных библиографических описаний, просмотр поисковых индексов сервера, заказ источника, добавление или изменение записей.
Протокол 739.50 в действии
Стандарт протокола определяет достаточно много возможностей по унификации доступа к информации. Это позволяет использовать протокол 739.50 для создания сложных информационных систем, направленных на образование единого информационного пространства как минимум в пределах одной страны. С другой стороны, протокол является достаточно гибким средством в том смысле, что необязательно реализовывать все возможности, заложенные в стандарте. Это позволяет создавать системы меньшего масштаба.
В настоящее время в мире функционирует несколько сотен серверов, которые в основном обеспечивают доступ к библиографическим БД.
Из наиболее известных зарубежных серверов можно назвать, прежде всего, сервер Библиотеки конгресса США, предоставляющий доступ к фондам этой библиотеки.
Из российских серверов наиболее крупной разработкой считается проект Яи8ЬАКе11, реализуемый центром «Открытые библиотечные системы»2 совместно с Фундаментальной библиотекой СПбГТУ3. Цель этого проекта — создание единого информационного пространства библиотек Северо-Запада России и интеграция его в общемировое библиотечное пространство (3, с. 46). Одной из задач,
1 ЬИр://'йгйгй'.гш1ап.ги:8001/.
2
http://www.uni1ib.neva.ru/rus/o1sc/home.htm1. http://www.uni1ib .neva.ru/rus/1ib/home.htm1.
направленных на достижение этой цели, как раз и является предоставление доступа к библиографическим описаниям изданий из фонда ФБ СПбГТУ.
С 2000 г. сервер 739.50 функционирует и в ИНИОН РАН. На самом деле это не просто сервер, а целый интегрированный информационно-поисковый комплекс, имеющий название ІгЬі77. Создан этот комплекс путем объединения работающей в ИНИОН поисковой системы Ирбис, 7-сервера 7оорагк, разработанного в Объединенном институте геологии, геофизики и минералогии СО РАН, а также клиентского модуля протокола 739.50. Основной функцией комплекса ІгЬі77 является предоставление доступа к библиографическим базам данных ИНИОН по протоколу 739.50. Но система может выступать и в роли клиента 739.50. Интегрированный в поисковую систему клиентский модуль позволяет пользователю обращаться к другим 7-серверам (например, к серверу Научной электронной библиотеки или к серверу БЬвсо) за полными текстами найденных в базах данных ИНИОН журнальных статей.
Список литературы
1. Жижимов О.Л. Введение в Z39.50. - Новосибирск, НГОНБ, 2000.
2. Материалы Z39.50. Maintenance Agency http://lcweb.loc.gov/z3950/agency/.
3. Племнек А.И., Усманов Р.Т. Практика построения Z39.50-интерфейсов к библиографической реляционной базе данных для региональной библиотечной системы RUSLANet // Материалы международной библиотечной конференции «Информационные технологии в библиотеках на рубеже веков: проблемы, поиск, решения». - Минск: Красико-принт, 1999. - С. 41- 48.
