Увеличить
В работе рассматривается общая архитектура новой версии системы ИСИР, опирающейся на открытые стандарты W3C: Semantic Web [SW], XML[XML] технологии, и на применение opensource решений. Архитектура позволяет разрабатывать распределённые объектно-ориентированные информационные системы - цифровые библиотеки, информационные и корпоративные порталы, сайты на базе различных типов хранилищ информации, таких как объектные и реляционные базы данных, LDAP-каталоги. Система параметризуется описанием объектной схемы данных конкретной предметной области и легко адаптируется к её изменениям. Для описания схемы используется W3C стандарт на описание схем Интернет ресурсов - RDFS. Архитектура имеет многоуровневую модульную организацию, каждый уровень имеет собственные цели и абстракции. Фундамент решения - ядро ИСИР - унифицирует механизмы работы с хранимыми объектными данными, предоставляет ряд услуг по управлению этими данными, например, разграничение прав доступа, журнализация изменений. На базе ядра строятся более высокоуровневые сервисы такие, как RDF/XML-обмен данными, репликация информации между репозиториями, атрибутно - полнотекстовая индексация данных и др. Имеются средства для простой и эффективной разработки пользовательских Web-интерфейсов. Средства публикации информации и построения отчётов применяют механизмы XSLT и поддерживают широкий спектр целевых форматов. Служба управления потоками работ по редактированию ресурсов репозиториев следует стандартам WfMC - канонической модели и языку спецификации потоков работ XPDL. Служба управления содержанием Web-сайта обеспечивает мульти - иерархическую каталогизацию слабоструктурированной информации, отличающейся нерегулярностью взаимосвязи ее элементов.
Общая архитектура
Службы поддержки репозиториев
Сервисы ядра
Высокоуровневые сервисы
Использование XML-технологий
Web-публикация и XSLT
Управление потоками работ
Управления слабоструктурированными материалами
Атрибутно-полнотекстовый поиск.
Заключение
Литература
Новая версия системы ИСИР [ISIR, ELBIB-3-2003] ориентируется на поддержку реализации ключевых механизмов цифровых библиотек и корпоративных порталов. Корпоративный портал выступает в роли посредника, направляющего обращения пользователей к совокупности сервисов, релевантных данной тематический области, используя открытые прикладные протоколы, например, HTTP, SOAP[SOAP], Z39.50[Z39.50], SDLIP[SDLIP], LDAP[LDAP] и д.р. К основным задачам портала относится обеспечение операций обнаружения ресурса, локализации его местоположения, запроса и доставки ресурса. Реализация новой версии ИСИР исходит из общей многоуровневой архитектуры [MIA]. Цель выделения уровней, в которые в свою очередь содержат компоненты и модули, состоит в том, чтобы обеспечить локальное упрощение при поддержке сложных функциональных возможностей. Каждый уровень имеет собственные цели и абстракции, взаимодействие между уровнями ограничено. Модульная организация обеспечивает возможности простого расширения функциональных возможностей системы, простую интеграцию новых высокоуровневых сервисов с существующими. Общая архитектура определяет согласованные интерфейсы между уровнями, интерфейсы для поддерживаемой совокупности протоколов, используемых как клиентами системы (например, HTTP, SMTP, SOAP, Z39.50, SDLIP, LDAP), так и провайдерами данных и услуг (например, HTTP, SMTP, SOAP, Z39.50, SDLIP, LDAP, OAIP[OAIP]), интерфейсы для базового множества операций - поиск, локализация, запрос, доставка и т.п.
Общая архитектура[MIA] выделяет следующие уровни.
Уровень представления. Этот уровень отвечает за представление информации пользователями обеспечение пользовательского ввода. Компоненты этого уровня должны поддерживать всевозможные интерфейсы с разнообразным представлением данных, среди которых ключевым является Web-интерфейс с представлением на HTML, XML языках. Информация, вводимая пользователем, передается вниз на прикладной уровень, что может осуществляться посредством создания программных объектов для передачи их через согласованные API/интерфейсы или с помощью кодирования данных в специфическом транспортном формате (сериализации), например RDF/XML.
Прикладной уровень. Прикладной уровень обеспечивает реализацию прикладных операций, необходимых пользователям или программным агентам в рамках системы. Он отвечает за поддержку логики приложений системы. Прикладные операции - это высокоуровневые сервисы, реализуемые на основе низкоуровневых функций связующего программного обеспечения (промежуточного уровня). Прикладной уровень может поставлять на уровень представления и собственные сервисы, не зависящие от нижних уровней, например, сервис персонификации. Уровень отвечает за поддержку пользовательских профилей, за ведение сессий пользователей. Может приспосабливать информационное окружение под определенные сообщества пользователей, например, предоставлять предварительно сформированные поисковые запросы, средства типа закладок или рекомендаций. В его задачу входит адаптация запросов и их результатов к текущей ситуации, определяемой событиями сессии и профилем пользователя. Например, при поступлении поискового запроса в него могут включаться ограничения, определенные в профиле и обуславливаемые известными рубрикаторами. Аналогичное согласование данных может происходить при возврате результатов, например, из результата могут удаляться ресурсы, предоставленные пользователю ранее в ходе текущего сеанса.
Связующий уровень. Этот уровень (уровень промежуточного связующего программного обеспечения - посредника) ответственен за понимание значения сервисов, запрашиваемых прикладным уровнем, и сервисов, предоставляемых провайдерами. Связующий уровень, получая запросы от прикладного уровня, должен определить, какие из провайдеров услуг могут удовлетворить запрос, возможно, некая комбинация из них. Связующий уровень может обеспечивать управление авторскими правами.
Коммуникационный уровень. Коммуникационный уровень обеспечивает единообразное представление провайдеров данных, использующих разные сетевые возможности, формирует объектное представление данных. Он ответственен за коммуникации с внешними сервисами, скрывает от связующего уровня такие подробности, как коммуникационные протоколы, расположение внешних сервисов, внутреннюю организацию данных того или иного провайдера. Он может обеспечивать отображение между словарями метаданных, чтобы поддержать термины, понятые связующему уровню. В некоторых случаях сервисы провайдеров (внешних сервисов) могут «непосредственно» взаимодействовать со связующим уровнем (влияние коммуникационного уровня тривиально), например, с целью повышения эффективности исполнения некоторых операций. В таких случаях на связующем уровне выделяются обобщающие стандартизуемые интерфейсы, которые могут поддерживаться разными провайдерами данных – механизм расширения функциональности предоставляемой провайдерами данных (plugins). Например, так для сервиса категоризаации реализована поддержка запросов к иерархическим структурам данных – рубрикаторам, тезаурусам. Коммуникационный уровень обеспечивает связь между связующим уровнем и провайдерами, основываясь на профиле сетевого сервиса, связанным с каждым сервисом, предоставляемым провайдерами. Профиль сетевого сервиса предоставляет информацию о расположении, протоколе, языке запросов и форматах данных и словарях метаданных, требуемых для осмысленного доступа к внешнему сервису.
Уровень провайдеров данных и услуг. Уровень провайдеров данных и услуг включает все внешние сервисы, предоставляемые провайдерами в соответствии с профилями сетевых сервисов. Уровень включает "первичные" сервисы, на основе которых функционирует система, которые обеспечиваю доступ к информации и службам. Он также включает "вторичные" сервисы, используемые системой при предоставлении "первичных" сервисов. Это, например, могут быть реестры схем метаданных, сервисы аутентификации.
Базовые механизмы цифровых библиотек и корпоративных порталов реализуются средствами набора сервисов, следующих общей многоуровневой архитектуре системы. Ключевую роль играет совокупность базовых сервисов, называемая ядром ИСИР, включающая репозиторный сервис, сервисы глобальной идентификации, контроля доступа, категоризации. Компоненты базовых сервисов в основном относятся к коммуникационному и связующему уровням. Так механизм репозиторного сервиса, обеспечивающий отображение объектной модели данных во внутреннюю модель данных, относится к коммуникационному уровню. Основываясь на услугах базовых сервисов, сервисы следующих уровней обеспечивают доступ к объектным данным, управление ими, обмен данными, локальный поиск, поиск в распределенной среде, управление потоками работ, управление слабоструктурированным содержанием портала и т.д. К таким, например, относятся сервис управления объектными данными, индексный и поисковый сервисы, сервисы обмена данными и управления метаинформацией и др. Компоненты этих сервисов в основном принадлежат к прикладному уровню, частично к связующему уровню. Многие из высокоуровневых сервисов имеют компоненты уровня представления, как правило, Web-интерфейсы, обеспечивающие соответствующее сервису взаимодействие с пользователями системы.
В текущей состоянии реализации основное внимание уделено поддержке RDBMS провайдеров данных и Web клиентов. На следующем рисунке представлена совокупность основных сервисов системы.
В текущей реализации системы обязательно присутствует выделенный RDBMS-провайдер «собственных» данных и метаданных как служебных, так и информационных. Имеется поддержка XML[XML], RDFS[RDFS], SOAP[SOAP] и SDLIP[SDLIP] провайдеров данных. Ведется реализация JNDI[JNDI] адаптера для поддержки LDAP серверов, имеющая свое основной целью обеспечение интеграции информационных и сетевых сервисов.
Технологии ИСИР ориентируются на формирование единой корпоративной информационной системы из разнородных хранилищ и источников информации в распределенной среде, включая объектные и реляционные базы данных, LDAP-каталоги и пр. Каждое полнофункциональное хранилище называется репозиторием. ИСИР предоставляет многочисленные службы по поддержке репозиториев, например репликацию и обмен данными, индексирование и поиск, технологию построения Web-порталов для доступа к данным.
 |
