| Предыдущая | Содержание | Следующая |
Технология сетевого доступа к базам данных по протоколу Z39.50 существенно отличается от других технологий. Отличие обусловлено самой сутью протокола: ориентация на работу с базами данных, абстрагирование от конкретных систем, жесткая регламентация структуры пересылаемых данных.
В основе Z39.50 (здесь и ниже см. описание стандарта) лежит идея построения абстрактной модели работы с абстрактной базой данных. Каждый элемент этой абстрактной модели подробно описывается до однозначного толкования и стандартизуется с присвоением уникального идентификатора – OID. Работа с каждой конкретной СУБД согласно Z39.50 должна быть организована только через эту абстрактную модель путем обмена пакетами данных (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} и т.п.
Согласно стандарту Z39.50 взаимодействие клиента (origin) и сервера (target) начинается посылкой клиентом серверу APDU InitializeRequest и приемом от него APDU InitializeResponse. При этом стороны согласовывают между собой версию протокола, максимальные размеры записей, допустимые команды и другие параметры. В момент инициализации может быть проведена аутентификация пользователя. За успешной инициализацией следует открытие сеанса, который может быть закрыт получением одной из сторон APDU close. В течение сеанса происходит обмен APDU, инициатором которых чаще всего выступает клиент. Основные APDU следующие: Search, Present, DeleteResultSet, Scan, Sort, Segment, ExtendedServices.
Команда Search формируется с указанием списка баз данных и собственно запроса. Среди множества типов запросов, указанных в стандарте, обязательным для поддержки сервером Z39.50 является запрос типа 1 (RPNquery – запрос в обратной польской нотации). RPNquery – последовательность опрераторов и операндов. В качестве операндов могут использоваться: RPNquery, набор данных (resultSet) или комбинация атрибутов и поисковых термов. Существенно, что в качестве атрибутов можно использовать только их номера по выбранному стандартному набору атрибутов, имеющему свой OID. Наиболее распространен набор атрибутов Bib-1 {OID Z39.50 3 1}, включающий 99 поисковых (Use) атрибутов (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-структура, упакованная согласно спецификациям ASN.1-BER в APDU SearchRequest для передачи по сети.
Такая организация системы запросов позволяет с одной стороны однозначно отобразить логику запроса, абстрагируясь от синтаксиса запроса конкретной СУБД, а с другой - абстрагироваться от поисковых полей конкретной базы данных, так как запрос формулируется всегда в терминах абстрактного набора атрибутов, например, 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.
В результате описанной выше процедуры найденные записи сохраняются в рабочих наборах данных на стороне сервера и могут быть использованы в течение сеанса для уточнения поиска и извлечения по команде Present. Эта команда возвращает затребованное количество записей клиенту в необходимом формате внешнего представления. Форматы представления стандартизованы в классе RecordSyntax {Z39.50 5} и включают MARC-форматы ISO-2709 (Unimarc, Usmarc, CCF, SBN и т.д.), неструктурированный текстовый формат SUTRS, структурированные тэговые форматы (GRS-1, Summary), специальные форматы (HTML, XML, PDF, TIFF, GIF) и другие. Структурированные форматы позволяют после передачи по сети полностью сохранить первоначальную структуру записи, в отличие от других протоколов (http, ftp и др.), что является немаловажным в распределенных системах.
Поскольку извлекаемые записи могут иметь значительную длину, а их поля (элементы) могут иметь существенно различный тип данных, стандартом предусмотрена возможность извлечения ограниченного списка полей из записи. Список полей, допускающих одновременное присутствие во внешнем представлении записи, называется «набором элементов» (elementSet). Минимально допустимы два набора элементов – Full (F) и Brief (B).
Идеология максимального абстрагирования от структур реальных баз данных приводит к весьма изощренной схеме извлечения данных, описанной в стандарте Z39.50: записи из результирующих наборов отображаются в записи абстрактной базы данных через схему, определяющую абстрактную структуру записи в виде дерева элементов, специфицируемых метками (tag) из стандартных наборов (tagSet); затребованные элементы выбираются в нужной альтернативной форме (variant) из абстрактной записи и отображаются в экспортируемую структуру, определяемую форматом внешнего представления (recordSyntax). Все объекты описанной процедуры (schema, tagSet, elementSpec, variantSet, recordSyntax) определены в соответствующих классах с присвоением OID.
Стандартом Z39.50 версии 3 предусмотрена специальная база данных IR-Explain-1, в которой сервер может хранить информацию о своей конфигурации, базах данных, атрибутах, форматах и других поддерживаемых им объектах (всего 17 категорий).
К этой базе метаданных клиент должен обращаться с запросами RPN по атрибутам Exp-1 {Z39.50 3 2} и получать записи в структурированном формате Explain {Z39.50 5 100}, не запрещается дополнительно поддерживать другие форматы записей Explain (SUTRS, GRS-1). Поддержка (необязательная) сервером Z39.50 базы данных Explain позволяет клиентам дополнительно настраиваться на его конфигурацию. Это важная возможность при построении графических рабочих мест клиента Z39.50 с развитой системой самонастраивающихся меню.
| Предыдущая | Содержание | Следующая |
© ОИГГМ СО РАН, 2003-2006