расположение страницы : bookresearch.ru / Разработчику / Протокол Z39.50 – обоснование необходимости использования /

Протокол Z39.50 – обоснование необходимости использования

 Мария Сысойкина

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

Что представляет из себя этот протокол, и чем он лучше привычного всем HTTP?

Протокол Z39.50 определен соответствующим стандартом (ANSI Z39.50-1995, ISO/FDIS 23950). Z39.50 - протокол прикладного уровня в рамках семиуровневой эталонной модели взаимодействия открытых систем, разработанной Международной Организацией Стандартов (ISO) и поэтому может быть реализован в различных типах сетей (например, в сетях TCP/IP, IPX/SPX, OSI), независимо от реализации транспортного уровня. Его назначение - предоставить компьютеру, работающему в режиме "клиент", возможности поиска и извлечения информации из другого компьютера, работающего как информационный сервер.

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

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

История

Z39.50 разрабатывался в Библиотеке Конгресса США с начала 80-х годов.

В 1989 году в рамках библиотеки конгресса было создано специальное подразделение - Агентство поддержки Z39.50 (Z39.50 Maintenance Agency) (http://lcweb.loc.gov/z3950/agency/), которое в настоящее время координирует работу различных групп, развивающих отдельные направления использования протокола, и предлагающих новые версии стандарта, а также ведет реестр разработчиков программного обеспечения для протокола Z39.50.

Назначение

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

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

Во-первых, очевидно, что различные базы данных имеют разную структуру хранения информации. Это означает, что записи БД (документы) могут иметь разные наборы полей, в каждом конкретном случае поля совершенно по-разному называются, одни и те же поля могут трактоваться по-разному, а, следовательно, и наполняться данными по-разному в различных системах. Возьмем, к примеру, поле АВТОР, встречающееся в любой библиографической БД. В различных БД информация хранится в соответствии с разными стандартами (а иногда и вовсе без всяких стандартов, просто так, как сочли удобным разработчики). Следовательно, в этом поле могут содержаться совершенно разные значения. Например, если структура документа соответствует записи формата MARC, то в поле Автор, скорее всего, будет содержаться фамилия первого автора источника (т.е. поле 100 формата USMARC). Однако, поля БД могут формироваться исходя из других соображений, и тогда в поле АВТОР могут содержаться повторяющиеся значения, то есть фамилия не только первого автора, а все авторы источника вместе. Подобная ситуация происходит и с другими полями, например, когда выделяется основное заглавие документа, а все остальные (подзаголовок, альтернативные заглавия и т.д.) заносятся в одно поле. Очевидна, что такая неопределенность вносит определенные неудобства, как при поиске информации, так и на этапе ее выдачи пользователю.

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

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

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

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

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

Что же кардинально нового предлагает протокол Z39.50?

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

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

Основные положения протокола Z39.50

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

Каждый элемент этой абстрактной модели подробно описывается до однозначного толкования и стандартизуется с присвоением уникального идентификатора - OID. Работа с каждой конкретной СУБД должна быть организована только через эту абстрактную модель путем обмена пакетами данных (APDU), содержащими последовательности идентифицируемых по меткам объектов. В стандарте описаны следующие классы объектов:

• Контекст приложения (context),
• APDU,
• Аттрибуты (attributeSet),
• Диагностика (diagnostic),
• Структура записей (recordSyntax),
• Синтаксис преобразований (transferSyntax),
• Отчета по ресурсам (resourceReport),
• Контроль доступа (accessControl),
• Расширенный сервис (extendedService),
• Пользовательская информация (userInfoFormat),
• Элементы (elementSpec),
• Варианты (variantSet),
• Схема данных (schema),
• Схема меток (tagSet).

Внутри класса объекты идентифицируются номерами, дабавляемыми к классовому номеру. Например, в классе 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} и т.п.

В течение поисковой сессии происходит обмен APDU между клиентом и сервером, инициатором которых чаще всего выступает клиент. Основные APDU следующие:

• Init
• Search,
• Present,
• DeleteResultSet,
• Scan,
• Sort,
• Segment,
• ExtendedServices,
• Close.

Таким образом, абстрактная модель БД, представленная протоколом отображается на конкретную модель существующей базы данных. Задача разработчика системы состоит в том, чтобы правильно отобразить абстрактную модель данных протокола на существующую структуру БД и сопоставить соответствующие элементы.

Общение клиента и сервера

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

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

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

Иными словами, сессия - это последовательность взаимосвязанных операций, причем, каждая последующая операция выполняется только по завершении предыдущей и основана на ее результатах.

