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

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

С какими проблемами сталкиваются специалисты, выполняющие подобную интеграцию?

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

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

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

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

Отметим основные достоинства такого метаописания.

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

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

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

Компоненты метахранилища

Метахранилище должно содержать следующие сведения:

• семантическую модель предметной области;
• метаописание нормативно-справочной информации (НСИ);
• метаописание (модель) бизнес-процессов;
• описание информационных ресурсов (собственных и внешних);
• описание компонентов самой ИС;
• каталог предлагаемых услуг (web-сервисов).

Семантическая (информационная) модель предметной области

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

Метаописание НСИ

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

Метаописание (модель) бизнес-процессов

Модель бизнес-процессов — наиболее привычная и широко используемая часть метаописания. Обычно эта модель создается на первом этапе проекта автоматизации в ходе обследования предприятия. Однако она может формироваться и по-другому. В настоящее время имеется немало готовых типовых библиотек процессов для различных областей деятельности, которые являются результатом анализа и обобщения передового опыта многих предприятий (так называемые best practices). Хотя использование этих библиотек позволяет избежать возможных серьезных ошибок, довольно часто описанные в них процессы избыточны, содержат лишние шаги. В таких случаях для “упрощения” процессов применяются специальные инструментальные средства, которые на уровне метаописания позволяют адаптировать процессы к специфике конкретного предприятия.

Принципы описания информационных ресурсов

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

Описание ресурса должно включать следующий минимальный набор сведений:

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

Такое описание позволяет решать многие задачи, например автоматически генерировать web-сервисы, взаимодействующие с тем или иным ресурсом.

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

Для описания ресурсов целесообразно использовать концепции и стандарты, одобренные ИT-сообществом, лидирующими компаниями-производителями, научными и индустриальными кругами; это могут быть, например, элементы Semantic Web* или стандарты W3C. Спецификация Semantic Web основывается на языке XML и, в частности, использует его способность определять настраиваемые схемы разметки.

Важнейший элемент концепции Semantic Web — опора на следующие стандарты:

 • Resource Definition Framework (RDF) — язык для описания содержания информационных ресурсов, обеспечивающий гибкий подход к представлению данных;
 • Web Ontology Language (OWL) — язык web-онтологий, который может формально описать значение терминов, используемых в web-документах;
 • XML — обеспечивает синтаксис для формирования структурированных документов, но не налагает никаких семантических ограничений на их содержание;
 • XML Schema — определяет структуру XML-документов, а также дополнительные типы данных.

Язык RDF позволяет описывать модель данных (datamodel) для объектов (“ресурсов”) и отношения между ними средствами XML. Специфиакция RDF Schema служит, в частности, для описания свойств и классов RDF-ресурсов. OWL предоставляет дополнительные возможности для описания свойств и классов, в том числе позволяя характеризовать отношения между классами (например, непересекаемость), задавать их кардинальность (скажем, “точно один”) и т. д.

Описание компонентов самой ИС

Компонентная модель ИС может базироваться на тех же принципах, что и описание информационных ресурсов. Однако информация о компонентах системы должна быть несколько иной, и описывается она другими языками, например ССМ (CORBA Component Model); BOCA (Business Object Component Architecture); CDL (Component Definition Language). Признанным лидером на поле стандартизации компонентов стала технология Enterprise Java Beans, предложенная компанией Sun.

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

Каталог внешних услуг (web-сервисов)

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

На основании такой модели формируется набор web-сервисов (либо API-интерфейсов), которые и образуют каталог услуг, предлагаемых ИБД.

Web-сервисы описываются с помощью языка Web Services Description Language (WSDL), определяющего способ доступа к ним. Он описывает функциональные возможности web-сервисов и группирует операции взаимодействия с ними в интерфейсы, задающие способы выполнения тех или иных операций и наборы входных и выходных параметров. Для обнаружения web-сервисов, их самого общего описания и интеграции используется универсальный метод Universal Description, Discovery and Integration (UDDI). Технология UDDI позволяет приложениям и организациям динамически находить нужные им другие приложения или услуги, если те описаны в терминах web-сервисов.

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

С автором, заместителем директора отделения ИТ-консалтинга компании “ФОРС — Центр разработки”, можно связаться по адресу: ipolotnyuk@fors.ru