«ПОСТРОЕНИЕ РАСПРЕДЕЛЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ НА ОСНОВЕ ПРОТОКОЛА Z39.50 ...»

РОССИЙСКАЯ АКАДЕМИЯ НАУК

СИБИРСКОЕ ОТДЕЛЕНИЕ

Объединенный институт геологии, геофизики и минералогии

им. академика А.А. Трофимука

На правах рукописи

Жижимов Олег Львович

ПОСТРОЕНИЕ

РАСПРЕДЕЛЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

НА ОСНОВЕ ПРОТОКОЛА Z39.50 Специальность 05.25.05 – информационные системы и процессы, правовые аспекты информатики Диссертация на соискание ученой степени доктора технических наук

Научный консультант:

доктор физ.-мат. наук, чл.-корр. РАН Федотов Анатолий Михайлович НОВОСИБИРСК - Оглавление Введение 1 РИС: основные определения и требования 1.1 Что такое РИС.......................................... 1.2 Основные типы информационных систем.......................... 1.3 Требования к РИС....................................... 1.3.1 Распределенные данные................................ 1.3.2 Гетерогенные данные.................................. 1.3.3 Виртуальные данные.................................. 1.3.4 Абстрактная модель данных.............................. 1.3.5 Абстрактная модель поиска.............................. 1.3.6 Системная информация................................ 1.3.7 Разграничение доступа................................. 1.3.8 Аутентификация пользователей............................ 1.3.9 Учет............................................ 1.3.10 Расширяемость..................................... 1.3.11 Связь с другими системами.............................. 1.3.12 Открытость....................................... 1.3.13 Простота доступа к ресурсам............................. 1.3.14 Быстродействие..................................... 1.4 Выводы.............................................. 2 Z39.50 как технология РИС 2.1 Технологии построения РИС.................................. 2.2 Z39.50 как технология РИС.................................. 2.2.1 История протокола Z39.50............................... 2.2.2 Область действия протокола Z39.50......................... 2.2.3 Модель взаимодействия................................ 2.2.4 Сеанс связи....................................... 2.2.5 Дополнительные функции............................... 2.3 Недостатки Z39.50 как технологии РИС........................... 2.4 CIP – попытка модернизации Z39.50 для РИС....................... 2.5 Технологии Z39.50 и требования к РИС........................... 2.5.1 Открытость....................................... 2.5.2 Интероперабельность.................................. 2.5.3 Расширяемость..................................... 2.5.4 Абстрактная модель поиска.............................. 2.5.5 Абстрактная модель данных.............................. 2.5.6 Виртуальные данные.................................. 2.5.7 Гетерогенные данные.................................. 2.5.8 Распределенные данные................................ 2.5.9 Системная информация................................ 2.5.10 Разграничение доступа................................. 2.5.11 Аутентификация пользователей............................ 2.5.12 Учет............................................ 2.5.13 Простота доступа к ресурсам............................. 2.5.14 Быстродействие..................................... 2.6 Администрирование распределенных систем........................ 2.6.1 Пополнение, модификация и удаление информации................ 2.6.2 Мониторинг целостности РИС............................ Выводы................................................. 3 Наполнение РИС 3.1 Общие требования к данным в РИС............................. 3.2 Особенности метаданных в Z39.50.............................. 3.3 Типы информационных ресурсов............................... 3.3.1 Библиографические информационные системы................... 3.3.2 Научно-техническая библиографическая информация............... 5.5 Свойства РИС на основе серверов ZooPARK........................ 5.5.9 Сбор статистической информации о работе РИС.................. 5.6 Инсталляции сервера ZooPARK в России.......................... 6.4 Информационные системы корпоративных проектов ИОО................ 6.4.1 Корпоративная библиотечная РИС Новосибирска................. 6.4.3 Корпоративная библиотечная РИС Ярославль................... 6.4.4 Корпоративная библиотечная РИС Нижний Новгород.............. 6.5 Информационная система по газгидратам.......................... 6.5.4 Пространственная привязка и интерфейсы пользователя............. Введение Актуальность темы. Широкое использование современных средств доступа к информационно–вычислительным ресурсам открыло принципиально новые возможности использования информационных технологий и вычислительной техники. Современные информационные технологии, позволяющие создавать, хранить, перерабатывать и обеспечивать эффективные способы представления информационных ресурсов потребителю, стали важным фактором жизни общества и средством повышения эффективности управления всеми сферами общественной деятельности. Информация является важнейшим стратегическим ресурсом, а наибольший экономический и социальный успех сегодня сопутствует тем странам, которые активно используют современные средства компьютерных коммуникаций и сетей, информационных технологий и систем управления информационными ресурсами.

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

Если рассматривать только информационные ресурсы, не касаясь ресурсов вычислительных, такие как электронные каталоги библиотек, реферативные и полнотекстовые библиографические базы данных, музейные электронные коллекции, результаты наблюдений и экспериментов, цифровые фото–, аудио–, видео коллекции и многое–многое другое, то основная их часть находится в базах данных, которые управляется различными СУБД1. Спектр этих ресурсов широк, но их объединяет одно свойство все эти ресурсы упорядочены, хотя упорядочены по-разному.

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

СУБД Система Управления Базами Данных.

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

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

Для реализации этой цели в диссертации последовательно решен ряд задач, а именно:

1. определены основные пользовательские и эксплутационные требования, предъявляемые к современным РИС, на основе анализа мирового опыта построения и эксплуатации распределенных информационных систем;

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

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

4. создано многоплатформенное серверное программное обеспечение, способное функционировать в качестве основного в РИС;

5. построена экспериментальная РИС на основе нескольких серверов для проверки как работоспособности серверного программного обеспечения, так и для изучения основных характеристик РИС в различных режимах работы;

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

На защиту выносятся 1. Определение основных требований, которые предъявляются к РИС, обеспечивающих сетевой доступ к разнородным информационным ресурсам, управляемыми различными СУБД.

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

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

4. Разработка принципов организации серверного программного обеспечения, способного как функционировать в РИС на основе Z39.50, так и обеспечивать доступ к разнородным информационным ресурсам, хранящимся в различных СУБД.

5. Создание оригинального многоплатформенного модульного серверного программного обеспечения ZooPARK, способного функционировать в качестве базового в РИС и предоставлять пользователям различные интерфейсы (Z39.50, WWW, SRW ) для доступа к разнородной информации.

6. Внедрение серверов ZooPARK в эксплуатацию в составе промышленно эксплуатируемых РИС в различных регионах России (Новосибирск, Москва, Омск, Нижний Новгород, Ярославль и др.).

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

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

Практическая значимость. Разработанные принципы построения РИС на основе протокола Z39.50 явились основой созданного серверного программного обеспечение ZooPARK, которое в настоящее время функционирует более чем в ста организациях России, в том числе в таких крупных библиотеках как библиотека Государственной Думы РФ (Москва), ГПНТБ России (Москва), ГПНТБ СО РАН (Новосибирск), Центральной научной сельскохозяйственной библиотеке (ЦНСХБ, Москва), Библиотеке по естественным наукам РАН (БЕН РАН, Москва), Всероссийской государственной библиотеке иностранной литературы (ВГИБЛ, Москва), библиотеке Санкт-Петербургского университета, Новосибирской государственной областной научной библиотеке (НГОНБ, Новосибирск) и многих других. На основе серверов ZooPARK и Z-IRBIS 3 построены и успешно функционируют распределенные информационные системы ОИГГМ СО РАН, СО РАН, РИС LibWeb 4, корпоративные региональные библиотечные системы Новосибирска, Москвы, Омска, Ярославля, Нижнего Новгорода. Кроме этого, на основании работ по созданию специализированного программного обеспечения Z39. и построения РИС на его основе при поддержки Института ’Открытое Общество’ (Фонд Сороса) создан учебный курс и выпущено учебное пособие [3] - [6], претерпевшее четыре издания.