Основой новой версии ИСИР является объектно-ориентированный подход к представлению данных. Использование такого подхода унифицирует модель хранимых данных, облегчает процесс интеграции с Semantic Web[SW], XML-технологиями[XML], стандартами OMG[OMG] и ODMG[ODMG]. Использование понятия «хранимых объектов» в объектно-ориентированном языке программирования (на платформах Java, .NET) позволяет разработчикам прикладных приложений на базе ИСИР-технологий абстрагироваться от ненужных деталей и сконцентрировать своё внимание собственно на логике приложения. |
Каждый репозиторий не универсален: он не может, и не должен хранить «что угодно». Репозиторий специализируется в своей предметной области, и способен хранить данные, соответствующие его объектной схеме, которая описывает используемые классы и свойства. Ядро ИСИР обеспечивает механизм отображения объектной модели данных во внутреннюю модель данных используемого хранилища (реляционную, LDAP…). Так, в случае реляционного хранилища объектной схеме соответствует структура таблиц базы данных. С помощью такого механизма отображения ядро системы фактически превращает низлежащее хранилище в объектную базу данных и позволяет прикладному коду работать с «хранимыми объектами», изменения в которых прозрачно отображаются в хранилище. На данном этапе подобный механизм отображения поддерживается для реляционных СУБД, разрабатывается поддержка для LDAP каталогов.
В ИСИР мы используем Semantic Web язык описания объектных схем - RDFS[RDFS]. Этот выбор обусловлен простой объектной модели, удобством введения новых примитивов моделирования, ориентацией на такие задачи Web, как семантическая интероперабельность данных, адекватный поиск. Модель данных RDFS представляет собой адаптацию реляционной модели данных к распределённой среде Web. Причиной отличия парадигмы RDFS от традиционной объектной парадигмы является необходимость в децентрализализации и глобализации информационной системы, к которой мы приходим, выходя в Web пространство.
Мы вводим в RDFS новые примитивы моделирования, которые позволяют эффективно использовать этот язык для отражения как глобального, так и локального аспектов информационной системы. Более того, мы стремимся включить в RDFS-схему всю метаинформацию, необходимую системе, определяя в RDFS соответствующие конструкции. Она по существу является файловым мета-репозиторием системы. Например, RDFS-схема содержит не только формальные спецификации классов и свойств ресурсов, но их наименования и пользовательские описания на русском и английском языках, поскольку они являются такими же их характеристиками, как сведения о структуре или базовых классах. Совокупность введенных примитивов моделирования в купе с исходными примитивами RDFS, получила название языка описания iRDFS-схем. В предыдущем выпуске журнала [ELBIB-3-2003] представлена статья, в которой анализируются основные концепции Semantic Web. Приводится сопоставление парадигмы Semantic Web с традиционными парадигмами программирования, решений ИСИР с задачами Semantic Web. Рассматриваются основные примитивы моделирования, введенные нами, показана RDFS-подсхема классов для прикладной системы ИСИР РАН.
Каждый репозиторий рассматривает свою RDF-схему как замкнутое жёсткое описание собственной объектной схемы данных, которой соответствует структура «хранимых» java-классов и схема хранилища, например реляционной БД. С другой стороны, использование RDFS и технологий Semantic Web приносит существенные выгоды при интеграции различных репозиториев в единую информационную среду, взаимодействии со сторонними информационными источниками.
Приоритетное положение RDFS в ИСИР не мешает изначально описать объектную схему репозитория на ODL [ODMG], смоделировать на UML [UML], либо получить по существующей системе Java-классов. ИСИР предоставляет некоторые механизмы по отображению таких описаний друг в друга и их генерации.
Генератор Java-классов позволяет получить по iRDFS-схеме исходный код bean-подобных «хранимых классов». В эти классы вручную может быть заложена любая бизнес-логика, заменяющая или дополняющая исходное поведение. При изменении схемы (например, добавлении свойств) будет произведена инкрементная перегенерация классов – внесённые в код изменения будут сохранены. Таким образом, не ограничивая функциональных возможностей системы, RDFS позволяет автоматизировать реализацию многих обязательных операций.
Прототип генератора реляционной БД позволяет получить по iRDFS-схеме SQL DDL-скрипт для создания таблиц для хранимых данных, спецификацию соответствующего объектно-реляционного отображения. Процесс генерации является управляемым, можно явно указать, какие реляционные конструкции необходимо использовать в том или ином случае для поддержки тех или иных элементов объектной схемы, например, какое решение применить для поддержки наследования класса. Благодаря расширяемости RDFS, настройки генератора указываются в RDF-формате вместе с описанием объектно-реляционного отображения. В случае, когда необходимо настроить ИСИР-приложение на имеющуюся унаследованную БД, можно воспользоваться управляемостью генерации и специфицировать требуемый вид отображения, сопоставив таблицы и поля реляционной БД классам и свойствам объектной схемы. Это позволяет существенно упростить расширение области применения унаследованных БД, открыть доступ к ним ведущим Web и Semantic Web технологиям.
iRDF-схема используется не только репозиторным сервисом, представляя структуры хранимых данных, она влияет на поведение и других сервисов системы, обеспечивая их способность функционировать в рамках необходимой предметной области. Даже, описывая свои Web страницы и формы, использующие данные репозитория, вы должны пишете Xpath-выражения и OQL-запросы в соответствие с RDF-схемой (см. раздел «Web-публикация и XSLT»). В целом каждая конкретная прикладная система, реализуемая на технологиях ИСИР, параметризована iRDF-схемой соответствующей предметной области. Сама система ИСИР по существу является средой разработки прикладных систем (framework), которым предоставляется возможность настройки на требуемую схему данных, набор «базовых» операций над соответствующими данными (управление и обмен данными, их публикация и поиск) и ряд традиционных Web-сервисов, например, управление слабоструктурированной информацией (WCMS), форумы, механизмы новостей, подписки и т.п. На основе «базовых» операций, достаточных для обычных Web-систем, при необходимости могут быть реализованы требуемые дополнительные функции системы.
Вся функциональность ядра обеспечивается специальными объектами, существующими в единственном экземпляре (синглетонами) и называемыми сервисами. Каждый сервис отвечает конкретным функциональным потребностям – хранение объектов, наблюдение за хранимыми объектами, аутентификация пользователей, авторизация доступа и пр. Сервисы ядра используют функциональные возможности друг друга. Реализации сервисов могут замещаться. Такая организация обеспечивает модульность программной среды.
Как уже было сказано, ИСИР-приложения фактически работают с объектной базой данных, ответственной за хранение нужных приложению данных и надстроенной над реальным хранилищем некоторого типа. Доступ к такой объектной БД предоставляется репозиторным сервисом ядра (Persistence Service). Интерфейс этого сервиса является подмножеством стандартного интерфейса объектных баз данных ODMG[ODMG], который позволяет извлекать нужные объекты OQL-запросами, управлять транзакциями. Приложение работает с полученными из репозиторного сервиса «управляемыми» объектами как с обычными объектами языка Java - вызывает их методы, меняет свойства. При успешном завершении транзакции изменения отражаются в хранилище.
Сервис глобального наблюдения предоставляет возможность регистрировать в системе объекты-наблюдатели, получающие уведомления об изменении состояния интересующих их хранимых объектов. Эти наблюдатели могут проверять необходимые условия (например, проверки прав доступа), изменять связанную с данным объектом информацию (например, вести аудит изменений) и т.п. Использование «наблюдателей» позволяет придать требуемым типам хранимых объектов необходимую функциональность, не реализуя её непосредственно в коде класса.
Ядро системы предоставляет различные встроенные услуги по управлению хранимыми объектами, например, автоматическая проверка прав доступа, аудит и пр. Для того чтобы к хранимому классу была подключена некоторая услуга, он должен реализовать соответствующий маркер-интерфейс. К одному классу могут быть подключены несколько услуг одновременно (например «зависимый объект» и «персональные права доступа»). В iRDFS подключению услуг соответствует наследование классов от предопределённых базовых «абстрактных классов».
В дополнение к поддержке отображения объектов репозиторный сервис предоставляет возможность работать непосредственно с хранилищем конкретного вида, используя специальные интерфейсы (plugins), которые могут поддерживаться разными типами хранилищ данных. Это позволяют повысить эффективность исполнения некоторых операций в сравнении с их прямой реализацией на базе механизма хранимых объектов и ODMG API [ODMG]. Например, это существенно при проверке прав доступа к хранимым объектам, при поддержке запросов к иерархическим структурам данных и т.п.
Сервис аутентификации отвечает за поддержку входа пользователей в систему. Многие компоненты ядра, например система безопасности, аудита и пр., используют этот сервис для отождествления текущего пользователя. В стандартной реализации сервис аутентификации поддерживает соответствующий стандартный J2EE API - JAAS.
Сервис авторизации (Permission Service) отвечает за проверку прав доступа к объектам класса SecureObject, за управление их правами доступа. Права доступа выражаются в виде списка разрешений- Access Control List. Каждый элемент списка – это тройка <субъект доступа, объект доступа, привилегия>. Субъект доступа - это пользователь или группа пользователей. Объект доступа - это SecureObject-объект или их группа, к которым относится разрешение. Привилегия (вид доступа) представляет некоторую операцию или их группу, которые разрешено субъекту доступа производить над объектом доступа. Привилегии, поддерживаемые ядром системы, включают:
Разрешения, непосредственно указанные в списке, называются прямыми разрешениями, кроме них существуют неявные разрешения, вычисляемые в соответствии со следующими правилами:
Отсутствие у пользователя прямого или неявного разрешения на некоторую операцию над объектом означает запрет операции на ее выполнение.
Система безопасности ядра рассчитана на среду с большим количеством защищенных объектов и пользователей. Так группирующим объектам, которые некоторым образом можно соотнести с понятием «пользователя системы» (например, объектам, представляющим организационные единицы, - организации, подразделения, коллективы), может быть сопоставлена возможность представлять группы пользователей - формировать виртуальные группы пользователей. «Сотрудники» таких «орг. единиц» автоматически становятся пользователями системы и составляют эти виртуальные группы пользователей. В этом случае с некоторым видом взаимосвязи группирующих объектов (например, «административному подчинению» «орг. единиц») может быть соотнесена вложенность соответствующих групп пользователей. Если некоторой «орг. единице» (как группе пользователей) сопоставить право на определенный вид доступа к какому-то объекту или их группе, то все её «сотрудники» (как пользователи) смогут воспользоваться этим правом.
Кроме того, крупные информационные объекты могут наследовать права доступа в соответствии с некоторой структурой их взаимосвязи - формировать вложенность соответствующих виртуальных групп объектов доступа. Например, права доступа к «подразделению» могут быть унаследованы от «организации», содержащей это «подразделение». Права доступа к «сотруднику» «подразделения» могут определяться правами доступа к «подразделению».
Использование объектов класса DependentObject позволяет облегчить процесс проверки прав доступа, если объект не нуждается в персональных правах. Так, если доступ к элементам «штатного расписания» («штатным единицам») «организации» всецело определяется правами доступа к «организации», достаточно сделать «штатную единицу» объектом, зависимым от «организации». В этом случае «штатная единица» попадают под политику безопасности определенную для «организации».
Возможны и более сложные комбинации из зависимых и защищаемых объектов. Объект может одновременно являться DependentObject и SecureObject, то есть иметь персональные права доступа. Тогда для его чтения, модификации, удаления необходимо не только личное разрешение для этого объекта, но и аналогичное разрешение для его объекта-контекста. Например, «полный текст» «публикации» может предоставляться за отдельную плату, в то время как «библиографическое описание» может быть публично доступным.
Сервис авторизации используется системой безопасности ядра, но может быть использован прикладными приложениями, которые кроме этого могут определять собственные неизвестные ядру привилегии и самостоятельно проверять их соблюдение.
Сервис аудита изменений обеспечивает регистрацию всех модификаций для всех AuditedObject-объектов (с помощью специального наблюдателя, зарегистрированного в «сервисе глобального наблюдения») и позволяет получить соответствующую информацию.
Репозиторный сервис позволяет абстрагироваться от конкретного устройства хранилища и работать с хранимыми Java-объектами, соответствующими объектной схеме репозитория. Многие службы, тем не менее, нуждаются в большей абстракции – они должны уметь работать с разными объектными схемами. Для таких служб в системе поддерживается абстрактный интерфейс, называемый унифицирующим интерфейсом - Unified API (UAPI), обеспечивающий опосредованную работу с репозиторным сервисом и хранимыми объектами. Unified API представляет собой набор простых Java-интерфейсов, ориентированных на работу с RDF-совместимыми данными. Он представляет хранимые объекты репозитория согласно модели данных RDF - в виде направленного графа, удовлетворяющего RDF-схеме репозитория, где вершинами являются объекты, а рёбрами свойства. Многие прикладные сервисы системы используют RDF-схему и Unified-интерфейс для работы с репозиторием, что позволяет получить их «схемонезависимую» или точнее параметризованную RDF-схемой реализацию, где выполняемые над данными манипуляции следуют RDF-схеме репозитория. Так реализован ряд внешних служб системы, в первую очередь, это так называемые сервисы сериализации/десериализации. Unified API достаточно прост в реализации, по крайней мере, в сравнении с полнофункциональным репозиторным сервисом, что позволяет применить «схемонезависимые» службы к внешним источникам информации, обеспечив поддержку только Unified API.
На базе сервисов ядра и Unified API построены следующие высокоуровневые сервисы системы:
Программные компоненты, представляющие высокоуровневые сервисы, за исключением сервисов сериализации и десериализации, могут размещаться удаленно от репозиторного сервиса, как в пределах локальной сети, так и в рамках Интернет. Это вкупе с Unified API снижает требования к внешним источникам информации, существенно упрощает их поддержку.
 |