Прежде всего, происходит процесс инициализации соединения. Клиентское приложение посылает серверу запрос на соединение, передавая при этом такие сведения о себе, как используемая версия протокола, максимальные размеры записей, допустимые операции и так далее. Такой запрос передается в соответствующем APDU - InitializeRequest. В ответ сервер отправляет клиенту APDU InitializeResponse, в котором пересылает клиенту тот же набор параметров, но уже со своими значениями. Таким образом стороны "договариваются" о том, какие возможности протокола могут быть использованы в ходе сессии. После ответа сервера клиенту открывается новая сессия. В ходе этой сессии пользователь может формулировать и посылать серверу поисковые запросы, просматривать результат поиска, сортировать выдачу, просматривать поисковые индексы, удалять результаты поиска и так далее. Закрывается сессия либо по инициативе клиентского приложения, посылающего серверу 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). Полную информацию о наборе атрибутов Bib-1 вы сможете получить здесь: ftp://ftp.loc.gov/pub/z3950/defs/bib1.txt.

Примером развернутого в строку RPN-запроса может быть запрос на поиск записей, в которых автор начинается на "Jhon" и встречается в любой позиции поля:

@attr 1=1003 @attr 2=3 @attr 3=3 @attr 5=1 {John}
        где
                Bib-1 @attr 1=1003  - соответсвует author,
                @attr 2=3 - равно,
                @attr 3=3 - любая позиция в поле,
                @attr 5=1 - усечение справа,
                John - поисковый термин

Естественно то, что серверу передается не строка запроса, а древовидная RPN-структура, где каждая пара "атрибут=значение" представлена отдельным элементом. Такая организация системы запросов позволяет с одной стороны однозначно отобразить логику запроса, абстрагируясь от синтаксиса запроса конкретной СУБД, а с другой - абстрагироваться от поисковых полей конкретной базы данных, так как запрос формулируется всегда в терминах абстрактного набора атрибутов, например, Bib-1. Кроме Bib-1, ориентированного на работу с библиографическими базами данных, сегодня стандартизованы и другие наборы атрибутов, например, STAS - 2000 атрибутов для научно-технической информации, GEO - 2000 атрибутов для геоинформационных систем и др.

Запросы RPN (Type-1) - не единственно допустимый тип запросов в Z39.50. Стандарт 1995 года (версия 3) допускает запросы Type-0 - запросы в синтаксисе конкретной СУБД, запросы Type-2 - запросы в синтаксисе Common Command Language (CCL - ISO 8777) и др. В настоящее время ведется обсуждение включения в Z39.50 запросов в синтаксисе SQL.

Ответом на поисковый запрос служит APDU SearchResponse, который содержит такую информацию, как количество найденных записей и номер следующей извлекаемой записи. Поскольку протокол рассчитан на сессионное взаимодействие, и каждое последующее действие выполняется только по результатам предыдущего. Мы не можем сразу же просмотреть найденные записи. В APDU ответа на поиск найденные записи не передаются. Для этого нужно послать серверу запрос на выдачу нужных записей - PresentRequest.

При запросе на выдачу серверу передается имя результирующего множества, из которого мы просматриваем записи, номер записи, с которой начинается просмотр, количество выдаваемых записей, формат выдачи и набор элементов (все поля или только часть). Получив такой запрос, сервер обращается к результирующему множеству, выбирает нужные записи, преобразует их в требуемый формат и возвращает клиенту в APDU PresentResponse.

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

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-форматах - как правило Usmarc или Unimarc или же Rusmarc, если мы имеем дело с отечественным сервером.

Поскольку извлекаемые записи могут иметь значительную длину, а их поля (элементы) - различные типы данных, стандарт позволяет извлекать ограниченный список полей из записи. Такие списки называются "наборами элементов" (elementSet). Минимально допустимы два набора элементов - Full (F) и Brief (B).

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

Заключение

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

1. Поддержка сессионного взаимодействия и четко определенный порядок этого взаимодействия. Иными словами - унификация способа передачи информации.
2. Идеология абстрактной модели данных - унификация представления информации.
3. Принцип стандартизованной выдачи данных - унификация обмена данными.

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

Список литературы

1. Жижимов О.Л. Введение в Z39.50. - Новосибирск: Изд-во НГОНБ, 2000.
2. Материалы Z39.50 Maintenance Agency http://lcweb.loc.gov/z3950/agency/
3. Племнек А.И., Усманов Р.Т. Практика построения Z39.50-интерфейсов к библиографической реляционной базе данных для региональной библиотечной системы RUSLANet // Материалы международной библиотечной конференции "Информационные технологии в библиотеках на рубеже веков: проблемы, поиск, решения".-Минск: Красико-принт, 1999.-с.41-48.
4. Сысойкина М. А. Протокол Z39.50 для гуманитариев // Теория и практика научной информации, Т.18, 2002 г (в печати)