Апробация результатов. Основные положения диссертации обсуждались на III - XI международных конференциях ”Крым” - ”Библиотеки и ассоциации в меняющемся мире: новые технологии и новые формы сотрудничества” (Форос, 1996 [22]; Судак, 1997 [24], 1999 [25–27], [28–30], 2001 [31] - [35], 2002 [36] - [39], 2003 [40], 2004 [41, 42]); на I - VIII международных рабочих совещаниях по электронным публикациям (ELPUB) (Новосибирск, 1996, 1997, [43], 1998, 1999 [44–46], 2000, [47,48], 2001, 2002, 2003); на II - VII Всероссийских конференциях ”LIBCOM” (Москва, 1997 - 1999; Звенигород, 2000 - 2003); на VII и VIII международных научно-практических конференциях - ”Информационные системы и технологии” (Владивосток, 2000, 2001); на международных конференциях ”Central Asia” – ”Библиотечно-информационные ресурсы в науке, обраСервер Z-IRBIS является упрощенной версией сервера ZooPARK. Z-IRBIS оптимизирован для работы с библиографическими базами данных ИРБИС (ГПНТБ России, Москва).

Проект LibWeb финансировался РФФИ с 1995 года (проекты № 95-07-19417, № 98-07-90394, № 01-07-90445) и с 1997 года РГНФ (проект № 96-05-12025).

зовании, культуре и бизнесе” (Узбекистан, Самарканд, 1999 [49]; Бухара, 2002 [50,51]); на II международной конференции ”Интернет - Общество Личность - 2000 (ИОЛ-2000): Новые информационно-педагогические технологии” (Санкт-Петербург, 2000) [52]; на II - V всероссийской научной конференции ”Электронные библиотеки: перспективные методы и технологии, электронные коллекции” (Протвино, 2000 [53–55]; Петрозаводск, 2001 [56]; Дубна, 2002 [57]; Санкт-Петербург, 2003 [58, 59]), на международных конференциях EVA-2000 [60,61], EVA-2003 [62] (Москва), на 6-ой Международной конференции ”НТИ-2002: Информационное общество, интеллектуальная обработка информации, информационные технологии” (Москва, ВИНИТИ, 2002) [63–65], Western Pacic Geophysics Meeting 2000 (American Geophysical Union) [66], VI International Conference on Gas in Marine Sediments (S-Petersburg, 2000), [67] а также на ряде других конференций, рабочих совещаний и семинаров, организованных РАН, РФФИ, СО РАН (Иркутск, 2002 [68–71]; Новосибирск, 2004 [76]), ГПНТБ СО РАН (Новосибирск, 1996 [23], 2002 [72–74]), Институтом развития информационного общества (ИРИО, Москва, 1999 [75], 2001 [15]) и др. Апробацией практических результатов работы можно считать включение разработчиков ZooPARK в реестр реализаторов Z39.50 (Z39.50 Register of Implementors, см. [77]) с ID=155 и постоянное тестирование всех инсталлированных серверов ZooPARK и Z-IRBIS российскими и зарубежными роботами.