В архитектуре ИСИР широко используются XML-технологии. XML-представление данных является такой же неотъемлемой частью ИСИР, как и объектное представление. XML-представление объектных данных позволяет применить к ним всю мощь XML-технологий и интегрировать в архитектуру различные разработки, связанные с XML (XSLT и XForms, RDF/XML, SOAP, ...). В многоуровневой архитектуре ИСИР XML-представление данных стоит на следующей ступеньке после объектного представления, которое в свою очередь находится над внутренним представлением данных конкретного хранилища (ODBMS, RDBMS, LDAP, ...). |
Ядро ИСИР обеспечивает отображение внутреннего представления в объектное представление, позволяет прикладному программисту работать с хранимыми объектами как с обычными объектами языка программирования (Java, .NET), и обеспечивает прозрачное отображение изменений объектов в хранилище. Службы сериализации и десериализации поддерживают отображение между объектным и XML представлениями. Поддержка протокола SOAP[SOAP] позволяет организовать Web-сервисы[WSDL, UDDI]на базе функциональности репозитория, его внешних служб.
В ИСИР представление объектной информации в XML-виде опирается на идеи и принципы Semantic Web[SW]. Этот W3C-проект являет собой логическое продолжение развития Web – от гипертекстовых страниц к структурированным XML-документам, а затем к смысловому содержанию данных и их адекватной машинной интерпретации. Модель данных Sematic Web представляет собой выражение реляционной модели данных в глобальном аспекте Web – объекты и их свойства идентифицируются с помощью URI. Semantic Web определяет способ описания данных Web (RDFS-схема), способ их записи в XML виде (RDF/XML-синтаксис). Представление информации в XML в соответствии с принципами Semantic Web приносит ряд существенных преимуществ при обмене этой информацией, при интеграции данных. В ИСИР структура RDF/XML документов, формируемых для данных репозитория, чётко соответствует его объектной RDFS-схеме. Такие RDF/XML документы несут в себе не только данные и их структуру, но в определенной мере семантику сериализованных данных. Сторонний потребитель RDF/XML документа имеет возможность сопоставить RDFS-схему данных документа с собственной системой классов и свойств и адекватно обработать сериализованные данные. Это как раз то преимущество, которое несёт Semantic Web – семантическая интероперабельность. Интеграция XML и Semantic Web технологий в ИСИР с позволяет эффективно использовать XML для обмена информацией как между репозиториями ИСИР, так и со сторонними системами. ИСИР-репозитории могут служить источниками RDF-знаний для сторонних программных агентов Semantic Web, таких как поисковые системы. ИСИР-технологии способны сделать доступным в Semantic Web огромное количество информации, накопленной в унаследованных базах данных и системах. С другой стороны, Semantic Web предоставляет ИСИР-репозиториям возможность «добывать» информацию из сторонних источников, связывать с ней свои данные.
Упомянутые выше службы ориентированы в большей степени на обработку данных или обмен ими, они используют XML для представления этих данных в линейной форме. Другой аспект использования XML-технологий в ИСИР – это Web-публикация информации с применением XSLT. Использование XML/XSLT для построения Web-порталов позволяет, во-первых, разделить логику выборки данных и стиль их визуального представления, то есть разграничить области ответственности дизайнера и программиста. В результате дизайн сайта может эволюционировать со временем независимо от его информационного наполнения. Во-вторых, мы получаем возможность представлять страницу пользователю в различных форматах помимо HTML (WML для сотовых телефонов, PDF для печати, Excel для отчётов, SVG для графиков, RDF для метаданных).
Для каждой страницы портала, использующей данные репозитория, необходимо отдельно описать:
При разработке всех компонентов архитектуры ИСИР мы придерживаемся стратегии следования открытым стандартам и общепризнанным решениям. В плане поддержки XML/XSLT-технологий выбор пал на хорошо зарекомендовавший себя Apache-проект Cocoon [COCOON].
Cocoon опирается на простую конвейерную модель обработки данных: XML-документ проходит через конвейер, который представляет собой несколько фаз преобразования XML-данных. Каждый конвейер начинается генератором XML-данных (точка возникновения данных), содержит несколько преобразователей XML-данных (например, XSLT) и завершается сериализатором (выходные данные в требуемом формате). По конвейеру последовательно в виде потока SAX-событий (событий «открытия» и «закрытия» XML-элементов; это одна из компактных форм записи XML) перемещаются XML-данные. В ходе их прохождения по конвейеру происходит преобразование XML-данных от исходной формы к требуемой.
Простейшие сериализаторы преобразует SAX-поток в поток символов соответствующего XML-файла (XHTML, WML, SVG, VRML), более сложные могут преобразовывать SVG-данные в JPEG или PNG-формат, XSL FO данные - в PDF, PostScript формы.
Cocoon обобщает понятие «активных серверных страниц» на случай XML/XSLT-публикации данных, вводя механизм XML-серверных страниц (Extensible Server Page - XSP). XSP позволяет сконцентрировать своё внимание на формировании данных, требуемых странице, переложив задачу их визуализации на плечи XSLT. Для включения в XSP-страницы программного Java-кода и управления им предоставляются элементы xsp:logic и xsp:expr. XSP-страница транслируется Cocoon-ом в Java программу - генератор XML-данных. К XML-данным, сформированным XSP-страницей, в конвейере может быть применен ряд преобразований, дающих требуемые для визуализации XML-данные.
Использовать JSP для написания приложений со сложной логикой обработки было бы очень неудобно, если бы не было механизма «библиотек тегов» (tag libraries), обеспечивающих стандартизованную реализацию часто используемых конструкций. XSP тоже предоставляет механизм повторного использования кода, но несколько в иной форме. В XSP роль «библиотек тегов» играют так называемые «листы логики» (logicsheets), описывающие «XSLT-реализацию» вводимых ими тегов – преобразование тегов в соответствующие XML-данные, представляющие реализацию логики тегов. Эти преобразования применяются к XSP-страницам до их трансляции в Java-код соответствующего генератора.
Механизм logicsheet-преобразований существенно более гибок, чем JSP механизм библиотек тегов, поскольку в рамках logicsheet мы получаем полный контроль над всем обрабатываемым XSP-документом, а не только над конструкцией, выделяемой соответствующим «спец-тегом». Это позволяет изменить логику обработки исходной страницы, вводить «спец-атрибуты» вместо «спец-тегов», произвольным образом интерпретировать XML-элементы, не относящиеся к категории «спец-тегов», и т.п. Однако, это же делает этот механизм значительно более опасным, требует большой аккуратности в реализации logicsheet.
Этот потенциал XSP позволил сделать описание выборки объектных данных из ИСИР-репозитория максимально декларативным и ясным. Для этого было разработан специальный logicsheet-преобразователь (ISP), позволяющий получить на выходе XML-данные, соответствующие iRDF-схеме репозитория и удовлетворяющие в RDF/XML синтаксису, следовательно, представляющий хранимую объектную информацию в соответствие с принципами Semantic Web. Ниже приведен пример таких XML-данных.
<?xml version="1.0"?>Язык iXSP-страниц (XSP-страницы, использующих этот logicsheet-преобразователь) позволяет наглядно и декларативно описать выборку из репозитория необходимых объектных данных, и их представление в RDF/XML форме.
В результате большинство iXSP-страниц имеют предельно простой вид – они извлекают указанный параметром объект и включают в XML нужные атрибуты и связи с другими объектами, хотя могут содержать произвольный управляющий код. Ниже приведен пример iXSP-страницы, формирующей приведённые выше XML-данные.
<?xml version="1.0"?> <!--Указание xmlns:isp и xmlns:xsp-request включает logicsheets ISP и Cocoon Request --> <xsp:page xmlns:xsp="http://apache.org/xsp" xmlns:isp="urn:hdl:1016.1/isp" xmlns:xsp-request="http://apache.org/xsp/request/2.0" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:isir="urn:hdl:1016.1/core/"> <rdf:RDF> <!-- корневой элемент генерируемого XML (RDF/XML) --> <isir:organization> <!-- Указываем, какого класса объекты нужны - организации --> <isp:serialize-by-id> <!-- Указываем, как выбрать объекты этого класса: нужен объект, имеющий идентификатор (ObjectWithId), <xsp-request:get-parameter name="id"/> <-- указанный HTTP-параметром id --> </isp:serialize-by-id> <!-- Указываем, значения каких свойств этого объекта представить в XML: в начале isir:unitName, затем isir:department --> <isir:unitName isp:localize="yes"> <!-- Извлечь из коллекции значений свойстваisir:unitName «локализованое» значение - значение, соответствующее текущему выбору языка клиентом --> <isir:full/> <!--какие из свойства объекта-значения представить в XML--> <isir:abbrev/> </isir:unitName> <!-- Извлечь подразделения организации с приоритетом 0 – дирекцию --> <isir:department isp:oql-filter="this.departmentType.priority = 0"> <isir:unitName isp:localize="yes"> <!-- Извлечь «локализованое» наименование --> <isir:full/> <!--Вставить полное наименование подразделения --> </isir:unitName> <isir:staff> <!-- Для всех членов подразделения --> <isir:rank> <!-- вывести «локализованые» название должности--> <isir:name isp:localize="yes"> <isir:full/> <isir:name> </isir:rank> <isir:hired> <!-- и ФИО человека, занимающего эту должность--> <isir:personName isp:localize="yes"> <isir:first/> <isir:middle/> <isir:last/> </isir:personName> </isir:hired> </isir:staff> </isir:department> </isir:organization> </rdf:RDF> </xsp:page>
Смысл этой iXSP-страницы очевиден – она обращается к репозиторному сервису, находит (если клиент имеет право на чтение объекта) в хранилище организацию по ее идентификатору, указанному HTTP-параметром, а затем выводит (если клиент имеет право на чтение свойств) название организации, информацию о подразделении с нулевым приоритетом и занимаемых должностях этого подразделения.
iXSP-страница практически является шаблоном результирующего XML-документа, в который требуется подставить соответствующие данные из репозитория, чтобы получить приведённый выше RDF/XML документ. Именно эта «шаблонная часть» составляет основное содержание страницы. Управляющие теги и атрибуты, задающие логику формирования данных, не мешают увидеть структуру результирующего документа. Смотря на такой шаблон, не вдаваясь в логику страницы, можно без труда написать XSLT-преобразование для визуализации результатов этой iXSP-страница.
В завершение охарактеризуем механизмы разработки Web-форм редактирования хранимой информации. Для этих целей могут использоваться две технологии – на базе JSP и XForms. Для создания форм на JSP разработана специальная среда управления формами (Formbuilder framework), базирующаяся на JSP-библиотеке тегов и отвечающая за встраивание в формы данных хранимых объектов и обработку результатов редактирования формы. Formbuilder работает напрямую с репозиторным сервисом ядра и хранимыми объектами. Аналогично механизму iXSP-страниц Formbuilder при работе с хранимыми объектами стремиться следовать RDF-схеме репозитория, хотя в несколько иной форме – в форме JXPath-выражений. Это можно видеть на следующем фрагменте кода.
<table align="left"><tr>
<td width="150">
<-- генерирует локализованную текстовую строку с указанной меткой -->
<jxpath:label value="ORGANIZATION_NAME"/>:</td> <td>
<-- Элемент text генерирует TEXT-поле для ввода текста.
Атрибут jxpath задает значение атрибута value HTML-тега. -->
<jxpath:text name="name"
jxpath="{<resource>unitName[language='{<page>dataLocale/language}']/full}"/>
</td></tr>
<tr><td width="150"><jxpath:label
value="ORGANIZATION_TYPE"/>:
</td><td>
<-- Элемент select генерирует SELECT элемент – выпадающий список.
Атрибут jxpath, принимающий (JXPath-выражение), указывает коллекцию объектов,
используемых для генерации списка.
Атрибут label задает путь к подписям пунктов списка относительно объекта коллекции.
Атрибут value задает путь к значениям пунктов списка относительно объекта коллекции.
-->
<jxpath:select name="type"
jxpath="{<orgtype>collection}"
label="{name[language='{<page>dataLocale/language}']/full}"
value="{ext:dectostr(id)}"
matcher="{<resource>ext:dectostr(organizationType/id)}"/>
</td>
</tr></table>
Другой механизм создания форм, находящийся на стадии проработки, опирается на спецификацию XForms[XFORMS]. Форма в XForms – это XML-данные, подлежащие редактированию, набор управляющих элементов формы и сопоставление XML-данных этим элементам. Результатом редактирования формы являются XML-данные. В ходе интерпретации XForms-формы, обеспечивающей редактирование некоторого хранимого объекта, необходимые значения свойств этого объекта представляются в RDF/XML и подаются в качестве данных формы, а после завершения редактирования возвращаемые данные в RDF/XML форме с помощью сервиса десериализации замещают исходные значения свойств объекта.
В наше время происходит стремительный рост числа информационных Web-порталов и цифровых библиотек, в которых все большее и большее применение находят автоматизированные системы управления потоками работ. С их помощью становится возможным увеличение качества и объемов выполняемых работ по манипулированию информационным наполнением и сервисами Web-порталов и цифровых библиотек. С появлением сложных Web-систем, цифровых библиотек, корпоративных порталов, поддерживающих и управляющих большими объемами и потоками информации, сформировалось категория подсистем, называемых системами управления содержанием/контентом Web-систем (WCMS - Web Content Management System). Первые WCMS представляли совокупности Web-форм для управления данными – как несвязанных, так взаимосвязанных Web-форм, но с фиксированным в программном коде порядком обработки. Сейчас актуальной становится потребность в более гибкой организации управления потоками работ, в поддержке декларативных форм определения и оперативного изменения потоков работ. WCMS должны управлять созданием и модификацией информационных, сильно взаимосвязанных ресурсов произвольных типов. Потоки работ могут быть связаны не только с поддержкой информационных ресурсов, но и с выполнением полностью автономных регламентных процедур системы в ответ, например, на программные обращения, на наступление некоторого события и т.п.
Репозитории ИСИР должны обладать гибкими средствами для поддержки актуальности данных: пакетной загрузкой информации, автоматизированными средствами создания и редактирования ресурсов. Редактирование и создание отдельных ресурсов с помощью форм требует наличия системы, управляющей декларируемыми потоками работ пользователей. RDF/XML загрузка решают задачу внесения в базу данных больших объемов информации, однако после нее требуется участие администраторов данных, отвечающих на запросы системы по нарушениям форматов, разрешению неоднозначности, выявлению дубликатов, которое также должно быть осуществляться в рамках ролевых, контролируемых потоков работ. Поэтому возникла задача создания службы управления потоками работ.
Существующие на данный момент модели описания потоков работ разбиваются [Shapiro] на две категории:
Проведенный сравнительный анализ двух видов моделей на примере их основных представителей (XPDL и BPML) с точки зрения организации в них основных конструкций, определяющих модель потоков работ, показал, что все основополагающие конструкции блочной модели BPML могут быть выражены через их прямые аналоги модели потоков работ XPDL. Кроме того, спецификация XPDL обладает рядом очевидных преимуществ.
На основании проведенного анализа за базовый стандарт описания модели рабочих процессов по редактированию ресурсов репозитория ИСИР выбрана спецификация XML Process Definition Language (XPDL) ввиду наиболее полного соответствия требованиям к функциональности создаваемого решения. Была создана служба управления потоками работ по редактированию ресурсов репозиториев ИСИР, ориентирующаяся на это предложение.
Данная служба использует сервисы ИСИР для хранения в репозитории объектной модели рабочих процессов, аутентификации пользователей, управления доступом к объектам процессов. Административные и пользовательские интерфейсы системы управления потоками работ построены на базе ИСИР- технологий, автоматизирующих процесс построения Web-форм.
Общая объектная модель рабочего процесса представлена на следующей диаграмме:
Поддержка и следование службой управления рабочими процессами по манипулированию ресурсами репозитория ИСИР ряду соответствующих стандартов делает возможным ее применение в системах управления контентом Web-порталов, системах электронного документооборота и других сервисах, автоматизирующих управление потоками работ, распределенных между разнообразными участниками производственных процессов.
Широкая область применения служб подобного типа дает не менее широкие предпосылки к дальнейшему развитию и модернизации данного проекта. К ближайшим шагам по дальнейшей разработке и модернизации компонентов системы можно отнести следующее:
К задачам второстепенной важности можно отнести поддержку возможности экспорта XPDL-описаний с предварительным преобразованием к другим существующим стандартам декларации потоков работ и реализацию распределенной системы управления рабочими процессами.
Важная часть любой информационной Web-системы будь то сайт или портал - это представление информации, данных – содержания системы. Соответственно важнейшей функцией Web-системы является управлять содержанием. Служба управления содержанием призвана обеспечить сквозное управление единицами содержания, их взаимосвязями, образуемыми ими структурами и существенно снизить трудоемкость сопровождения информационной Web-системы. Часто службы управления содержанием сопровождаются функциональными модулями, обеспечивающими, например, комментирование статей содержания, анкетирование читателей, ведение дискуссий и обсуждений в рамках единиц содержания, то есть механизмами, обеспечивающими возможность привязки к разделам и документам данных, отражающих отношение пользователей к информации сайтов. Важным для таких служб является и обеспечение контролируемого прохождения этапов манипулирования содержанием - наличие неких редакционных процессов с разделением ролей авторов и редакторов, чтобы информация, прежде чем быть опубликованной, проходила необходимые стадии обработки, выполняемые разными людьми. Как правило, службы управления содержанием осуществляют манипулирование слабоструктурированной информацией, отличающейся нерегулярностью взаимосвязи ее элементов, редкостью изменений, такой как информационно-публицистические материалы сайта, пресс-релизы. Вследствие этого они обычно обеспечивают иерархическую каталогизацию данных одного типа – разделы/документы.
Мы стремимся видеть в службе управления содержанием разностороннею поддержку информационного содержания порталов и сайтов. Служба должна включать средства управления как неструктурированной, так структурированной информацией, средства сопряжения слабоструктурированных и структурированных данных, в частности, включения вторых в первые, механизмы атрибутно-полнотекстового индексирования данных обоих видов, поддержки синтаксической и семантической интероперабельности распределенных источников информации.
Реализация службы управления содержанием исходит из многоуровневой архитектуры системы ИСИР. Сервисы службы условно разделены по трём уровням. Каждый уровень имеет свои абстракции понятий, которыми оперируют его сервисы. Например, средства визуализации данных работает с понятиями (в частности, с разделами, статьями), которые предоставляет сервис хранения объектных данных, поддерживающий модель данных предметной области. Последний непосредственно взаимодействует с хранилищем (базой данных или файловой системой), поэтому расположен на более низком уровне. На следующем рисунке показаны сервисы, участвующие в обслуживании данных порталов на базе технологий ИСИР, стрелками обозначены зависимости между ними. Например, для обмена индексами используется протокол SOAP, который еще участвует в реализации распределенного поиска.
Служба управления слабоструктурированными материалами обеспечивает управление мульти-иерархической структурой и данными разделов и подразделов содержания. Основные сущности схемы данных и их взаимоотношения приведены на следующей упрощенной схеме.
 |
