CC BY
684
Шибанов С.В. , Яровая М.В, Шашков Б.Д., Кочегаров И.И., Трусов В.А. ОБЗОР СОВРЕМЕННЫХ МЕТОДОВ ИНТЕГРАЦИИ ДАННЫХ В ИНФОРМАЦИОННЫХ СИСТЕМАХ
Информационные системы (ИС) представляют широкий класс программного обеспечения, используемого различными предприятиями для автоматизации их работы. Поскольку объем обрабатываемой информации огромен, уже в каждой организации существует, как правило, несколько информационных систем. Часто в этих системах обрабатывается одна и та же информация. В связи с этим возникает проблема интеграции данных из различных систем.
Под интеграцией данных понимается процесс объединения данных из различных источников для получения их согласованного представления, в широком смысле - процесс организации регулярного обмена данными между различными ИС предприятия.
Методы реализации интеграции данных
Наиболее распространенными методами реализации интеграции данных являются:
обмен на основе файлов;
репликация данных;
технология Web-сервисов;
сервис-ориентированная архитектура (SOA);
интеграционные серверы.
Обмен файлами является наиболее распространенным способом интеграции. С точки зрения реализации это самый простой способ, но он имеет недостатки. В случае необходимости обмена сложными структурами, необходима разработка специализированных форматов файлов, что приводит к большой зависимости систем друг от друга. Также обмен с помощью файлов подразумевает наличие человека, который осуществляет выгрузку и загрузку файлов. Однако в случае невозможности взаимодействия через сеть перенос данных на физическом носителе является единственным возможным решением.
В частности обмен данными между подсистемами и с приложениями из пакета MS Office для автоматизированной информационной системы «Прокуратура-Статистика» был использован именно это метод. Было необходимо реализовать обмен статистическими отчетами между территориально удаленными подсистемами. Для обмена между узлами был разработан внутренний формат представления данных в двоичном файле. А для описания структуры отчета для приложений MS Word и MS Excel был использован язык XML для описания структуры форм отчетности. Это позволило универсально описать способ отображения данных в файле отчета для любой формы.
Язык XML также используется в системе "1С" для реализации обмена данными между различными подсистемами.
Репликация - процесс приведения данных электронных таблиц двух БД в идентичное состояние. Процесс репликации основан на понятиях "издатель" и "подписчик". Издателем является сервер публикации, т.е. сервер, отправляющий информацию. Подписчиком является соответственно принимающий сервер
- сервер подписки.
Репликации удобно разбить на две большие категории: репликация данных в среде между серверами
и репликация данных между сервером и клиентами. Репликация данных между серверами выполняется для поддержки следующих приложений и требований:
Повышение масштабируемости и доступностиОбслуживание непрерывно обновляемых копий данных позволяет масштабировать операции чтения на несколько серверов. Избыточность, которая возникает в результате обслуживания нескольких копий одних и тех же данных, критически важна для планового и непланового обслуживания системы.
Хранение данных и составление отчетов Серверы хранилищ данных и серверы отчетов часто используют данные с интерактивных обработки транзакций (OLTP). Используйте репликацию для перемещения данных между серверами OLTP и системами подготовки отчетов и поддержки решений.
Объединение данных с нескольких узлов Данные из удаленных офисов часто накапливаются и объединяются в центральном офисе. Аналогичным образом, можно реплицировать данные в удаленные офисы.
Объединение разнородных данных Некоторые приложения зависят от данных, посылаемых из баз данных или в базы данных, отличные от SQL Server. Используйте репликацию для объединения данных из
баз данных, отличных от SQL Server.
Разгрузка пакетной обработки Пакетные операции часто бывают слишком ресурсоемкими для выполнения на сервере OLTP. Используйте репликацию для переноса обработки на выделенный сервер пакетной обработки. В настоящее время используется технология Web-сервисов, которая представляется как удобное средство интеграции приложений, позволяющее легко реализовать межплатформенное взаимодействие. Сервисы представляют собой объекты, находящиеся в определенном отношениях и обладающие вложенной в них функциональностью. Любой Web-сервис можно рассматривать как черный ящик, имеющий входной и выходной порты. Но технология Web-сервисов не может рассматриваться как общий подход к интеграции приложений по нескольким причинам: Web-сервисы непригодны для обработки больших объемов данных; в них отсутствуют средства поддержки транзакций; в момент взаимодействия интегрированные системы должны находиться в работоспособном состоянии. Непригодность для обработки больших объемов информации связано с тем, что все данные преобразуются в формат XML, что ведет к увеличению объема данных и нагрузки на систему в целом. Web-сервисы начинают «захлебываться», когда за одно взаимодействие нужно передать сотню килобайт. Существует стандарт, WS-Transaction, который должен решить данную проблему, но пока полноценной его реализации отсутствуют. Так, например, WS-Transaction поддерживается IBM в своих продуктах, основанных на WebSphere Application Server, но с наложением массы ограничений, основным из которых как раз является необходимость работы под управлением WebSphere Application Server. То же самое можно сказать и про .Net 3.0 от Microsoft. Что же касается необходимости работоспособности взаимодействующих приложений, то можно сказать, что изначально удаленные вызовы были придуманы не для интеграции приложений, а для реализации распределенных систем, когда компоненты одной системы работают на разных машинах.
Очень распространенной является архитектура, ориентированная на сервисы (Service Oriented Architecture, SOA). Сервис-ориентированная архитектура (Service-Oriented Architecture или SOA) -подход к проектированию, развертыванию и эксплуатации распределенных программных систем. Система, реализованная по принципам SOA, представляет собой совокупность программных компонентов, а именно сервисов, имеющих стандартные интерфейсы для доступа к ним посредством сети и использования этих компонентов. Интерфейсы в SOA независимы от платформ развертывания сервисов и технологий их реализации. Интерфейс - это ключевое понятие сервиса. С помощью них выполняется представление возможностей сервиса внешнему миру и организация взаимодействия сервисов. SOA предлагает единую схему взаимодействия сервисов, независящую от того, где находится сервис. В качестве сервиса может целое приложение, так и отдельный его модель. Предполагается, что сервис выполняет какое-либо бизнес-действие (business concept), какую-то отдельную функцию. Завершив свою работу, сервис мо-
жет вызвать другой сервис. В сервисной архитектуре нет жестких связей между модулями. Их заменяют, так называемой, слабой связностью компонентов (loose coupling). Используя такую связь можно на ходу собирать из сервисов такую конфигурацию, которая необходима в данный момент. Так же наряду с обычными данными при обращении к сервису вызывающий модуль, который знает, как его вызвать и какую работу он выполняет, передает метаданные. Используя совокупность данных и метаданных, сервис выполняет заказ на обслуживание [9]. SOA - это не какие-то отдельные продукты, а технология построения информационных систем, которые представляют из себя сервисы, доступные для наружного использования. И так, SOA базируется на следующих принципах:
слабая связность компонентов, которая позволяет выполнять изменение внутри сервиса, не затрагивая программные модули использующие его;
«Крупнозернистая» (coarse-grained) структура сервисов, которая обеспечивает, благодаря тому, сервисы - модули бизнес-логики высокого уровня, не нуждающиеся в наличии множества низкоуровневых вызовов, учитывающих архитектуру сервисов, снизить нагрузку на сеть и повысить производительность;
Стандартные интерфейсы (standards-based). Благодаря нейтральности по отношению к используемой аппаратной платформе, обеспечивается универсальность взаимодействия сервисов в разнородной среде и снижение затрат на интеграцию.
Simple Object Access Protocol (SOAP) — для обмена данными.
Технология SOA активно используется при реализации интеграции данных в банковских системах.
Интеграционные сервера представляют собой промежуточные серверы в интеграционной среде, шлюзы, осуществляющие обработку потоков данных и сообщений, а также распределение данных между приложениями, имеющими различные интерфейсы. В ядре интеграционного сервера должны храниться бизнес-правила, на основе которых, а также полученных данных, выполняются вычислительные операции, анализ и принятие решений. Использование брокеров позволяет вынести правила интеграции из кода конкретных систем в отдельные бизнес-правила, что упрощает изменение этих правил, ведет к их открытости и применению ко всем взаимодействующим системам. Также на брокеры возлагаются функции адресации и преобразования данных.
Примером программного обеспечения, реализованного в соответствии с технологией серверов, может служить IBM WebSphere Message Broker.
Способы представления данных для интеграции
Однако проблему интеграции данных можно рассматривать немного по другим углом. Можно выделить два подхода к представлению данных: синтаксический и семантический. Большинство современных решений интеграции основаны именно на синтаксическом представлении данных. При таком подходе разработчик основывается на внешнем сходстве данных. Семантическое же представление основано на содержательной схожести.
Как бы ни были совершенны с технической точки зрения реляционные и функциональные подходы к консолидации данных, по своей сути они примитивны. Все они имеют в основе традиционное инженерное мировоззрение, сложившееся на протяжении всех лет существования ИТ.
Их общая слабость в том, что данные рассматриваются как наборы битов и байтов, а их семантика никоим образом не учитывается. Более того, нет даже внятного определения, что такое данные, а есть лишь аморфные высказывания вроде «данные - это представление фактов и идей в формализованном виде, пригодном для передачи и обработки в некотором информационном процессе» или «данные - это то, что находится на нижнем уровне в иерархии данные - информация - знание». [1]
Первые серьезные попытки изменить существующее положение были связаны с созданием в 80-е годы систем, состоящих из множества баз данных, за ними последовали СУБД с агентами, выступающими в качестве «посредников при доступе к данным» (mediators agent). Эти работы позволили понять, что причина сложности при интеграции данных, содержащихся в классических базах, кроется в жесткой связанности баз и единственности используемой в них схемы хранения. Эти работы остались на уровне академических или университетских исследований и к тому же не предложили решения проблемы интеграции гетерогенных данных, проблемы, которая обострилась в связи с широким распространением неструктурированных или квазиструктурированных данных.
Общая причина неудач заключается в том, что проблемы интеграции не являются чисто техническими
- совсем не сложно объединить различные реляционные базы, используя интерфейсы Open Database Connectivity (ODBC) или, например, Java Database Connectivity (JDBC), но сложнее интегрировать данные, поступающие из источников, имеющих разные модели или, что хуже, имеющих различную семантику, то есть интерпретирующих одни и те же данные по-разному. Для автоматизации работы с данными семантика должна быть явным образом выражена и включена в эти данные, т.е. данные должны содержать в себе описания собственной семантики. Здесь можно провести параллель с тем, как человек обобщает данные в своей повседневной жизни, основываясь на понимании окружающего мира, семантика которого уже в нем заключена.
Если такое удается реализовать, то возможен переход на следующий уровень интеграции, который можно назвать семантическим.[1]
Семантическая интеграция
Первые попытки создания систем с семантической интеграцией проводились еще в начале 90-х годов, однако семантические методы еще долго не выходили за рамки исследовательских проектов.
Семантическая интеграция - это скорее дополнение, а не замена стандартных методов, но это дополнение заполняет критичный пробел в обеспечении необходимой практичности данных и их взаимосвязи.
Применение семантических технологий - необходимое условие для построения успешной Сервис-Ориентированной Архитектуры предприятия (SOA). Без преимущества семантической интероперабельности данных и федеративных онтологий, развертываемая SOA-архитектура предприятия будет страдать от многих подводных камней, от которых страдают традиционные технологии EAI-интеграции: сложная и
дорогостоящая поддержка и предельно хрупкие правила трансформации данных при обмене, требующие переработки при изменении специфики данных. Применение Web-сервисов для «обёртывания» унаследованных систем не решает также проблем качества данных: поскольку, как правило, при вводе данных в такие системы не налагается необходимых проверок, могут наблюдаться ошибки дублирования и несоответствия данных.
В большинстве своем семантические модели строятся на основе одного из направлений в логике первого порядка, которые представляют собой семейство языков, позволяющих формально и однозначно описывать понятия в какой-либо предметной области. Каждый класс («концепт») может быть соотнесен с другим подобным ему концептом путем добавления тэгов метаданных, указывающих на свойства, общие черты, различия и т.д. Расширение моделей тэгами позволяет создавать такие структуры, которых раньше не могло быть. Благодаря тому что данные представляются в виде графов, происходит упроще-
ние их изменений. Так например, слияние двух моделей сводится к объединению их графов. Информационная единица может быть представлена идентификатором Uniform Resource Identifier (URI), посредством которого могут быть установлены отношения между двумя или большим числом информационных единиц. Семантические модели, они же онтологии, могут быть написаны с использованием Resource Description Framework (RDF) модели для представления данных, разработанной W3C на языке Web Ontology Language (OWL). [1]
Описать представление модели можно представить следующим образом.На нижнем, атомарном уровне представления данных располагается словарь, на следующем уровне распологаются таксономии, представляющие собой аналог схемы. Каждый элемент контента должен представлять свою принадлежность к определенной таксономии. Следующий уровень - онтология (словаоь и таксономия), представляет собой структуру, выражающую одновременно иерархию и набор отношений между элементами словника в этой иерархии. Семантическое множество объединяет онтологии, таксономии и глоссарии, входящие в состав корпоративной системы.
В последние несколько лет появился ряд специфических стандартов и средств для поддержания семантической интеграции. Однако одно из важных достижений это возможность создания семантической абстрактной модели. Это обеспечивает ряд преимуществ, которые ранее не были доступны:
- возможность абстрагировать управление и поддержание системы под нашим контролем в автоматизированном режиме;
- возможность ссылаться на различные бизнес-процессы через то же самый абстрактный уровень управления.
Подводя итог можно выделить следующие преимущества семантического подхода к интеграции: структура данных ориентирована на отношения между единицами данных вне зависимости от схожести формы их представления;
данные связываются на основе определения в общих онтологиях;
меньшая привязка системы к стандартам обмена, вследствие чего увеличивается масштабируемость. Уже сегодня на рынке имеется ряд продуктов, в которых, пусть и частично, реализованы методы семантической интеграции.
Пример продуктов современного рынка ПО для реализации семантической интеграции
Раньше других компания Progress Software выпустила семантический интегратор DataXtend Semantic Integrator. Progress® . Он предоставляет единую модель данных, делающую возможной семантическую интеграцию данных различных информационных структур. Поэтому если представление о некоторой структуре данных какой-либо системы или разработчика конфликтует с представлением в другой структуре, DataXtend SI будет проверять обмен данными между системами, стремясь к бизнес-целостности данных. Он решает задачи интеграции корпоративных данных, обеспечивая допустимость данных на основе бизнес-правил для пользователей и приложений, которым требуются эти данные. Использование решения семантической интеграции данных DataXtend позволяет предприятию ограничиться для приложений только слабо связанными интерфейсами и обеспечивает слабую связанность на семантическом уровне. [2]
Семантический сервер (Semantics Server) компании Алтимета позволяет улучшить интеграцию сложных данных и оптимизировать доступ к ключевой информации в масштабе всей организации. Он позволяет в реальном времени превратить разрозненные данные организации в полноценную бизнес-информацию, пригодную для принятия эффективных решений. Семантический сервер может использоваться совместно с Интеграционным сервером этой же компании, что позволяет обеспечить тотальную интеграцию данных и приложений в масштабе всей организации. Он обеспечивает интеграцию приложений с использованием архитектуры SOA и подхода интеграционных процессов (BPEL, BPMN). Этот традиционный подход, используемый всеми крупнейшими поставщиками интеграционных решений.
Семантический сервер применяет семантические стандарты к SOA-архитектуре. Он позволяет: консолидировать не только справочники и классификаторы, а вообще всю информацию, которую необходимо совместно использовать интегрируемым системам
объединить, интегрировать информацию и гарантировать качество данных обеспечить получение информации из слабоструктурированных источников производить автоматическую классификацию данных и логический вывод.
Выводы
На сегодняшний информационные системы активно развиваются, и объем обрабатываемых данных возрастает экспоненциально, также меняется и форма их представления. Объединение данных от всех используемых на предприятии ИС бывает достаточно сложно, а изменение таких систем может быть достаточно дорогостоящим.
Существующим техникам интеграции данных для полноценного решения это задачи недостаёт как масштабируемости, так и функционального охвата. Эти подходы в основном концентрируются на простом перемещении данных из одной системы в другую и применении трансформации и агрегации к элементам данных.
Решить эту проблему поможет использование методов семантической интеграции. На сегодняшний день это активно развивающаяся и перспективная область исследований.
ЛИТЕРАТУРА
1. Черняк Л. Интеграция данных: синтаксис и семантика. Открытые системы 2009 №10.
2. Lahanas S. Semantic Integration. Information Management Magazine, June 2008.
3. Добровольский А. Интеграция приложений: методы взаимодействия, топология, инструменты. Открытые системы 200 6 №9.
4. Дубова Н. Интеграция приложений и бизнес-процессы. Открытые системы 2006. №9.
5. Прокофьева И.В., Шибанов С.В., Шевченко О.А. Модель метаданных и программные средства обмена в системе электронных платежей. Научно-технические ведомости СПбГПУ, №1, 2008.
6. Леонид Черняк, Сервисы и сложные системы. Открытые системы 2007, №10.
7. Крупский В. Интеграция приложений на основе концепции Service Oriented Architecture (SOA).
Connect №6, 2008.
8. Леонид Черняк, EDA как очередная инкарнация SOA. Открытые системы 2006, №9.