Публикации. Материалы по теме диссертации были опубликованы в виде монографии (см. [2]); как учебные пособия (четыре издания, см. [3] как статьи в журналах (см. [7] - [21]); как доклады в сборниках трудов российских и международных конференций (см. [22] - [76]); как техническая документация на программные продукты (см. [78,79]); как содержательные отчеты по грантам Института ”Открытое Общество” (Фонд Сороса, Россия) I2A708 [80], PFC944 [81], PFC00F [82].

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

Основное содержание работы

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

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

Для РИС в целом формулируется список пользовательских и административных задач, из которых вытекают технологические и функциональные требования, которые предъявляются к распределенным информационным системам:

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

Гетерогенные данные – информационная система должна предоставлять доступ к распределенным данным, управляемыми различными СУБД на серверах с различной программно-аппаратной платформой.

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

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

Абстрактная модель поиска – система должна оперировать не конкретным синтаксисом запросов, а его логической сутью на основе абстрактных атрибутов, поскольку привязка поиска к синтаксису запросов конкретной подсистемы или СУБД ограничивает возможности сквозного поиска в других подсистемах.

Системная информация – система должна предоставлять полную и достоверную информацию о себе и обо всех своих ресурсах.

Разграничение доступа – система должна быть способна предоставлять различные уровни привилегий для пользователей по доступу к информации.

Аутентификация пользователей – распределенная информационная система должна обеспечивать единый домен аутентификации пользователей для предоставления авторизованного доступа к информации.

Учет – система должна обеспечивать сбор и обработку статистики по запросам пользователей и ведение их бюджетов.

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

Связь с другими системами – система должна иметь возможность интегрировать свои ресурсы с ресурсами других информационных систем.

Открытость – информационная система должна быть основана на открытых стандартах и протоколах.

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

Быстродействие – любая распределенная информационная система должна обрабатывать пользовательские запросы за приемлемое для него время.

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

• Отсутствие описания модели 3-х уровневого взаимодействия не регламентирует функционирование серверов промежуточного слоя и порождает тем самым возможность реализации различных режимов • Отсутствие описания механизмов переадресации запросов.

• Отсутствие описания механизмов контроля маршрутизации запросов.

• Отсутствие описания распределенного учета интегрированных системных ресурсов РИС.

• Отсутствие описания схем аутентификации пользователей в многосерверной среде.

• Отсутствие описания технологии учета статистической информации На основании наличия этих недостатков утверждается, что стандарт Z39.50 при своем создании не предназначался для построения РИС и не описывает режимы их функционирования. Однако, в рамках Z39. возможно создание специфических расширений стандарта, устраняющих эти недостатки Z39.50 как технологии построения РИС. Эти расширения далее подробно рассматриваются при анализе деталей функционирования РИС на основе Z39.50 с позиции требований, предъявляемых к РИС. Подчеркивается, что эти расширения можно обеспечить собственными механизмами Z39.50, что иллюстрируется примером частного расширения стандарта на основе протокола CIP (Catalogue Interoperability Protocol ) [83].

Рассмотрены возможные реализации РИС применительно к семиуровневой модели сетевого взаимодействия ISO 5 /OSI 6, способы и механизмы обеспечения распределенности в РИС на основе Z39.50, такие как объединение баз данных и переадресация запросов, а также возможные режимы работы серверов Z39.50 с точки зрения выбора наиболее оптимальной по времени обработки запросов пользователей конфигурации РИС.

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

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

В третьей главе сформулированы требования, предъявляемые к информации, к которой может быть обеспечен доступ в РИС, исходя из предпосылки, что интеграция информационных ресурсов в РИС возможна только на уровне метаданных. Основные требования при этом ISO - International Standards Organization OSI – Open Systems Interconnect сводятся к требованию стандартизации типов метаданных, причем для интероперабельности РИС эта стандартизация должна быть глобальной, и к требованию соответствия схем данных модели данных Z39.50.

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

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

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

Для сервера Z39.50 : обеспечение основных протокольных процедур OID (Object Identicator ) – идентификатор объекта, соответствующий квалификатору иерархического рубрикатора ISO.

и дополнений (search, present, deleteSet, resourceReport, scan, namedResultSet, negotiation, queryType104 ), адаптируемость к различным СУБД, параллельные операции, поддержка сервиса Explain, аутентификация пользователей в том числе и через LDAP, контроль доступа, протоколирование, работа в РИС. Для обеспечения работы РИС в соответствии с моделью данных Z39.50 сервер должен поддерживать различные схемы данных (GILS, Collection, CIMI, ZThes, GEO), в том числе и не имеющих глобальных OID (Explain, PERSON, ZSTAT и др.), форматы внешнего представления (SUTRS, GRS-1, XML, HTML, USmarc, RUSmarc, UNIMARC ) и наборы поисковых атрибутов (Bib-1, GILS, Exp-1, CIMI, ZThes, Collection, GEO, XD-1, Util-1 ). Дополнительно для интеграции с реляционными СУБД и согласования реляционных и иерархических моделей данных сервер должен поддерживать спецификации Z+SQL (запросы Type-104 SQL, формат SQL-RS ).

Для сервера HTTP: поддержка протокола 1.0/1.1 и обеспечение доступа к документам HTML и др., поддержка методов GET, POST, поддержка PHP и PERL, поддержка SOAP/SRW для интеграции с сервис-ориентированными WEB -системами и обеспечение функционирования шлюза Z39.50-HTTP для организации пользовательских точек входа в РИС.

Для шлюза Z39.50-HTTP: генерация HTML-страниц на основе правил интерпретатора встроенного языка или любого внешнего интерпретатора; обработка запросов пользователей для методов GET и POST ; предоставление пользователю интерфейсов различного уровня сложности для создания поисковых запросов на основе модели поиска Z39.50 с различными наборами поисковых атрибутов;

осуществление многобазового параллельного поиска информации в соответствии с моделью поиска Z39.50 ; извлечение данных в различных форматах внешнего представления; представление данных формата GRS-1 в соответствии с предопределенными шаблонами для различных схем данных; представление библиографических данных форматов семейства ISO-2709 в виде, допускающем наглядное отображение информации через WEB -броузер; сохранение записей в различных форматах на компьютере клиента WEB ; поиск и просмотр записей БД IR-Explain-1 различных категорий в формате Explain; поиск и просмотр записей в схеме Zthes-1 для тезаурусов и классификационных схем; поддержка различных кодовых таблиц для кириллических текстов; протоколирование всех обрабатываемых шлюзом APDU 8 на сервере сбора статистики в РИС;

предоставление интерфейсов для поиска, извлечения и просмотра в WEB -браузере статистической информации о работе РИС.

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

Пятая глава посвящена серверному программному обеспечению ZooPARK, разработанному под руководством и непосредственном участии автора на основе требований к программному обеспечению РИС, изложенных выше. В ней приведены основные характеристики сервера ZooPARK (Z-IRBIS ), сопоставленные с упомянутыми требованиями, рассмотрена архитектура сервера (см. рис. 5.3), построенного по модульному принципу и легко адаптируемого для работы с нештатными источниками данных (см. рис. 5.4). Приводится список созданAPDU (Application Protocol Data Unit) – пакет данных прикладного уровня модели ISO/OSI.

ных для сервера провайдеров данных для различных СУБД и АБИС (Автоматизированная библиотечно-информационная система).

Далее приводится перечень расширений сервера ZooPARK и соответствующим им объектов с локальными OID, обеспечивающих необходимую функциональность сервера (см. таблицу 5.4, символ Z эквивалентен префиксу OID Z39.50 : 1.2.840.10003). Эти расширения относятся в первую очередь к адаптации сервера для работы в РИС по протоколу Z39.50 и обслуживанию нестандартных схем данных в соответствии с абстрактной моделью данных Z39.50. Утверждается, что модель и номенклатура типов данных сервера ZooPARK соответствуют требованиям, обсуждавшимся выше.

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

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

В части обеспечения требования распределенности данных для РИС на основе серверов ZooPARK рассматриваются детали реализации в сервере возможности переадресации запросов, контроля маршрутизации запросов и контроля петель переадресации в специфическом провайдере данных Z-REMOTE.

Обеспечения доступа к системной информации в РИС на основе серверов ZooPARK демонстрируется показом пользовательских интерфейсов сервиса Explain через встроенный в сервер шлюз.

В части сбора статистической информации о работе РИС и предоставления доступа к ней приводятся различные сценарии обеспечения этого требования серверами ZooPARK в РИС на основе локальной схемы данных ZSTAT и спецификаций Z+SQL, допускающего групповые операции. Демонстрируются интерфейсы пользователя для доступа к этой информации через встроенный шлюз.

Расширяемость РИС на основе серверов ZooPARK по номенклатуре поддерживаемых СУБД обеспечивается модульностью сервера и его адаптируемостью к различным источникам данных.

В части обеспечения простоты доступа к ресурсам РИС указывается на существование в сервере ZooPARK встроенного шлюза Z39.50-HTTP, что позволяет организовать точку доступа в РИС на основе Z39.50 в среде WEB без привлечения специализированного клиентского программного обеспечения Z39.50.

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

В заключение главы приводится статистика инсталляций серверов ZooPARK и Z-IRBIS, которая указывает на их популярность.

Шестая глава посвящена практическому применению серверов ZooPARK и Z-IRBIS при построении и эксплуатации РИС. Рассматриваются РИС ОИГГМ СО РАН, СО РАН, LibWeb, РИС проектов ИОО по созданию корпоративных библиотечных систем (Новосибирск, Москва, Ярославль, Нижний Новгород, Омск) и информационная система по газгидратам (Брюссель), в которых эксплуатируется серверное программное обеспечение ZooPARK и Z-IRBIS. Приведено краткое описание каждой из перечисленных РИС, их архитектура и состав. Указывается на возможность ZooPARK обеспечить функционирование региональных РИС, высокую степень их интероперабельности и, как следствие, их интегрирование в мировое информационное пространство.

В Заключении сформулированы основные выводы диссертации.

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

В Приложении B приведены схемы данных UIGGM, PERSON, ZSTAT, разработанных для сервера ZooPARK и имеющих локальные OID.

В Приложении C приведен список, содержащий более 100 организаций, в которых на 1.09.2004 установлены серверы ZooPARK или ZIRBIS.

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

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

Более детально, на защиту выносятся следующие положения:

1. Определение основных требований, которые предъявляются к РИС, обеспечивающих сетевой доступ к разнородным информационным ресурсам, управляемыми различными СУБД.

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

3. Разработка расширений Z39.50, в том числе схем данных, необходимых для РИС, но отсутствующих в глобальном реестре Z39.50, которые удовлетворяют модели данных Z39.50 и не только расширяют спектр описываемых информационных ресурсов (схемы ZSTAT, PERSONS ), но и разрешают (схема UIGGM ) ряд противоречий в традиционных библиографических схемах (форматах) данных.

4. Разработка принципов организации серверного программного обеспечения, способного как функционировать в РИС на основе Z39.50, так и обеспечивать доступ к разнородным информационным ресурсам, хранящимся в различных СУБД.

5. Создание оригинального многоплатформенного модульного серверного программного обеспечения ZooPARK, способного функционировать в качестве базового в РИС и предоставлять пользователям различные интерфейсы (Z39.50, WWW, SRW ) для доступа к разнородной информации.

6. Внедрение серверов ZooPARK в эксплуатацию в составе промышленно эксплуатируемых РИС в различных регионах России (Новосибирск, Москва, Омск, Нижний Новгород, Ярославль и др.).

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

1.1 Что такое распределенная информационная система Словосочетание распределенная информационная система для однозначной трактовки изложенного в настоящей работе материала требует некоторого пояснения. Дело в том, что в это понятие различные авторы вкладывают различный смысл.

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

Согласно такому определению, в распределенных информационных системах (РИС) не требуется исполнение распределенных приложений, а, следовательно, класс актуальных для них задач, решаемых, вообще говоря, при помощи широко обсуждаемых сегодня технологий распределенных систем [6] (.NET, J2EE, CORBA и др.) может быть существенно сужен.

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

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

Рис. 1.1: Типичная схема распределенной модульной информационной системы Моноблочные ИС построены в виде единого комплекса программноаппаратных средств. Все составляющие таких ИС как правило хорошо взаимодействуют между собой, используя недокументированные или плохо документированные интерфейсы и протоколы. Моноблочные ИС чаще всего ориентированы на работу с конкретными СУБД, трудно поддаются расширению и обладают плохой интероперабельностью. Тем не менее, в конкретной тематической области они позволяют создать достаточно эффективные системы, обеспечивающие быстрый поиск и извлечение информации, полное администрирование и высокую степень защиты данных на различных уровнях. Моноблочные ИС трудно считать распределенными, т.к. они, как правило, функционируют или на конкретном компьютере или на заведомо предопределенном их списке (кластере). Распределенность моноблочных ИС может достигаться применением распределенных СУБД или разнесением функциональных блоков ИС по разным компьютерам. Последнее переводит моноблочную ИС в другую категорию.

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

Наиболее общий вид распределенной модульной информационной системы изображен на Рис. 1.1. Стрелками показаны сетевые взаимодействия модулей. При этом можно явно выделить семь логических уровней, которые представлены на Рис. 1.2:

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

2. Транспортный уровень ”клиент – сервис-провайдер” – сеть, т.е. среда, обеспечивающая связь клиента с сервисными службами РИС. На сегодняшний день эта среда чаще всего представляет собой среду Интернет.

3. Уровень сервисных служб РИС – совокупность сетевых точек доступа в РИС. На этом уровне производится предварительная обработка запросов клиента для приведения их в соответствие с конкретными СУБД. В качестве субъектов этого уровня могут выступать различные серверы приложений, WEB-серверы с соответствующей настройкой, серверы Z39.50.

4. Транспортный уровень ”сервис-провайдер – СУБД” – характерен для СУБД, имеющих сетевые интерфейсы, например, SQLсерверы (ORACLE, MS SQL Server и др.). Как правило, в качестве среды на этом уровне используются защищенные сети и ЛВС. Однако очень часто используется и Интернет.

5. Уровень СУБД – совокупность серверов с программным обеспечением СУБД 6. Транспортный уровень ”СУБД – данные” – как правило, ЛВС или защищенные сети.

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

1.3 Требования к РИС Исходя из задач, которые должны решаться распределенной информационной системой, можно сформулировать минимальный список требований, которым она должна удовлетворять [9].

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

В качестве примера глобальной распределенной информационной системы можно привести распределенную информационную систему по пространственным метаданным Clearinghouse [84], которая включает данные не одной сотни серверов (см. [85]), описанную в Приложении A.6.

1.3.2 Гетерогенные данные Распределенная информационная система должна предоставлять доступ не просто к распределенным данным, а к распределенным данным, хранящимся на серверах с различной программно-аппаратной платформой и управляемыми различными СУБД. Чем большее количество серверов охватывает РИС, тем актуальнее становится требование возможности работы с гетерогенными данными, т.к. трудно представить аппаратно-программное единообразие в большой распределенной информационной системе. В глобальных информационных системах подобное единообразие практически недостижимо.

Примером распределенной информационной системы с ярко выраженной гетерогенностью данных может служить РИС австралийского проекта Zavier (Z39.50 Arts Victoria Interoperability Project) [86] – экспериментального проекта создания точки доступа через Интернет к распределенным гетерогенным базам данных по викторианскому культурному наследию (см. Приложение A.4.2).

1.3.3 Виртуальные данные

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

В качестве примера логической группировки данных в распределенных информационных системах можно указать (см. рис. 1.3) иерархические коллекции CIP (Catalogue Interoperability Protocol ) [83, 87].

1.3.4 Абстрактная модель данных Информационная система строится на основе абстрактной схемы данных, на которую должны быть отображены конкретные базы данных.

Это позволяет объединять данные из разнородных систем в одной логической группе, обеспечивая тем самым требование виртуальности данных (см. 1.3.3).

В качестве примера РИС на основе абстрактной модели данных можно привести информационную систему проекта EULER (см. Приложение A.3.4).

1.3.5 Абстрактная модель поиска Информационная система должна оперировать не конкретным синтаксисом запросов, а его логической сутью на основе комбинаций абстрактных поисковых атрибутов. Привязка процедуры поиска информации к синтаксису запросов конкретной подсистемы или СУБД ограничивает возможности сквозного поиска в других подсистемах. Это требование вытекает, с одной стороны, из требования гетерогенности (см. 1.3.2), а с другой – из требования виртуализации данных (см. 1.3.3).

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

• список всех интегрированных в РИС серверов баз данных;

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

• описание всех поддерживаемых в РИС схем данных;

• описание поддерживаемой в РИС модели поиска информации;

• описание всех поддерживаемых форматов извлечения информации;

• описание правил ограничения доступа к информации;

1.3.7 Разграничение доступа Информационная система должна быть способна предоставлять различные уровни привилегий для пользователей по доступу к информации.

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

1.3.8 Аутентификация пользователей Требование разграничения полномочий пользователей в РИС (см.

1.3.7) приводит к необходимости аутентификация каждого пользователя РИС. Только после исполнения процедуры аутентификация пользователя можно говорить о наделении этого пользователя тем или иным списком полномочий в РИС. С одной стороны, аутентификация пользователя не является уникальной процедурой, т.к. она существует как в любой многопользовательской операционной системе, так и в любой многопользовательской СУБД. Однако, для распределенной информационной системы аутентификация пользователя должна быть однократной и однозначно пониматься всеми серверами, входящими в РИС. Фактически РИС должна выступать как единый домен аутентификации пользователей, в рамках которого каждый пользователь имеет свой список полномочий.

В качестве примера реализации аутентификации пользователей в РИС можно указать системы, основанные на упоминавшимся выше CIP (см. 1.3.3), в соответствии с которым в РИС должна существовать и поддерживаться специальная база данных пользователей IR-User-1, содержащая всю необходимую информацию о каждом пользователе РИС.

Другим примером аутентификации пользователей в РИС могут служить системы (см., например, [88–90]), в которых применяются технологии, основанные на LDAP.

1.3.9 Учет Информационная система должна уметь собирать исчерпывающую информацию о работе каждой своей подсистемы и, при необходимости, предоставлять доступ к этой информации. Необходимость доступа к подобной информации определяется административными задачами, связанными с обеспечением бесперебойной работы РИС и оптимизацией функционирования всех ее подсистем.

Другая часть задач, решаемых при помощи учета работы РИС, характерна для систем, предоставляющих доступ к информации на коммерческой основе. При этом для каждого пользователя РИС ведется собственный бюджет с фиксацией всех запросов к РИС и всей информации, извлекаемой из нее. Естественно, ведение пользовательских бюджетов невозможно без удовлетворения требований аутентификации пользователей (см. 1.3.8) и разграничения их прав в РИС (см. 1.3.7).

1.3.10 Расширяемость Распределенная информационная система должна легко расширяться 1. в части увеличения объема доступной в ней информации;

2. в части увеличения количества серверов и баз данных, которые в ней интегрированы;

3. в части правил, которые регламентируют функционирование РИС.

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

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

Способность РИС интегрировать свои ресурсы с ресурсами других систем позволяет организовывать большие информационные системы как совокупность отдельных полностью функциональных информационных подсистем с едиными пользовательскими интерфейсами для доступа к информации. Такая организация информационных систем полностью соответствует принципу виртуализации данных (см. 1.3.3).

Следует также подчеркнуть, что обсуждаемое требование интероперабельности РИС может быть удовлетворено лишь при выполнении требования открытости.

1.3.12 Открытость Информационная система должна быть основана на открытых стандартах и протоколах. Только использование полностью документированных, т.е. открытых, интерфейсов и стандартных1 протоколов взаимодействия всех подсистем в РИС может гарантировать ее расширяемость (см.

1.3.10) и интероперабельность (см. 1.3.11) при обеспечении доступа к распределенным (см. 1.3.1) и гетерогенным (см. 1.3.2) данным.

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

рано или поздно приведет к потере интероперабельности РИС.

1.3.13 Простота доступа к ресурсам Для пользователей информационная система должна предоставлять различные, в том числе и простые, интерфейсы доступа к информации.

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

Следует заметить, что практически все информационные системы, описанные в Приложении A, предоставляют доступ к информационным ресурсам, кроме прочих, и через WEB -интерфейсы. Для некоторых систем WEB -интерфейсы являются единственными.

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

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

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

Глава Z39.50 как технология РИС 2.1 Технологии построения распределенных систем Для разработки распределенных информационных систем сегодня используются различные технологии [6]. Большая часть этих технологий по своей сути ориентирована не на работу с базами данных, а на сетевое взаимодействие программ и распределенные вычисления в гетерогенных средах. Даже беглый обзор используемых или обсуждаемых технологий может составить предмет отдельного увесистого тома (см. [91, 92]). Поэтому ниже упомянуты лишь некоторые технологии.

RPC – технология удаленного вызова процедур широко применяется для разработки сетевых приложений, в том числе и приложений для доступа к базам данных. Технология обеспечивает аппаратно независимый обмен данными между различными платформами, но в общем случае требует одновременной разработки серверного и клиентского приложения. Последнее делает ее малопригодной для построения распределенных информационных систем с разнородными данными без дополнительной стандартизации. Тем не менее, именно эта технология лежит в основе DCE [93], DCOM/COM+ и многих специальных закрытых фирменных систем.

DCOM/COM+ – технологии фирмы Microsoft для работы с распределенными программными объектами общего назначения. Получила широкое распространение для платформы Windows NT/2000. Для работы с базами данных требует построения специальных объектов, реализующих специфичные для каждой СУБД методы. Фирма Microsoft предлагает набор объектов DCOM под общим названием OLE DB [94], позволяющий скрыть различия конкретных СУБД за общими программными интерфейсами, в том числе высокоуровневыми – MS ADO. Недостатки технологии OLE DB – уклон в сторону реляционной модели данных и, несомненно, недоступность на платформах, отличающихся от Intel-Windows.

RMI – технология распределенных вычислений в среде Java – набор интерфейсов для удаленных вызовов Java-приложений [92, 95, 96].

Технология ориентирована на взаимодействие программ, но не на взаимодействие баз данных. Для баз данных в Java существуют интерфейсы JDBC – аналог интерфейсов ODBC для среды Windows.

Недостаток этих интерфейсов – уклон в сторону реляционных систем и медлительность, которая является следствием большого объема промежуточных преобразований на линии ”клиент-сервер”. Для Java-приложений эта медлительность усугубляется медлительностью виртуальных Java-машин.

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

Z39.50 – протокол сетевого доступа к базам данных. Разработан специально для унификации интерфейсов доступа к различным базам данных на основе ASN.1 в 1988 году [1]. Включает описание не только протокольных процедур взаимодействия ”клиент-сервер”, но и идеологии организации этого взаимодействия.

HTTP – протокол обмена данными в среде WEB – ориентирован на обмен неструктурированными данными, что делает его малопригодным для доступа к базам данных. Однако, ввиду большой популярности WWW, HTTP может успешно применяться на стороне клиента для просмотра данных через WEB -серверы, выступающие в этом случае как серверы промежуточного слоя. В последнее время протокол HTTP часто используют как транспортный для передачи структур XML.

XML/SOAP – протокол работы с так называемыми WEB -сервисами.

Выполняется поверх протокола HTTP. В последнее время является весьма популярным [97, 98] ввиду относительной простоты и возможности расширения в рамках принятых правил XML и RDF (Resource Description Framework ) [99]. Активно поддерживается ведущими разработчиками программного обеспечения. Однако ввиду новизны практически отсутствует опыт эксплуатации систем на основе этой технологии. Тем не менее, существует множество проектов, в том числе и в России, построения РИС на основе этих технологий (см., например, [100] - [103]).

XML/SOAP/SRW – технология, аккумулирующая лучшие свойства как Z39.50, так и XML/SOAP. Фактически представляет собой SOAP для упрощенных структур Z39.50, представленных в виде структур XML. Позиционируется сегодня как следующая генерация технологий Z39.50 (ZING – Z39.50 – International: Next Generation). Находится в стадии активного обсуждения [104, 105].

Тем не менее, существуют проекты, основанные на этой технологии (см. Приложение A.4.4).

FTP – протокол передачи файлов (см. [106]). В РИС чаще всего применяется для доступа к первичным ресурсам. Не предназначен для передачи структурированной информации.

DNS – протокол, на котором основана распределенная система именования компьютеров в Интернет (см, например, [107]). Технология обеспечивает распределенность, гетерогенность и виртуальность данных. Иерархическая схема данных DNS имеет довольно жесткую структуру и не может быть использована для построения РИС общего назначения.

LDAP – протокол доступа к данным, организованным в виде иерархических каталогов (см, например, [108]). Обеспечивает распределенность, гетерогенность и виртуальность данных. Модель данных и модель поиска ограничены. Применяется для доступа к данным в соответствии с простыми схемами, чаще всего для организации в РИС единого домена аутентификации пользователей. Тем не менее, существуют проекты РИС, основанные на технологиях LDAP (см., например, [88, 89, 109, 110]).

На сегодняшний день обозначились несколько основных группы технологий построения распределенных систем.NET – технология Microsoft для платформы Windows 2000. Технология включает поддержку специальной среды (CLR) для исполнения приложений, написанных на разных языках, среду ASP.NET для динамических Web-приложений. Для доступа к базам данных.NET использует технологии MS ADO и OLE DB.

J2EE (Java 2 Enterprise Edition, 1999) – технология Sun Microsystems.

J2EE (см., например, [92]) включает описание компонентной модели Enterprise JavaBeans, описания правил для WEB -приложений Java Servlets, Java Server Pages (JSP ) и правила доступа к базам данных JDBC. Технология J2EE активно используется при построении серверов приложений.

CORBA – проект OMG (Object Management Group) по стандартизации набора спецификаций для интеграции приложений, созданных в различной среде и выполняющихся в различных гетерогенных программно-аппаратных средах. На сегодняшний день (CORBA 3, [92]) проект содержит наиболее полный набор спецификаций для распределенных систем.

В каждой из перечисленных групп предусматривается взаимодействие с базами данных. К сожалению, спецификации этого взаимодействия ограничены спецификациями MS ADO, ODBC или JDBC, стандартизация взаимодействия сводится к стандартизации языка SQL и метаданных для реляционных систем.

Как видно даже из этого беглого обзора, применяя перечисленные технологии отдельно или в комплексе, несомненно, можно организовать сетевую работу с базами данных. Более того, для каждой конкретной СУБД можно подобрать технологию, обеспечивающую высокий уровень эффективности и функциональности. Однако ни одна из упомянутых технологий, кроме Z39.50, не обеспечивает универсальных способов работы с базами данных – необходимого уровня абстрагирования от конкретных систем и платформ при сохранении высокой степени функциональности и предоставления пользователю единого интерфейса доступа к различным СУБД. В пользу технологии Z39.50 для доступа к базам данных говорит тот факт, что обсуждается возможность включения Z39.50 как в.NET и в J2EE, так и в CORBA [98, 111–116]. Интерес к технологиям Z39.50 существует и в GRID-системах на уровне доступа к информационным ресурсам GRID-IR (см., например, [117–120]).

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

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

2.2.1 История протокола Z39. Первая версия протокола, получившего наименование Z39.50, была подготовлена Комитетом по Национальным Информационным Стандартам США – NISO (National Information Standards Organization) и утверждена в 1988 г. как стандарт Z39.50-1988 (см. [121]). Его действие распространялось на работу только с библиографической информацией. Именно эта версия протокола дала толчок к появлению известной службы Интернет WAIS.

В 1989 г. было организовано Агентство поддержки протокола Z39. (Maintenance Agency Z39.50 ) под административным управлением лаборатории библиотеки Конгресса США, а в 1990 г. сформирована Группа исполнителей Z39.50 – ZIG (Z39.50 Implementors Group). Ее членами стали производители, продавцы, консультанты, распространители разнородных видов информации (в т.ч. библиографической, текстовой, графической, финансовой, общественного назначения, химической и новостей), университетские сотрудники и т.д. Членство в Группе ZIG было открыто для всех заинтересованных сторон. Разработанная указанными организациями версия стандарта 1992 г. (Z39.50-1992 ) заменила собой стандарт 1988 г.

В ходе подготовки стандарта Z39.50-1992 было сделано большое количество предложений для поддержки широкого диапазона возможностей информационного поиска. Однако реализация указанных предложений существенно задерживалась. Поэтому в качестве первоочередной задачи исполнителей была определена переработка версии 1988 г. для обеспечения его битовой совместимости с международными стандартами ISOSR – Search and Retrieve). (Z39.50-1992 заменил Z39.50-1988 и SR).

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

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