Раздел – основной структурный элемент каталога слабоструктурированных материалов. Всё множество разделов соответствует иерархии материалов сайта. Понятие варианта возникает из-за необходимости поддержки многоязычной информации. Вариант раздела представляет информацию, соответствующую одному из допустимых языков. Дополнение представляет собой дополнительные данные, ассоциированные с вариантом раздела. Различается три типа дополнений – произвольные данные, хранящиеся в виде файлов, URL-ссылки и запрос на включение структурированных данных («динамических данных»). Поля хранит непосредственно данные раздела. |
Служба поддерживает управление доступом на базе заданных прав доступа к объекту. Для организации наполнения и редактирования материала применяется служба управления рабочими процессами. Для визуализации данных применяется технология XSLТ. Для реализации визуальных интерфейсов используются стандартные для ИСИР технологий программные продукты.
Описание одной из страниц службы управления слабоструктурированными материалами приведёно на следующем рисунке.
Для посетителей портала или сайта поиск является наиболее удобным средством обнаружения необходимой информации. Несмотря на эффективность современных поисковых машин, у них есть несколько существенных ограничений. Они индексируют только открытую для внешнего мира часть сайта. Часто плохо индексируют динамические страницы. Не всегда возможно организовать поиск только по пространству сайта. Если даже это удалось осуществить, то актуальность индекса сайта, как правило, запаздывает на несколько дней. Предоставляется только полнотекстовый поиск. В связи с этим, если не рассматривается статический, полностью открытый сайт с большим периодом обновления, приобретает актуальность наличие собственной для сайта системы поиска. С точки зрения внутренней поисковой машины страницы имеют существенно больше атрибутов, чем это может выделить поисковая машина из сформированной HTML-страницы - это, например, авторы материала, даты создания и последнего изменения, связи с тематическими рубриками. Эти атрибуты позволяют более качественно осуществлять
Для полнотекстового индексирования имеются хорошо разработанные методы формирования индексов (инвертированные списки), имеются бесплатные реализации этого механизма. Однако, они плохо подходят для индексирования структурированных данных, например, XML-данных и данных БД. По мере роста динамичности сайтов, увеличения доли структурированных данных возникает потребность в иных решения, способных обеспечить индексирование локальных данных - и полнотекстовых, и структурированных.
Одно из решений - использовать с этой целью возможности реляционных СУБД. Такой подход был использован в рассматриваемой системе. Сервис индексирования обеспечивает построение «атрибутно-полнотекстового» IDF-индекса. Под «атрибутно-полнотекстовым» IDF-индексом понимается совокупность инвертированных списков, в которых для вхождения слова еще указывается контекст его вхождения (атрибут ресурса) - структурный элемент, его содержащий. Контекст используются для уточнения условий поиска и ранжирования. Ранжирование ресурсов базируется на частотных характеристиках слов.
Сервис умеет индексировать простые тексты, тексты с разметкой (HTML, XML) и данные в RDF формате, в частности, хранимые объекты репозитория, выдаваемые RDF-сериализатором. Индексирование параметризуется RDFS-описанием схемы данных, указывающей, какие свойства, какие объектов подлежат индексированию.
Сервис поддерживает нормализацию слов русского и английского языков. Нормализация слов используется для поддержки поиска, учитывающего словоформы слов. Нормализация может быть применена как в процессе индексирования, так и только при обработке слов запроса – пополнение запроса словоформами слов, заданных в запросе. Механизм основан на алгоритме iSpell и его открытых словарях. Процесс нормализации выполняется независимо от процесса индексирования.
IDF-индекс хранится и обслуживается реляционной СУБД. Сервис позволяет создавать несколько групп индексов, при этом для каждой группы формируется свой набор таблиц. Таблицы термов, нормальных форм и суффиксов являются общими для всех групп индексов. Схема достаточно проста, кроме частей, поддерживающих процессы нормализации слов, ранжирования ресурсов и сжатия информация о вхождениях слов.
Сервис поиска, принимая LDAP-подобные логические выражения, переводит их в SQL-запросы к таблицам индекса, выбирающие удовлетворяющие запросу ресурсы и ранжирующие их в соответствие с частотными характеристиками вхождений слов.
Процессы, происходящие при индексировании, изображены на следующей диаграмме.
 |
