Технологии Semantic Web для интеграции информационных систем

    Технологии семантической паутины (Semantic Web) периодически привлекают внимание благодаря тому, что на их основе создаются новые интересные инструменты. Совсем недавно появился социальный поиск (Graph Search) в Facebook – первый инструмент поиска по графу, доступный действительно широкому кругу пользователей.
    Однако, сфера применения семантических технологий не ограничивается социальными сетями и поисковыми сервисами. Идея применить эти технологии для организации обмена данными между информационными системами достаточно очевидна. Если одна система передает другой не только сами данные, но и информацию об их предметной сущности (смысле, семантике), это позволяет лучше абстрагировать обменивающиеся системы друг от друга, чем при использовании выгрузок в XML или веб-сервисов SOA.
    Кодирование информации в семантическую форму при передаче
    Сегодня существует несколько реализаций такого подхода. Большинство из них, конечно, сделано зарубежными компаниями, но есть и российские разработки. В этой статье я расскажу об архитектуре одной таких систем, которую реализовал на практике.

    При создании системы я исходил из предположения, что нескольким информационным системам необходимо очень быстро (с интервалом в несколько секунд) сообщать друг другу об изменениях, происходящих в их хранилищах данных. Поэтому архитектура сильно напоминает шину обмена сообщениями (Message Queue), основной особенностью которой является то, что содержание сообщений выражено в синтаксисе RDF, то есть представляет собой триплеты. Со стороны каждой из интегрируемых систем работает клиентский модуль обмена, который интерпретирует получаемые сообщения, и, если необходимо, вносит соответствующие изменения в хранилище данных этой системы. Клиентский модуль является активным, то есть, если в хранилище произошли изменения, о которых нужно сообщить другим системам – он кодирует сведения об этих изменениях в RDF, и отправляет в виде сообщения по шине.
    Роль маршрутизатора в шине выполняет центральный сервер-посредник, который обладает информацией о правах доступа информационных систем к разным видам данных, гарантирует доставку, контролирует целостность данных (и, при необходимости, старается ее восстановить), а также выполняет ряд других полезных функций. На рисунке ниже показана схема программных компонентов, участвующих в обмене. В качестве примера двух обменивающихся систем взяты, с одной стороны, некое веб-приложение на PHP/MySQL, и конфигурация 1С — с другой. Сервер-посредник тоже пока реализован на PHP/MySQL, однако будет переписан на более подходящей платформе. Что касается баз данных, то клиентскому компоненту уже сейчас все равно, с какой БД работать — MySQL, PostgreSQL или Oracle.
    Схема обмена между клиентами и сервером
    Разумеется, на практике обменивающихся систем может больше, чем две.
    Преимущества этого подхода по сравнению с выгрузкой в XML или веб-сервисом SOAP достаточно очевидны, особенно если исходить из того, что необходимо связать между собой три, четыре или более систем. Они могут оперировать одними и теми же типами объектов (например, во всех информационных системах любой компании почти наверняка присутствует понятие «клиент»), но обладать разными наборами данных о них, и использовать их в разных контекстах. Выгрузки в XML почти всегда будут избыточными, жестко связанными со структурой данных в БД-источнике, и потребуют написания программного кода для экспорта и импорта. Если, например, в CRM-системе хранятся таблицы с клиентами и сделками с ними, XML-выгрузка будет выглядеть примерно так:
    Выгрузка в XML
    Понятно, что одной системе-потребителю этой информации сведения о сделках потребуются с детализацией по товарам, другой — без нее, зато со сведениями о грузополучателе и сроке доставки, и т.д. Использование выгрузок становится крайне проблематичным, если какие-нибудь данные могут измениться «задним числом». А уж если какая-нибудь из систем-получателей имеет право вносить изменения в эти данные (например, из системы отдела логистики могут поступать сведения о фактической отгрузке товара) — продолжать использовать выгрузки можно только из чистого упорства.
    Более прогрессивный вариант — использовать SOAP веб-сервис. Тогда схема взаимодействия системы-источника с потребителями информации будет выглядеть так:
    Интеграция с использованием веб-сервиса SOAP
    Это будет удобно до тех пор, пока число сервисов (растущее пропорционально числу типов информационных объектов, которыми нужно обмениваться) не перевалит через несколько десятков. Тогда проблема мониторинга работоспособности сервисов, их документирования и поддержки начнет становиться по-настоящему критичной. Кроме того, это не решает проблему обратной связи систем: в упомянутом выше примере, когда система отдела логистики не только забирает информацию из CRM, но и может сама помещать в нее какие-либо данные, веб-сервисы придется реализовывать со стороны обеих систем, что совсем неудобно. Также программистам придется самим заботиться о безопасности сервисов, поддержании целостности данных, обработке ошибок и т.п. — проблем не счесть.
    В более крупных инфраструктурах применяют MDM-системы (что требует совсем другого порядка вложений и усилий), а также шины обмена сообщениями. Шины хороши тем, что позволяют объединять большое количество информационных систем без возрастания сложности обмена в зависимости от числа систем. Мы, фактически, и реализуем шину, только в отличие от «классической» шины будем передавать по ней сообщения, выглядящие примерно так:
    Информация, кодированная в виде триплетов RDF
    Как я уже говорил, каждая система-отправитель перед отправкой преобразует в такой формат сведения, которыми хочет поделиться, а каждая система-получатель интерпретирует их в соответствии со своими правилами.
    Преимущества такого подхода в сравнении с классической шиной обмена сообщениями состоят в том, что информационным системам нет необходимости создавать «протокол обмена», определяющий смысловую нагрузку сообщений. Его роль выполняет онтология, известная всем обменивающимся системам и серверу (сервер обладает наиболее полной версией онтологии, клиентские системы могут использовать ее подмножества). В настройках каждого клиентского модуля производится сопоставление (mapping) элементов онтологии структурным элементам локального хранилища данных (проще говоря, таблицам и полям базы). Разумеется, можно создавать пользовательские программные обработчики для сущностей и связей, которые не имеют однозначного отображения на структуру БД, но в практических внедрениях объем требуемого программного кода измеряется десятками строк. Также, в отличие от классических шин обмена сообщениями, в нашем случае сервер выполняет ряд высокоуровневых полезных функций, вроде уже упомянутого восстановления целостности данных, выявления дублей объектов, разрешения конфликтов. Кстати, заодно сервер может формировать SPARQL базу данных, в которой будут аккумулированы сведения из всех обменивающихся систем, представленные в виде графа. Это обещает обеспечить такие возможности аналитики, какие не сможет предоставить ни одна из интегрируемых систем в отдельности.
    Конечно же, использование описанного мной подхода позволяет решить все перечисленные выше проблемы интеграции: обеспечить независимость процедур обмена со стороны различных систем от структуры баз друг друга, отказоустойчивость, безопасность, гибкость настройки, возможность легко использовать одну и ту же информацию в разных контекстах, и т.п.
    Разумеется, описанный подход является далеко не единственным вариантом применения семантических технологий для интеграции данных. О возможных альтернативах я расскажу в следующем посте. Также за рамками этого поста остался вопрос о выборе онтологии для кодирования передаваемой информации.
    Метки:
    Поделиться публикацией
    Похожие публикации
    Комментарии 9
    • 0
      Думаю, добавление условий и связей превратит эту технологию в SQL.
      Хотя, именно этот метод был бы удобен для тех, кому привычнее консоль.
    • +2
      Занимался реализацией подобного проекта (интеграция нескольких ИС + MDM на основе RDF-хранилища). Т.к. множество аспектов не стандартизовано, а подводные камни каждый обходит по-своему, хотелось бы узнать подробнее о деталях реализации, если Вас не затруднит.
      1. Каким образом организовано разграничение привилегий для различных сервисов (на уровне частей онтологии/на уровне веб-сервиса)?
      2. Как разрешаются конфликты репликации (в трёх различных ИС различные значения заданного поля сущности)?
      3. Как ведётся версионирование данных (RDF Refine, Talis changeset, RDFSync и т.д.)? Как решались проблемы с производительностью?
      • 0
        Спасибо за интерес к посту! Отвечаю.
        1. Обоими способами. Каждая клиентская система обладает только той частью общей онтологии, которая ей нужна. Плюс на сервере есть настройки прав доступа — в визуальном интерфейсе администратор может настроить, какие элементы онтологии будут доступны каким системам (на чтение и на запись). Есть функция выгрузки онтологии с сервера на клиент: сервер передает клиенту часть общей онтологии, отфильтрованную в соответствии с правами доступа.
        2. По идее, такие ситуации должны предупреждаться настройкой прав, но если, скажем, две системы имеют право изменять одно и тоже свойство, к примеру телефон клиента, и делают это одновременно — «победит» та, чье сообщение будет позже доставлено серверу. Ее версия значения и будет распространена всем системам.
        3. До версионирования пока не добрались, хотя проблема очень актуальна. Производительностью как раз сейчас занимаемся, много что оптимизируем под нее. Надеюсь в ближайшее время написать статью на эту тему.
        • 0
          Планы написать статью про производительность накрылись, или ещё теплятся? Очень интересно!
          Версионирование тоже интересно!
          • +1
            Проблему версионирования решили в рамках другой разработки, скоро доложим на KESW 2014.
            По производительности делали кое-какой бенчмарк в прошлом году.
            В личку могу поделиться результатами.
    • 0
      1. А в сообщениях идет набор триплетов или один триплет?
      2. Атрибуты сообщения тоже закодированы в RDF? (дата создания/исходящая система)
      3. Табличные данные вы также передаете или уровнем Data Integration?
      • 0
        1. Набор триплетов. Буквально сегодня выложил статью об определении оптимального количества информационных объектов и триплетов в пакете
        2. Исходящая система определяется в процессе авторизации, дата создания тоже автоматически фиксируется сервером. Но некоторые атрибуты сообщения все же попадают в само сообщение.
        3. Пока также передаем, но имеется насущная необходимость разработать режим передачи табличных данных (прежде всего, для первоначальной синхронизации систем) — этим сейчас занимаемся.
    • 0
      Если вы еще не слышали, советую посмотреть на то, как семантический веб используется в интеграции данных в разных около-промышленных областях — у них там есть международный страндарт ISO 15926 для интеграции данных, и в нем описываются технологии Semantic Web.

      Русскоязычное сообщество пользователей стандарта — .15926. Уже даже есть русскоязычный софт для работы с интеграцией данных, все на Semantic Web технологиях, опять же.
      • 0
        Я знаком с этим стандартом, и являюсь читателем этого сообщества. Тут все далеко не так просто, и на тему отношения нашего подхода и ISO 15926 я также писал отдельную статью. Кстати, в том самом сообществе хватает «критики», а точнее, не совсем разумного противопоставления Semantic Web и ISO 15926. С одной стороны, понятно, что стандарт представляет собой более высокоуровневый подход, с другой — я уверен, что во многих практических применениях наш подход намного рациональнее.

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.