Версия 1992 года стала известной под названием ”версия 2”, а версия 1995 года – как ”версия 3”. Но, хотя эти обозначения версий имеют определенное протокольное значение, они никак не связаны с версиями стандарта. Z39.50-1992 соответствует версии 2 протокола; Z39.50- соответствует версиям 2 и 3 протокола.

Хотя стандарт Z39.50-1992 заменил Z39.50-1988 (а стандарт Z39.50устарел), отношение Z39.50-1995 к Z39.50-1992 совершенно иное:

Z39.50-1995 шире версии 1992 года и совместим с нею. В документе о Z39.50-1995 можно найти полную информацию о версии 2 и создать на ее основе систему, совместимую с Z39.50-1992.

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

В 1998 году протокол Z39.50 был утвержден как стандарт ISO- [124].

Агентство поддержки Z39.50-1995 является постоянно действующим органом, производящим сопровождение эксплуатации протокола и его и развитие. Сетевой адрес Агентства: http://lcweb.loc.gov/z3950/agency.

2.2.2 Область действия протокола Z39. Протокол Z39.50 определяет порядок взаимодействия клиента и сервера, процедуры поиска и извлечения информации из баз данных, и форматы представления этой информации.

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

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

2.2.3 Модель взаимодействия Протокол Z39.50 не определяет транспортный уровень сетевого взаимодействия. Поэтому возможны реализации Z39.50 поверх любых транспортных протоколов (TCP/IP, SPX/IPX, OSI и т.д.).