Все процессы (разбор, выделение термов, создание индекса, его временная запись в буфер, сохранение индекса) выполняются параллельно. При этом одни поставляет данные для других. Зависимости по данным изображены на диаграмме стрелками. Поскольку процесс сохранения индекса в БД медленнее процесса его формирования, процессы были разделены, и было обеспечено их параллельное функционирование с синхронизацией через файловый буфер. |
В работе рассмотрены архитектура, технологии и решения новой версии системы ИСИР, позволяющей разрабатывать распределённые объектно-ориентированные информационные системы - цифровые библиотеки, информационные и корпоративные порталы, сайты на базе различных типов хранилищ информации. Ядро системы унифицирует механизмы работы с хранимыми объектными данными, предоставляет ряд услуг по управлению хранимыми данными - управление доступом, аудит изменений, категоризация и т.п. На базе ядра реализованы более высокоуровневые сервисы и службы. Система имеет средства для разработки пользовательских Web-интерфейсов на базе XML/XSLT технологий. Примечательным является то, что механизмы системы параметризуются описанием объектной схемы данных. Это позволяет получить почти готовую информационную систему, приготовив объектную схему данных для требуемой предметной области. Для описания схемы используется язык RDFS - W3C стандарт на описание схем Интернет ресурсов. Во второй части статьи приведена краткая информация о наиболее интересных пользовательских службах системы, реализованных на рассмотренных технологиях системы. Это служба управления потоками работ по редактированию хранимыми данными, следующая стандартам WfMC, служба управления содержанием Web-сайта, обеспечивающая каталогизацию и управление слабоструктурированной информацией, служба атрибутно-полнотекстового поиска на базе РСУБД, индексирующая простые тексты, тексты с разметкой, RDF и хранимые данные, учитывающая словоформы слов, контекст их вхождений, ранжирующая ресурсы в соответствие с частотными характеристиками вхождений слов. Система была использована в реализации ряда открытых и коммерческих проектов, в которых хорошо себя зарекомендовала, что продемонстрировало ее практичность и зрелось.
Материал опубликован на http://www.elbib.ru/