Технологии
В.А. Лекае, В.П. Челноков СИСТЕМА ПОСТОЯННЫХ URL
В статье рассматривается реализация системы постоянных URL под названием PURLRU, работающей в научной библиотеке РГГУ. Эта система сделана вместо свободно распространяемой американской системы PURL, оказавшейся у нас неработоспособной. Предложена и реализована простая схема объединения всех библиотечных клиентов под управлением одного PROXY-сервера. Эта система называется «мобильный библиотечный куст».
Образование такого куста крайне важно для повышения качества обслуживания абонентов путем расширения их возможностей за счет унификации доступа к информационным ресурсам библиотеки.
Ключевые слова: система PURL, URL, постоянный URL, локальный URL, свободно распространяемое программное обеспечение, мобильный библиотечный куст, система Handle, DOI.
Введение
В США была предложена концепция поддержки постоянных URL (persistent URL, PURL), ссылающихся на реальные библиотечные объекты (например, тексты книг). Этот механизм поддерживается OCLC (некоммерческий компьютерный библиотечный сервис). Общественной целью этой организации является расширение доступа к мировой информации и сокращение расходов на информацию. Более 72 000 библиотек в 170 странах и территориях используют услуги OCLC для поиска, приобретения, каталогизации, заимствования и сохранения библиотечных материалов. OCLC предоставляет доступ к библиографической, аннотационной и полнотекстовой информации.
© Лекае В.А., Челноков В.П., 2013
Сущность механизма PURL заключается в следующем: для каждого объекта, нуждающегося в постоянной URL-ссылке, создается такая ссылка и регистрируется на специальном сервере, хранящем эти постоянные ссылки. Там же хранится и соответствующая локальная URL-ссылка, реально указывающая на этот объект; эта ссылка может не совпадать с постоянной ссылкой. При поступлении WEB-обращения с постоянной ссылкой к этому серверу происходит следующее: эта постоянная ссылка заменяется на локальную. Тем самым обеспечивается перенаправление запроса на реальный объект.
Обеспечить постоянство подобных ссылок могут, например, национальные библиотеки, поскольку они имеют стабильное финансирование и государственную поддержку, или крупные организации, имеющие в своем составе много филиалов и/или институтов, в частности РГГУ.
В рамках действующего проекта OCLC был разработан пакет программного обеспечения, его реализующий. Этот пакет доступен для скачивания на сайте http://purl.org. Он предназначен для работы в операционной системе LINUX.
Однако этот пакет оказался не работающим у нас (по крайней мере, Option A этого пакета) и слабодокументируемым в отношении выбора инструментальной операционной системы (вида Linux, предпочтения между сервером или настольной машины), а также в отношении самого процесса инсталляции.
Поэтому с другими американскими коллегами было принято решение написать собственный PURLRU на языке PHP. Программа оказалась удивительно простой и предлагается нами для использования в рамках свободно распространяемого обеспечения. Она работоспособна как в среде UNIX, так и в Windows.
Программа PURLRU
Программа PURLRU состоит из двух частей: программы замены постоянного URL на локальный и программы настройки подобных замен. Программа настройки подготавливает основную таблицу замен PURL. Таблица PURL хранится как реляционная таблица в базе данных PURL, работающей на сервере MySQL. Подчеркнем, что настраивать PURLRU может только администратор.
Первое поле таблицы PURL с именем CONSTANT содержит постоянный URL, а второе поле LOCAL - реальный, локальный URL. В дополнительном поле DATE хранится дата последнего изменения строки этой таблицы.
Программа PURLRU обрабатывает каждый поступающий WEB-запрос клиента на обслуживание. Она проверяет, указан ли в таблице PURL в качестве постоянного URL поступившего запроса. Если это так, производится его замена на URL, взятый из поля LOCAL; если же это не так, используется поступивший URL. Затем производится переадресация к объекту по полученному таким образом URL.
Программа настройки таблицы замен URL содержит основные опции для создания строки подмены, ее изменения или удаления. Эта технология может эффективно использоваться для создания мобильного библиотечного куста1.
Действительно, пусть мы имеем набор серверов, содержащих данные одной библиотеки. Поставим в качестве корня этой иерархии PROXY-сервер, который будет транслировать для всех приходящих WEB-запросов их постоянные URL в реальные URL.
Пусть все библиотечные серверы объединены в локальную сеть (мобильный библиотечный куст). Пусть также корнем этого куста является подобный PROXY-сервер, на котором работает программа PURL. Взаимодействие с внешним миром идет через этот сервер (в частности, он принимает все приходящие в данную локальную библиотечную сеть Web-запросы).
Пусть интернет-адрес произвольного объекта выглядит следующим образом: «http://<nYTb-K-PROXY>/<nyTb>». Здесь ПУТЬ-К-PROXY это часть URL, указывающая на путь именно к PROXY-серверу; а ПУТЬ - оставшаяся часть URL, уточняющая размещение объекта в рамках мобильного библиотечного куста. Предположим также, что этот интернет-адрес первоначально и является реальным интернет-адресом искомого объекта. Тогда в таблице PURL нет никакой информации о перенаправлении и при поступлении запроса по такому интернет-адресу производится переадресация к объекту именно с этим поступившим адресом.
Далее допустим, что наш мобильный куст сменил домен: путь к PROXY-серверу и стал равным nyTb-K-PROXY_1. В этом случае интернет-адрес произвольного объекта данного мобильного куста стал равным: «http:// < nyTb-K-PROXY_1>/<nyTb>». При этом мы полагаем, что ПУТЬ к объекту остается прежним. Действительно, намного чаще будет меняться домен адреса, а не размещение объекта в кусте.
Тогда, чтобы старый интернет-адрес работал, в таблицу PURL должна быть записана следующая строка: поле CONSTANT: ^yTb-K-PROXY^ поле LOCAL: ^yTb-K-PROXY^. В этом случае при поступлении запроса на старый адрес: <ПУТЬ-
K-PROXY> и при сравнении его с записями в поле CONSTANT таблицы PURL такая запись обнаружится в указанном поле упомянутой таблицы и программа заменит старый адрес прокси-сервера в запросе на значение, взятое из поля LOCAL, т. е. на новый адрес прокси-сервера, т. е. на <ПУТЬ-К-PROXY_1>. В результате адрес текста запроса преобразуется в реально существующий на данный момент адрес объекта и программа переадресует к искомому объекту с актуальным адресом, т. е. к объекту с реальным адресом http:// «< ПУТЬ-К-PROXY_1>/<ПУТЬ>».
Приведем поясняющий пример. Пусть постоянный интернет-адрес объекта такой: 'http://localhost:8080/net/partialexample/ioo/ bar/baz', а интернет-адрес реального объекта стал равным 'http:// example.com/partialtest/ioo/bar/baz'. Легко видеть, что в обоих адресах ПУТЬ равен 'foo/bar/baz' (указание ПУТЕЙ-К-PROXY в обоих адресах выделено курсивом).
Нетрудно видеть, что при поступлении постоянного интернет-адреса должна производиться только смена ПУТЕЙ-К-PROXY для получения адреса локального объекта. Значит, соответствующая строка таблицы PURL должна иметь вид: CONSTANT: 'http:// localhost:8080/net/partialexample/'; поле LOCAL: 'http://example. com/partialtest/'.
Полагаем также, что если в интернет-запросе содержатся параметры, то они не меняются. Тогда вызов http://localhost:8080/ net/partialexample/foo?bar=baz' будет преобразован в следующий: 'http://example.com/partialtest/foo?bar=baz' (напоминаем, что изменяется только ПУТЬ-К-PROXY-серверу - этот путь выделен курсивом в приведенных выше адресах).
В программе PURL также могут быть реализованы и реализуются в настоящее время расширенные виды перенаправления: частичный (Partial), частичный с добавлением расширения (Par-tial-append-extension), частичный с игнорированием расширения (Partial-ignore-extension) и частичный с заменой расширения (Partial-replace-extension). Приведем краткое, неформальное их описание, используя для этого примеры.
Частичное перенаправление было описано выше. Суть частичного метода с добавлением расширения заключается в следующем: добавляется расширение в локальный адрес. Пусть строка таблицы PURL имеет вид: CONSTANT: http://net/partialappendextension/; поле LOCAL: http://example.com/partialappendtest.
Пусть также постоянный интернет-адрес есть http://localhost: 8080/net/partialappendextension/ioo^/bar/bam?id=fizzle'. Тогда этот адрес преобразуется в 'http://example.com/partialappendtest/bar/bam.
foo?id= fizzle'. Нетрудно видеть, что первый компонент ПУТИ 'foo' удаляется из адреса и вставляется в качестве расширения файла '.foo'.
Суть частичного метода с игнорированием расширения заключается в том, что при проведении операции замены удаляется расширение имени файла из локального адреса. Например, постоянный интернет-адрес 'http://localhost:8080/net/partialignoreextension/foo. html' будет преобразован в 'http://example.com/partialignoretest/foo'.
Частичный метод с заменой расширения является комбинацией двух последних методов. Использование этих методов расширяет гибкость при изменении интернет-адресов.
Этот механизм позволяет правильно конструировать мобильный библиотечный куст. При этом создатели куста обеспечивают пользователей возможностью изменять провайдера, не изменяя URL.
Существует и другая платная система Handle, решающая аналогичные задачи обеспечения постоянства URL-объектов. Возможности использования данной системы рассматриваются ниже.
Система Handle используется для уникальной идентификации информационных объектов (их содержания) в цифровой среде. При этом само содержание не обязательно должно иметь цифровую форму. Каждый объект идентифицируется с помощью DOl -digital object identifier (цифровой идентификатор).
Структурно DOI является строкой из букв и цифр, образующих два компонента DOI - префикс (Publisher ID) и суффикс (Item ID). Эти компоненты разделяются знаком «прямой слэш» (/). Ограничений на длину DOI нет, однако рекомендации советуют ограничиваться 128 символами.
Префиксы выдаются одним из официальных агентств DOI или Международным фондом DOI. Суффиксы DOI для информационных объектов формируют сами издатели. Приведем пример DOI:
DOI:10.1126/science.1169616 - статья из журнала "Science".
К сожалению, для получения суффикса DOI нужно его оплатить. А описываемая в этой статье система бесплатна. Эту систему можно также использовать и для создания кластеров библиотек, архивов и пр., обеспечивающих пользователей нецифровой информацией.
Поэтому излагаемая в данной работе разработанная технология может быть применена и весьма перспективна для России в части решения важных задач аналогичного плана для хранилищ нецифровых информационных объектов, например хранилищ оригиналов документов архивного плана, кинофотодокументов и пр.,
поскольку в отличие от системы Handle префикс можно выдавать бесплатно, а суффиксы назначаются самой библиотекой.
Система PURLRU была отлажена и эффективно используется в библиотеке РГГУ.
Выводы
1. В работе рассмотрены широко применяемые в мире технологии формирования кластеров из библиотек, архивов и других информационных систем, обеспечивающих интеграцию сведений о хранящихся в них информационных ресурсах цифрового и нецифрового характера. Показана эффективность их использования, поскольку такой подход существенным образом повышает качество обслуживания абонентов за счет формирования метаданных об адресах хранения их информационных ресурсов и, как следствие, упрощает доступ к ним.
2. Показано, что разработана аналогичная технология и для России за счет создания простой программной системы, обеспечивающей ее реализацию.
3. Отмечено, что разработка позволяет реализовывать создание кластеров держателей информации цифрового и нецифрового плана, а также обеспечивает возможность ее использования на компьютерах с разнообразными операционными системами.
Примечания
Cm.: Jha Sh, Merzky A., Fox G. Programming Abstractions for Clouds // CCA-08: Cloud Computing and Its Applications (Chicago, 22-23 October, 2008). 6 p. URL: http://grids.ucs.indiana.edu/ptliupages/publications/cca08/pdf.