Наибольшее значение имеют реализации Z39.50 поверх TCP/IP, так как именно этот транспортный протокол принят в Интернет.

По умолчанию для запросов Z39.50 предусматривается TCP порт 210.

Допускается использование других номеров портов, как правило, непривилегированных. Поэтому обращение к серверу Z39.50 должно содержать кроме IP -адреса или DNS -имени сервера дополнительно его номер TCP порта.

Протокол Z39.50 описывает сетевое взаимодействие субъектов в архитектуре клиент-сервер. Однако это взаимодействие несколько отличается от классической архитектуры клиент-сервер, в которой инициатором любого запроса может быть только клиент, а серверу всегда отводится пассивная роль ожидающего и отвечающего. Как будет видно ниже, в Z39.50 это не всегда так. Может быть поэтому разработчики протокола изменили терминологию, заменив термины клиент и сервер на термины origin и target соответственно. За редким исключением понятия клиент – origin и сервер – target совпадают.

В стандарте описаны четыре сервисных примитива, в терминах которых формулируются правила сервисных процедур Z39.50 :

Request (запрос) – примитив, используемый origin для инициализации его сервис-провайдером соответствующей сервисной процедуры Indication (индикация) – примитив, используемый target для передачи от сервис-провайдера к сервис-потребителю Response (ответ) – примитив, используемый target для инициализации его сервис-провайдером ответа Conrmation (уведомление) – примитив, используемый origin для передачи от сервис-провайдера к сервис-потребителю.

Последовательность сервисной процедуры может быть проиллюстрирована на примере запроса Search, инициатором которого является origin:

1. Origin сервис-потребитель формирует для своего сервис-провайдера запрос SearchRequest 2. От origin к target по сети пересылается APDU SearchRequest 3. Target сервис-провайдер указывает своему сервис-потребителю о поступлении SearchRequest 4. Target сервис-потребитель формирует SearchResponse для своего сервис-провайдера 5. От target к origin пересылается APDU SearchResponse 6. Origin сервис-провайдер уведомляет своего сервис-потребителя об APDU SearchResponse Обычно так выглядят все сервисные протокольные процедуры (Init, Search, Present, Delete, Resource-report, Sort, Scan, Extended-services).

Однако есть и такие, в которых роли target и origin меняются местами. Инициатором процедур (Access-control и Resource-control ) является target!

Как видно из описания протокольных процедур, по сети от origin к target и наоборот передаются специальные пакеты – APDU (Application Protocol Data Unit) для обмена информацией между субъектами. Каждой протокольной процедуре соответствуют свои APDU, структура которых жестко регламентирована.

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

Здесь вступает в силу стандартизация объектов.

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

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

Общение origin с target вне сеанса возможно только при помощи APDU initRequest, предназначенного для установления сеанса.

Для закрытия сеанса по инициативе origin он должен послать APDU close и получить в ответ от target такой же APDU.

Следует особо отметить, что инициатором APDU close может быть не только origin, но и target. Эта особенность отличает APDU close от других. Причина этого проста: может возникнуть ситуация, когда сервер вынужден закрыть сеанс или все сеансы для корректной работы, например, при его выключении администратором.

2.2.5 Дополнительные функции Дополнительные сервисы Z39.50 не являются обязательными. Настройка на поддержку этих сервисов в сеансе связи происходит при инициализации сеанса через параметр APDU options.

Для представления об актуальности различных сервисов в Табл. 2.1 ( апреля 2001 года, 26 марта 2002 года, 2 марта 2003 года и 31 марта года) приводится информация, полученная в соответствующее время с WEB -сервера компании IndexData [125], которая показывает статистику поддержки различных сервисов в списке тестируемых серверов Z39.50.

Недостатки Z39.50 как технологии построения 2. Содержание описания стандарта Z39.50 [1] позволяет утверждать, что протокол Z39.50 изначально не предназначался как базовый протокол распределенных информационных систем. Несмотря на подробное описание регламента взаимодействия с базами данных в модели клиентсервер, в стандарте Z39.50 не описаны некоторые детали, необходимые concurrentOperations 79 (26%) 108 (36%) 138 (32%) 255 (41%) Таблица 2.1: Распространенность сервисов Z39. для построения распределенных информационных систем. К таким деталям можно отнести следующие [19]:

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

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

• Отсутствие описания механизмов контроля маршрутизации запросов также является следствием первого недостатка. Этот контроль необходим в случаях возникновения ситуации множественной переадресации и петель переадресации.

• Отсутствие описания распределенного учета ресурсов приводит к невозможности построения в рамках стандартных средств распределенной базы данных IR-Explain-1. Дело в том, что в соответствии с идеологией Z39.50 каждый сервер Z39.50 в РИС может поддерживать собственную базу данных IR-Explain-1, в которой содержится исчерпывающая информация об его собственных ресурсах. Однако эти локальные базы данных, имеющие к тому же все одно и то же имя, ввиду своей жесткой предопределенной структуры не могут быть интегрированы в одну логическую базу данных, содержащую описание всего ресурса РИС в целом. Это ограничение, несомненно, отрицательно сказывается на возможности реализации службы обеспечения учета интегрированных ресурсов РИС.

• Отсутствие описания схем аутентификации пользователей в многосерверной среде.

• Отсутствие описания технологии учета статистической информации о работе РИС.

• Отсутствие описания механизма выполнения распределенных транзакций затрудняет выполнение административных задач управления распределенными данными. Однако это совершенно не сказывается на пользовательских задачах, которые, как было сказано выше, являются основными задачами РИС.

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

CIP – попытка модернизации Z39.50 для РИС 2. Сознавая привлекательность технологий Z39.50 для построения РИС, с одной стороны, и отсутствие в Z39.50 необходимых компонент для функционирования РИС, с другой стороны, CEOS (Committee on Earth Observation Satellites) [126] разработал специальный протокол для построения своей распределенной информационной системы – CIP (Catalogue Interoperability Protocol ) [83, 87] как модернизированный протокол Z39.50. Система предназначена для доступа к данным по дистанционному зондированию Земли. CIP наследует все свойства Z39.50, оба протокола могут использоваться совместно. Следует заметить, что членами CEOS являются:

The European Space Agency (ESA) – http://www.esrin.esa.it National Aeronauvtic and Space Administration (NASA) – http://www.nasa.gov/home/index.html Deutschen Zentrum fr Luft- und Raumfahrt (DLR) – http://www.dlr.de National Space Development Agency of Japan (NASDA) – http://www.nasda.go.jp Canada Centre for Remote Sensing (CCRS) – http://www.ccrs.nrcan.gc.ca British National Space Centre (BNSC) – http://www.bnsc.gov.uk Center for Earth Observation (CEO) – http://www.ceo.org Описание протокола и профиля CIP составляет довольно увесистый том и здесь, конечно, рассматриваться не будет. Следует лишь обратить внимание на специфические особенности CIP :

• CIP ориентирован на обработку распределенной информации, хранящейся на различных серверах и организованной в иерархические коллекции (базы данных) (см. Рис. 1.3).

• Для обеспечения обработки распределенных данных в CIP переопределены многие объекты в классах Z39.50, в том числе и объекты в классе APDU. Это существенно отличает расширения CIP от обычных расширений Z39.50.

Таблица 2.2: Объекты Z39.50, переопределенные в CIP • CIP включает дополнительные спецификации для поиска и извлечения информации, для поддержки Explain, расширенного сервиса, исполнения заказа.

• В CIP определены спецификации базы данных пользователей (IRUser-1 ), которая используется в том числе и для аутентификации.

Протокол CIP используется многими информационными системами, связанными космическим мониторингом, например, системами INFEO (Information on Earth Observation) [127] (см. также Earth Observation Portal [128]), DIMS (Data Information and Management System) [129] и др (см. [130]). Следует отметить, что соответствующие организации в России также пытаются включиться в процесс создания глобальных библиотек данных по космическому мониторингу. В качестве примера можно указать Институт космических исследований РАН (ИКИ РАН) [131].

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

Технологии Z39.50 и требования к РИС 2. Распределенную информационную систему на основе протокола Z39.50 можно представить как совокупность серверов Z39.50, распределяющих между собой обработку запросов клиентов. Схематично такая система изображена на Рис. 2.1, на котором под базами данных (БД) следует понимать клиентские части сетевых СУБД.

Ниже рассмотрены свойства подобных РИС с точки зрения удовлетворения требованиям, обсуждавшимся в разделе 1.3.

2.5.1 Открытость Z39.50 создавался как открытый стандарт ANSI/NISO. В 1998 году он был принят как стандарт международный ISO-23950. Стандарт регламентирует сетевое взаимодействие с базами данных в соответствии с моделью клиент-сервер. Поэтому Z39.50 полностью удовлетворяет требованию открытости (см. раздел 1.3.12).

Рис. 2.1: Модель РИС на основе протокола Z39. 2.5.2 Интероперабельность Интероперабельность (см. раздел 1.3.11) Z39.50 основана на глобальной стандартизации всех определенных в нем объектов. Для однозначной идентификации всех объектов принята система присвоения каждому из них числового идентификатора. Справедливости ради следует отметить, что эта практика присуща не только Z39.50, а всем протоколам, описанных в терминах ASN.1 (см. раздел 2.5.7). В этом смысле сам Z39. является объектом более общего класса. Иерархия классов следующая iso (1) – member_body (2) – US (840) – ANSI-Z39.50 (10003) что дает для Z39.50 идентификатор OID (object identier ) 1.2.840.10003.

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

Классы объектов, подлежащих стандартизации в Z39.50, приведены в Табл. 2.3.

Следует заметить, что последние два класса объектов были определены после утверждения стандарта в 1995 году и не вошли в официальное

Z.2

Abstract

syntax denition for APDUs

издание стандарта версии 3.

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

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

Существует несколько возможностей расширения возможностей базового набора средств Z39.50.

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

Дело в том, что Z39.50, как и многие другие протоколы (LDAP, SNMP и др.) определен в терминах ASN.1 [132] и для однозначной интерпретации объектов использует рубрикатор объектов ISO. Z39.50 имеет в этом рубрикаторе свою ветвь, определяемую кодом iso (1) – member_body (2) – US (840) – ANSI-Z39.50 (10003) что дает для Z39.50 OID:1.2.840.10003. В дальнейшем этот OID будет обозначаться как (Z). Все объекты, подлежащие стандартизации, в Z39.50 получают в своем OID префикс Z. Стандартом определены классы объектов, приведенные в Табл. 2.3.

Внутри каждого класса объектам присваивается идентификатор, в префиксе которого содержится OID класса. В частности, в классе Z. (см. Табл. 2.3) RecordSyntaxDenitions содержится объект SUTRS, OID которого Z.5.101. Полный список актуальных OID всегда можно найти в глобальном реестре объектов:

http://lcweb.loc.gov/z3950/agency/defns/oids.html Все вышесказанное касалось только объектов, определенных глобально.

Благодаря этим определениям любое программное обеспечение Z39. любого производителя может однозначно интерпретировать и обработать тот или иной объект. Кроме этого стандарт Z39.50 допускает существование локально определенных объектов, область действия которых ограничена объекта после префикса класса, кода 1000 и идентификатора разработчика. Глобальный реестр разработчиков программного обеспечения Z39.50 находится по адресу:

http://lcweb.loc.gov/z3950/agency/register/entries.html Следуя этому правилу, в любом из указанных выше классов можно определить новый объект и присвоить ему локальный OID. Наиболее экзотическими являются новые объекты в классах

Z.2 abstract syntax denition for APDUs

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

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

1. OID локального объекта вместе с описанием объекта публикуется в глобальном реестре объектов. Это самый правильный способ, поскольку не только позволяет всем разработчикам получить необходимую информацию через WWW, но и при некоторых обстоятельствах в конце концов приводит к стандартизации объекта и выделении для него глобального OID.

2. Описание локального объекта помещается в специальную базу данных IR-Explain-1 в соответствующей категории на серверах, которые эти объекты поддерживают. Этот способ дополняет первый.

К сожалению, далеко не все серверы Z39.50 поддерживают сервис Explain (см. раздел 2.5.9).

Использование специальных полей в APDU Согласно Z39.50, при взаимодействии клиент и сервер обмениваются прикладными пакетами (APDU ), структура которых регламентирована в классе Z.2, содержащем 23 глобально стандартизированных объекта.

В структуре всех типов APDU стандартом (v.3) предусмотрено необязательное поле OtherInfo, представляемое в терминах ASN.1 как OtherInformation ::= [201] IMPLICIT SEQUENCE OF SEQUENCE{ characterInfo [2] IMPLICIT InternationalString, externallyDefinedInfo [4] IMPLICIT EXTERNAL, InfoCategory ::= SEQUENCE{ categoryTypeId [1] IMPLICIT OBJECT IDENTIFIER OPTIONAL, categoryValue [2] IMPLICIT INTEGER} Это поле содержит последовательность структур, идентифицируемых как правило по OID, в том числе и локальным. Информационное наполнение структур определяется структурой соответствующих объектов и в случае локально определенных объектов может содержать контент, требуемый для функционирования РИС.

Использование внешних определений Для передачи структурированной информации, в том числе через поле OtherInfo, стандартом Z39.50, вернее ASN.1, предусмотрено наличие внешнеопределенных типов данных EXTERNAL. Объекты типа EXTERNAL как правило идентифицируются по OID, в том числе и локально определенным, и формально могут принадлежать любому классу.

Использование данных типа EXTERNAL в структурах OtherInfo позволяет реализовать механизм передачи нестандартных структурированных данных любой сложности в стандартных APDU, не прибегая к переопределению последних.

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

Поэтому и принято ее называть набор атрибутов (attributeSet).

Получив от origin запрос в виде термов и поисковых атрибутов, target, а точнее, database provider, конечно же, свяжет его с реальной базой данных и конвертирует его в реальный синтаксис, но это процедура для конечного пользователя останется незаметной. При таком подходе к процедуре поиска все базы данных становятся для пользователя одинаковыми, если поддерживают один и тот же набор поисковых атрибутов.

Наборы поисковых атрибутов составляют класс объектов Z39. (Z.3), подлежащих стандартизации. В классе Z.3 в настоящий момент стандартизованы наборы, представленные в Табл. 2.4.

Для поиска библиографической информации используется набор атрибутов bib-1. Некоторые наборы атрибутов (gils, geo-1 ) включают в себя набор bib-1, поэтому этот набор является основным.

В Z39.50 для всех серверов обязательна поддержка запросов type- (RPN – Reverse Polish Notation – обратная польская нотация). Поддержка других типов запросов серверами Z39.50 является факультативной.

Запрос RPN можно представить в виде дерева, в узлах которого находятся связывающие операторы (AND, OR, AND-NOT). Листьями этого дерева являются блоки ”атрибуты+терм” (APT ).

Z.3.1 bib-1 Библиографическая информация Z.3.2 exp- Z.3.4 ccl- Z.3.5 gils Z.3.6 stas Научно-техническая информация Z.3.7 collections-1 Навигация по электронным коллекциям Z.3.8 cimi-1 Информация по музейным коллекциям Z.3.9 geo-1 Пространственные метаданные Z.3.10 ZBIG Биологическая информация Z.3.12 xd- Таблица 2.4: Стандартные наборы поисковых атрибутов В Z39.50 запрос RPN не является строкой символов, а является структурой, которую можно изобразить в виде строки, но только для наглядности. Запрос RPN определен в виде структуры ASN.1, схематично представленной на Рис. 2.2.

Дополнительно к запросам RPN в Z39.50 поддерживаются и другие типы запросов:

в частности, запросы SQL (см. раздел 3.4) и CQL (см. раздел A.4.4), определенные через EXTERNAL.

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

2.5.5 Абстрактная модель данных Модель данных Z39.50 основана на абстрактных иерархических схемах, которые формулируются в терминах меток (тегов) из стандартизованных наборов (tagset). Схема представляет собой правило, по которому формируется абстрактная структура записи (abstract record structure), являющаяся в Z39.50 основой обработки данных при извлечение информации.

Идеология максимального абстрагирования от структур реальных баз данных приводит к весьма изощренной схеме извлечения данных, описанной в стандарте Z39.50 : записи из результирующих наборов отображаются в записи абстрактной базы данных через схему, определяющую абстрактную структуру записи в виде дерева элементов, специфицируемых метками (tag) из стандартных наборов (tagSet); затребованные элементы выбираются в нужной альтернативной форме (variant) из абстрактной записи и отображаются в экспортируемую структуру, определяемую форматом внешнего представления (recordSyntax ). Все объекты описанной процедуры (schema, tagSet, elementSpec, variantSet, recordSyntax ) определены в соответствующих классах с присвоением OID. Схематично модель извлечения записей представлена на Рис. 2.3.

Модель данных Z39.50 полностью соответствует требованию работы РИС в соответствии с абстрактной моделью данных (см. раздел 1.3.4).

2.5.6 Виртуальные данные Реализация в Z39.50 абстрактной модели поиска (см. раздел 2.5.4) и абстрактной модели данных (см. раздел 2.5.5) позволяет удовлетворить требованию виртуальности данных (см. раздел 1.3.3).

В ситуации, когда для пользователя все базы данных одинаковы, т.е. если • поддерживаются одинаковые поисковые атрибуты, • записи отображаются на одну схему данных, создается возможность для логического объединения этих баз данных [133, 134]. Пользователю нет необходимости знать реальные имена баз данных, достаточно знать некие условные имена, скрывающие группы однотипных баз данных. Указывая такое имя в качестве имени базы данных в запросе на поиск, пользователь осуществит его во всей группе, а всю ”кухню” одновременного поиска обеспечит сервер.

Конечно, пользователь нечто подобное может проделать и сам, т.к. в запросе на поиск (searchRequest) серверу Z39.50 передается не имя базы данных, а список имен. Согласно протоколу сервер должен выполнить поиск во всех указанных базах данных. Однако первый вариант кажется более привлекательным, т.к. в этом случае у пользователя отпадает необходимость запоминать длинный список имен баз данных и условия их объединения в одном запросе.

Что касается извлечения данных, то здесь проблемы объединения баз данных не существует. Это определяется тем, что данные извлекаются не из баз данных, а из промежуточных наборов, созданных сервером в момент осуществления поиска. Поэтому к моменту запроса на извлечение данных эти данные, извлеченные из разных баз в момент поиска, уже будут объединены в одном промежуточном наборе.

Наконец, процедура просмотра поисковых термов (scan) тоже может выполняться над группой баз данных. Все необходимое при этом, т.е.

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

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