CC BY
1393
Прокофьева И.В. , Шибанов С.В. , Шажков Б.Д. АНАЛИЗ ПРИМЕНЕНИЯ СОВРЕМЕННЫХ ТЕХНОЛОГИЙ ИНТЕГРАЦИИ ДАННЫХ В РАЗНОРОДНЫХ РАСПРЕДЕЛЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМАХ
Введение. В настоящее время трудно найти и даже представить предприятие, обходящееся без средств автоматизации своей деятельности. Из рабочего процесса давно уже невозможно вычленить автоматизированные системы, которые постоянно совершенствуются, видоизменяются и модернизируются. Автоматизация деятельности предприятия позволяет повысить эффективность его работы, обеспечить прозрачных финансовых операций, применять лучшие мировые бизнес-практики. Существуют две основных стратегии автоматизации предприятий - революционная и эволюционная.
Революционная стратегия предполагает внедрение единой многофункциональной системы, способной охватить все бизнес-процессы предприятия. В случае эволюционной стратегии применяются методы интеграции к имеющимся на предприятии программным средствам. При этом каждая существующая на предприятии система автоматизации дорабатывается таким образом, чтобы была обеспечена максимально большая интеграция с другими программными средствами.
Можно выделить два типа интеграции приложений разнородных информационных систем (ИС): интеграция приложений внутри одного предприятия (Enterprise Application Integration, EAI); интеграция приложений между предприятиями (Business-to-Business Integration, B2BI).
Во втором случае возрастает роль стандартов и открытых систем. Как правило, интеграцию осуществляют на основе промышленной платформы, а необходимые интерфейсы к приложениям существующих информационных систем разрабатываются дополнительно [10].
Современные подходы к интеграции данных. Существует три основных подхода [13] к интеграции данных и информации в разнородных распределенных информационных системах (РРИС):
консолидация данных с применением метода «выгрузка-преобразование-загрузка» - ETL (Extract-Transform-Load);
интеграция данных в реальном времени с использованием федеративных запросов - EII (Enterprise Information Integration);
синхронизация разнородных данных с помощью промежуточного программного обеспечения (ПО) - MOM (Message-Oriented Middleware).
При использовании ETL исходные данные извлекаются из различных источников, полученные данные преобразовываются в соответствие с целевым форматом, переработанные данные загружаются в целевое хранилище данных. Инициализация процесса ETL начинается с работы программы, производящей извлечение данных из исходного хранилища данных. В качестве таких программ можно использовать как собственные разработки, так и готовые специализированные средства ETL или сочетать оба этих варианта. В реальности чаще всего используется последний вариант, где применяются программные средства, написанные сторонними разработчиками и программы, реализующие специфический функционал для данного окружения. По окончанию извлечения данных, процедуры преобразования данных выполняют их подготовку к загрузке в целевом хранилище данных. На этапе преобразования могут выполняться такие операции, как объединение, перевод значений, создание полей и фильтрация. Наконец после завершения всех преобразований выполняется загрузка данных в целевую базу данных. Загрузка данных может выполняться периодически или постоянно. В первом случае данная операция выполняется с определенной периодичностью (ежемесячно, ежеквартально, ежедневно). Постоянная загрузка осуществляет оперативное предоставление данных в целевую базу данных. Чаще всего средства ETL поддерживают оба способа загрузки, а наиболее современные позволяют загружать только изменившиеся данные. Также средства загрузки разделяют по следующим методам тиражирования: push-тиражирование - выполняется «проталкивание» данных из исходного в целевое приложение; pull-тиражирование - «вытаскиваются» данные целевым приложением по мере необходимости [6]. Метод ETL целесообразно применять, если накоплено большое количество информации за время существования организации, а также существует множество хранилищ данных. Помимо этого метод интеграции ETL также применяется при необходимости проверки данных, их корректировки, для интеграции разнообразных справочных данных [7].
Применение EII (Enterprise Information Integration) или федерализация позволяет осуществлять интеграцию в режиме реального времени в момент поступления запроса от пользователя. Метод интеграции EII позволяет представлять множество источников данных в качестве единого виртуального хранилища. Реально же данные могут располагаться в базах данных, хранилищах, созданных с помощью метода ETL, файлах, приложениях. В то время, когда пользователь формирует запрос к виртуальному хранилищу, с помощью инструментов федерализации, осуществляется извлечение данных из источника, их интеграция в соответствие с правилами, определенными заранее и отправка результата инициатору запроса. Преобразования данных выполняется, как правило, в оперативной памяти сервера в момент их извлечения из источника. Этот метод позволяет реализовать принцип автономности подразделений компании и осуществлять единый контроль путем разграничения прав доступа. Плюсом EII является возможность расширения количества источников данных, изменения правил запросов в режиме реального времени. Данный метод интеграции может применять при оперативном составлении запросов и формировании отчетности. Так же EII очень удобен, если из-за соблюдения мер безопасности, данные запрещено перемещать и копировать из операционной базы данных. Методология федерализации может использоваться на первом этапе интеграции, например для двух объединяющихся компаний, т.к. обеспечивает идеальную интеграцию. EII целесообразно применять, когда затраты на внедрение ETL превышают получаемые от нее выгоды. EII ориентирована на обработку относительно «легких» запросов, которые необходимо обработать немедленно, в то время, как ETL предназначена для обработки «тяжелых» агрегированных данных [7].
Подход к интеграции MOM предоставляет обеспечение гарантированной синхронной или асинхронной передачи сообщений между слабосвязанными приложениями, выполняемыми в территориально распределенной неоднородной среде. При этом поддерживается управление вычислительным процессом по событиям с обработкой очередей и подпиской/рассылкой сообщений. Синхронизация стала обычным способом связывания операционных задач. В распределенных транзакционных системах, например, с участием защищенного обмена данными получили распространение асинхронные коммуникации на базе MOM и механизмы обработки, управляемой по событиям, поскольку нужно, чтобы участники транзакций (и программы, и люди) оперативно реагировали на изменение информации. [13].
Современные технологии и модели интеграции данных. Интеграция данных является одним из основных инструментов обеспечения функционирования корпоративных систем. Выбор одной технологии, методологического подхода и инструментальных средств, которые позволят успешно решать все интеграционные потребности сложной информационной системы, является непростой задачей. В настоящее время существует множество технологий и моделей интеграции данных. Наиболее востребованными в настоящее время, на наш взгляд, являются следующие технологии:
технология обмена файлами данных;
модель сервер-сервер с применением шлюзов баз данных; технология web-сервисов;
сервис-ориентированная архитектура (Service-Oriented Architecture, SOA); архитектура, управляемая событиями (Event Driven Architecture, EDA); технология интеграционных брокеров;
архитектура на основе шины (Enterprise Service Bus - ESB).
Обзор технологий и моделей интеграции, выделение их достоинств и недостатков, преимуществ и ограничений применения позволят обоснованно выбрать подходящие средства интеграции данных в разнородных распределенных системах.
Технология обмена файлами. Обмен файлами - это наиболее распространенный способ обмена данными и взаимодействия приложений. Скорее всего, это связано с тем, что этот способ является наиболее интуитивно понятным и простым в реализации. Также сейчас существует набор стандартных форматов обмена. Например, CVS (Common Separated Values) - текстовый формат с полями, разделенными запятыми.
Данный способ интеграции данных в настоящее время очень широко распространен. Например, он активно применяется в таком классе программных продуктов, как системы дистанционного банковского обслуживания. Так компания BIFIT предлагает в качестве универсального шлюза для интеграции своего продукта iBank2 с любой автоматизированной банковской системой модуль ABS-txt, позволяющий организовать обмен с помощью текстовых файлов. Другая компания, также занимающаяся разработкой систем дистанционного банковского обслуживания, BSS, до недавнего времени предлагала в качестве средств интеграции со своей системой «Частный клиент» модуль обмена файлами заданного формата и только пол года назад смогла предложить интеграционных модуль, реализованный с применением технологии SOA. Такая популярность данного способа интеграции может объясняться тем, что, как правило, с одной или даже с обеих сторон, реализующих интегрируемые системы нет желания, а порой и возможности написания более технологичного решения.
Однако технология обмена файлами имеет ряд серьезных недостатков. В случае необходимости обмена сложными структурами, простые форматы становятся непригодными. В этом случае необходима разработка специализированных форматов файлов, что приводит к большой зависимости систем друг от друга. Обмен файлами часто подразумевает наличие человека, который непосредственно осуществляет выгрузку и загрузку файлов. Данный недостаток решаем путем организации задач, выполняемых по расписанию [1].
Модель сервер-сервер с применением шлюзов баз данных. Часто можно столкнуться с задачей интеграции двух или нескольких баз данных (БД), часть из которых являются базами данных унаследованных систем, другие - современные промышленные базы данных, например Oracle. В таком случае наиболее правильным решением будет использование шлюза, который позволит работать с унаследованной базой так, как будто это база Oracle. Здесь предполагается реализация технологии сервер-сервер, т.е. клиент обращается к серверу Oracle, а тот уже в свою очередь уже взаимодействует с серверами других баз данных. Для интеграции баз данных на уровне сервера необходимо:
определение некоторого компьютера, который будет играть роль интеграционного сервера баз данных;
единообразный доступ клиентов системы управления базами данных (СУБД) к интеграционному серверу;
применение шлюзов для доступа СУБД Oracle к другим базам данных.
Технология интеграции с применением шлюзов баз данных привлекательна своей простотой концептуального и архитектурного решений, а также высокой степенью надежности из-за четкого ограничения функциональности. Многие современные прикладные системы дают возможность работать с такими распределенными системами, как Oracle и Sybase, но они не могут взаимодействовать со старыми системами, такими, как TurboImage. Наилучшим выходом здесь является как раз использование шлюза БД. Совокупность продуктов, реализующих интеграцию на основе технологии шлюзов, можно разделить на следующие группы:
прозрачные шлюзы, обеспечивающие доступ к унаследованным базам данных, на основе использования языка запросов SQL, т.е. эти шлюзы позволяют осуществить доступ к «чужим» данным, таким же образом, как и к своим;
процедурные шлюзы осуществляют обработку вызовов удаленных процедур в унаследованной программной системе;
менеджеры доступа обеспечивают поддержку доступа «чужих» СУБД посредствам языка запросов SQL; службы репликаций позволяют выполнять репликации данных из «чужих» баз данных и обратно, используя прозрачные шлюзы.
Наибольший интерес из перечисленных компонентов представляют прозрачные шлюзы. Прозрачный шлюз - это некий «интеллектуальный программный канал», предоставляющий доступ к базам данных иных форматов, нежели основная база данных. Шлюзу не известен формат этих баз данных. Шлюз обращается к унаследованной СУБД, которая непосредственно и обеспечивает доступ к самой базе данных. Доступ может быть осуществлен, например, с помощью языка SQL, если это реляционная база данных Средства репликаций позволяют осуществить репликацию только измененных данных в целевую систему [2].
В качестве примера интеграции систем с использование шлюзов БД рассмотрим интеграцию двух центров данных существующих в банке. Один из этих центров представляет собой систему OLTP на базе компьютера IBM AS/400, на котором функционирует СУБД DB2/400. Основная часть актуальных данных банка находится в базах данных DB2/4 00 (версия СУБД DB2 производства IBM, реализованная на компьютерах AS/400). Второй центр обработки данных опирается на ПК-сервер под управлением ОС Windows NT с СУБД Microsoft SQL Server. Здесь использовались прозрачные шлюзы в качестве каналов для доставки данных из двух источников в хранилище данных, а также средства Replication Service for Data Propogator, чтобы реплицировать исключительно изменения в исходных таблицах целевой системы (DB2/MVS и DB2/400), а не содержимое таблиц целиком. Полученная конфигурация проекта изображена на рисунке 1 [2].
Рисунок 1 - Конфигурация проекта интеграции на основе прозрачных шлюзов
Технология Web-сервисов. В настоящее время прочно заняла свои позиции технология Web-сервисов, которая представляется как удобное средство интеграции приложений, позволяющее легко реализовать межплатформенное взаимодействие. Сервисы представляют собой объекты, находящиеся в определенных отношениях и обладающие вложенной в них функциональностью. Сервисы обладают тремя качествами:
потребительское свойство сервиса (service value) - представление сервиса с позиции потребителя;
сервис как предложение (service offering) - иерархическая система предложений сервисов в том виде, какой ее представляет поставщик;
сервис как процесс (service process) - описание того, как из сервиса можно выстроить некоторый процесс.
Любой Web-сервис можно рассматривать как черный ящик, имеющий входной и выходной порты. Сервисы обладают такими характеристиками, как тип, выполняемая функция, производительность, внутренние ресурсы, многократность использования и другие [9].
Но технология Web-сервисов не может рассматриваться как общий подход к интеграции приложений по нескольким причинам: Web-сервисы непригодны для обработки больших объемов данных; в них отсутствуют средства поддержки транзакций; в момент взаимодействия интегрированные системы должны находиться в работоспособном состоянии. Непригодность для обработки больших объемов информации связано с тем, что все данные преобразуются в формат XML, что ведет к увеличению объема данных и нагрузки на систему в целом. Web-сервисы начинают «захлебываться», когда за одно взаимодействие нужно передать сотню килобайт. В настоящее время существует стандарт WS-Attachments, который позволяет обойтись без преобразования в XML формат, но ведущие поставщики программного обеспечения этот стандарт не поддерживают.
В первоначальном варианте Web-сервисы не поддерживают механизм транзакций. Этот недостаток часто предлагают устранять с помощью выполнения компенсационных операций, но никто не гарантирует успех компенсационной операции, помимо этого есть системы не допускающие удаления данных, внесенных в базу. Существует стандарт, WS-Transaction, который должен решить данную проблему, но сейчас полноценной его реализации отсутствуют, те, что существуют сейчас, накладывают ограничения на выбор используемой платформы, подрывая тем самым основное преимущество Web-сервисов. Так, например, WS-Transaction поддерживается IBM в своих продуктах, основанных на WebSphere Application Server, но с наложением массы ограничений, основным из которых как раз является необходимость работы под управлением WebSphere Application Server. То же самое можно сказать и про .Net 3.0 от Microsoft. Что же касается необходимости работоспособности взаимодействующих приложений, то можно сказать, что изначально удаленные вызовы были придуманы не для интеграции приложений, а для реализации распределенных систем, когда компоненты одной системы работают на разных машинах [1].
Сервис-ориентированная архитектура (Service Oriented Architecture, SOA). Сервис-ориентированная архитектура - подход к проектированию, развертыванию и эксплуатации распределенных программных систем. Система, реализованная по принципам SOA, представляет собой совокупность программных компонентов, а именно сервисов, имеющих стандартные интерфейсы для доступа к ним посредством сети и использования этих компонентов. Интерфейсы в SOA независимы от платформ развертывания сервисов и технологий их реализации [12]. Интерфейс - это ключевое понятие сервиса. С помощью них выполняется представление возможностей сервиса внешнему миру и организация взаимодействия сервисов. SOA предлагает единую схему взаимодействия сервисов, независящую от того, где находится сервис. В качестве сервиса может целое приложение, так и отдельный его модель. На данном этапе своего развития SOA для организации своего функционирования использует базовые понятия Web-сервисов:
eXtensible Markup Language (XML) — для представления данных;
Web Services Definition Language (WSDL) — для описания доступных Web-сервисов;
Universal Description, Discovery, Integration (UDDI) — для создания каталога доступных по сети Web-сервисов;
Simple Object Access Protocol (SOAP) — для обмена данными.
Взаимодействие сервисов осуществляется по принципу «публикация-поиск-соединение» (рисунок 2) : приложение, предоставляющее определенный сервис (провайдер сервиса), размещает информацию о нем в каталоге сервисов.
Потребитель сервиса — приложение, которому необходима функциональность данного сервиса, находит информацию о нем в каталоге, для того чтобы установить соединение с этим сервисом и послать запрос. Для того чтобы использовать сервис, необходимо послать ему сообщение с контактной информацией, получив которое, как правило, он должен отправить подтверждение. Предполагается, что сервис выполняет какое-либо бизнес-действие (business concept), какую-то отдельную функцию. Завершив свою работу, сервис может вызвать другой сервис.
Рисунок 2 - Взаимодействие сервисов
В сервисной архитектуре нет жестких связей между модулями. Их заменяют, так называемой, слабой
связностью компонентов (loose coupling) . Используя такую связь можно на ходу собирать из сервисов такую конфигурацию, которая необходима в данный момент. Так же наряду с обычными данными при обращении к сервису вызывающий модуль, который знает, как его вызвать и какую работу он выполняет, передает метаданные. Используя совокупность данных и метаданных, сервис выполняет заказ на обслуживание [3].
SOA - это не какие-то отдельные продукты, а технология построения информационных систем, которые представляют из себя сервисы, доступные для наружного использования. И так, SOA базируется на следующих принципах:
слабая связность компонентов, которая позволяет выполнять изменение внутри сервиса, не затрагивая программные модули использующие его;
«крупнозернистая» (coarse-grained) структура сервисов, которая обеспечивает, благодаря тому, сервисы - модули бизнес-логики высокого уровня, не нуждающиеся в наличии множества низкоуровневых
вызовов, учитывающих архитектуру сервисов, снизить нагрузку на сеть и повысить производитель-
ность;
стандартные интерфейсы (standards-based). Благодаря нейтральности по отношению к используемой аппаратной платформе, обеспечивается универсальность взаимодействия сервисов в разнородной среде и снижение затрат на интеграцию.
simple Object Access Protocol (SOAP) — для обмена данными.
В зародышевой форме архитектура SOA существовала с начала 90-х годов. Это технологии CORBA (Common Object Request Broker Architecture) и DCOM (Distributed Component Object Model). Внешне они действительно похожи на SOA, но если их рассмотреть более детально, то можно увидеть, что в этих ранних подходах к сервисной ориентации программных систем не выполняются или выполняются с определенными ограничениями базовые принципы SOA. Так, в CORBA и DCOM взаимодействующие объекты являются сильносвязанными, и внесение изменений в реализацию программных компонентов. Запросы к объектам (сервисам) в этих архитектурах, как правило, содержат небольшой объем информации, учитывающей специфику реализации сервисов («мелкозернистая» — fine-grained — структура сервисов), и потому порождают значительный сетевой трафик между поставщиком и потребителем сервиса. В DCOM взаимодействие программных компонентов основано на закрытых интерфейсах Microsoft. CORBA хотя и не принадлежит частной компании, однако реализация спецификаций CORBA сильно варьируются в продуктах разных производителей, что ограничивает интероперабельность систем на ее базе [11]. Сейчас, с появление SOA, по сути, для пользователя ничего не изменилось и не изменится, пока ведущие производители программного обеспечения не модифицируют свои продукты, которые в настоящий момент являются замкнутыми системами, в соответствие с концепциями SOA [3].
Архитектура, управляемая событиями (Event Driven Architecture, EDA). Следующий шаг в развитии сервис-ориентированной архитектуры - архитектура, управляемая событиями (Event Driven Architecture, EDA), способная адаптироваться к потокам работ в бизнес-процессах. Здесь процессы могут выполняться как синхронно, так и асинхронно. Данная архитектура является перепрограммируемой, причем перепрограммирование выполняется при возникновении изменений в бизнес-процессах. Также система, реализованная на основе EDA, способна воспринимать события из внешней среды. Сообщения о событиях, поступающие в систему, распространяются по подписчикам (subscriber, автомат или человек). Сообщение состоит из двух частей: заголовок, в котором содержатся метаданные (идентификатор спецификации события, тип события, имя события, отметка времени и источник); тело, описывающее то, что произошло. Получив сообщение о возникновении события, подписчики тем или иным образом реагируют на него: это может быть дальнейшая пересылка сообщения, вызов какого-либо сервиса и
т.д. EDA - это распределенная и очень слабосвязанная архитектура (extreme loose coupling). Источник сообщения знает только, что сообщение передано, но не отслеживает его дальнейшую судьбу. В связи с этим в EDA применяются асинхронные потоки данных и работ. Архитектуры EDA разделяют по способам обработки событий:
простая обработка событий, в этом случае выполняется прямая передача событий из входного потока в процессор обработки событий;
потоковая обработка событий, простые события передаются сначала в генератор, где путем обработки формируются значимые события, отправляемые в процессор событий;
обработка сложных событий, в этом случае простые события неоднородны и выполняется фильтрация, а также различные статистические методы.
Если система построена на основе технологии EDA, то она должна включать следующие четыре компонента (подробная компонентная схема EDA изображена на рисунке 3):
генератор событий (event generator) выполняет первичную обработку и выделение значимых событий;
канал событий (event channel) обеспечивает передачу событий из генератора в процессор; процессор событий (event processor) оценивает события, вырабатывая необходимые решения (такие как запуск сервисов), осуществляет рассылку подписчикам и архивирование событий; управление последующими событиями (downstream event-driven activity).
Средства
генерации
событий
Правила обработки событий Подробное описание событий Данные событий
Устройство обработки событий
Сервисные вызовы Канал Модуль
передачи событий кэширования информации
Средства
управления
событиями
Модуль основы интеграции предприятия
Рисунок 3 - Компонентная модель EDA
В ситуации, когда входное событие требует выполнения комплекса действий, предоставляет соответствующие средства управления [3]. Для архитектуры, управляемой событиями принято выделять следующие характеристики:
широковещательные сообщения, о возникновении события оповещаются одновременно все заинтересованные стороны;
своевременность, публикация событий происходит по мере их возникновения, а не по завершению какого-либо цикла обработки;
асинхронность, система, разославшая информацию о событии, не дожидается сообщений об их обработке;
«мелкозернистость» событий, сообщается о нескольких событиях, а не об одном более крупном, состоящем из более мелких;
онтология, выполняется классификация и построение иерархии событий, системы-получатели, обычно, ожидают только конкретных событий или событий определенного типа;
обработка сложных событий, осуществляется отслеживание связей между событиями, их агрегирование, а также причинно-следственные связи между ними [12].
Технология интеграционных брокеров. Интеграционные брокеры (или интеграционные серверы) представляют собой промежуточные серверы в интеграционной среде, шлюзы, осуществляющие обработку потоков данных и сообщений, а также распределение данных между приложениями, имеющими различные интерфейсы. В ядре брокера должны храниться бизнес-правила, на основе которых, а также полученных данных, выполняются вычислительные операции, анализ и принятие решений.
Использование брокеров позволяет вынести правила интеграции из кода конкретных систем в отдельные бизнес-правила, что упрощает изменение этих правил, ведет к их открытости и применению ко всем взаимодействующим системам. Также на брокеры возлагаются функции адресации и преобразования данных. Таким образом, получается некоторый коммутатор, гипермейнфрейм [7].
Примером программного обеспечения, реализованного в соответствии с технологией брокеров, может служить IBM WebSphere Message Broker.
Архитектура на основе шины (Enterprise Service Bus - ESB). Компания Sonic предложила создание некоего метакомпьютера для всего предприятия, информационную магистраль предприятия (Enterprise Service Bus - ESB), но гораздо более дешевого и компактного, чем интеграционные брокеры. Архитектура ESB стала новым подходом к организации основы средств интеграции. Архитектура Sonic ESB представлена на рисунке 4.
ESB и подключенные бизнес-сервисы
• ESB контейнер
Распределенная сервисная архитектура Мультипротокольный транспорт
• IP сеть
Рисунок 4 - Архитектура SonicESB
С использованием этой шины можно реализовать корпоративную магистраль, имеющую распределенную архитектуру, ориентированную на службы. ESB позволяет создавать контейнеры для размещения служб. Службы легко собираются и согласуются. Реальная физическая сеть может подвергаться изменениям, т.к. вся конструкция, размещенная в ней, является виртуальной. В процессе работы одна или несколько служб находятся в специальном контейнере (service container) . С помощью контейнеров службы продвигаются в соответствие с маршрутом сообщений. К поступившему на вход ESB сообщению добавляется информация о маршруте, который обеспечивает контентно-управляемое продвижение по распределенному процессу. По этому процессу сообщение проходит через несколько служб и достигает конечной точки, для указания которых могут использоваться не физический, а логические имена. Сервисная шина предприятия обеспечивает поддержку дополнительных методов взаимодействия между хабом и при-
ложениями, прежде всего поддержку протокола SOAP. ESB может быть использована для реализации идей EDA. Шина ESB выполняет функции промежуточного слоя между различными процессами, что делает возможным инициацию запуска сервисов, включенных в систему ее средствами, клиентами и событиями. К основным характеристикам и преимуществам ESB можно отнести следующие: магистраль промышленного
класса; поддержка распределенной архитектуры сервисов; представлены сервисы трансформации XML, позволяющие осуществить достаточно легкую интеграцию; среда управления, обеспечивающая безопасное управление, контроль и конфигурирование всех сервисов; интеллектуальная маршрутизация; поддержка web-сервисов; гибкая система безопасности. Сервисная шина предприятия может рассматриваться как некий архитектурный шаблон, который реализуется разнообразными программными продуктами такими, как Sonic ESB и IBM WebSphere ESB [5].
Интеграция данных в РРИС «Электронный платеж». Проблема реализации обмена данными для разнородных распределенных информационных систем возникла при разработке автоматизированной информационной системы «Электронный платеж», разрабатываемой в ОАО Губернский банк «Тарханы» (г. Пенза), и предназначенной для приема и учета коммунальных и иных платежей. В процессе функционирования ИС «Электронный платеж» постоянно взаимодействует с ИС поставщиков услуг и агентов по приему платежей, регулярно обмениваясь данными. Взаимодействие осуществляется через глобальную сеть Интернет.
Поставщиками услуг являются организации, предоставляющие физическим лицам различные услуги. Например, коммунальные службы, компании сотовой связи, интернет-провайдеры и т.д. Агентами по приему платежей являются организации, принимающие от физических лиц какие-либо наличные платежи за оказанные услуги. Например, федеральная почтовая служба, банки, торговые сети, такие как «Евросеть», и т.д. Как показала практика, поставщики услуг и агенты предлагают для организации обмена данными собственные протоколы, не соответствующие протоколу, определяемому системой «Электронный платеж». Это обусловлено, техническими, экономическими, юридическими и другими причинами.
Проблема интеграции в ИС «Электронный платеж» решалась с помощью простого обмена файлами. Основной причиной выбора именно этой технологии интеграции систем стала универсальность: практически любые решения на разнородных платформах могут быть взаимосвязаны с помощью файлового обмена. Данный способ достаточно прост в реализации, но взаимодействие с различными корпоративными системами вело к необходимости поддержки широкого ряда различных протоколов обмена, причем, даже если различные корпоративные системы поддерживали единый протокол, могли требоваться различные форматы самих файлов (формат файла, текстовый, xml или др. мог различаться). Все это вело к необходимости реализовать для каждой новой корпоративной системы, с которой требовалось осуществить интеграцию, программное обеспечение, позволяющее формировать файлы, соответствующие тому или иному протоколу взаимодействия. Требовалась постоянная доработка системы обмена данными при необходимости интегрироваться с новой информационной системой, что вело к высоким накладным расходом и увеличению сроков интеграции. В связи с вышесказанным было предложено следующее решение: разработана система соответствующей методологии ETL, осуществляющая работу с файлами, реализующими разнообразные протоколы обмена и в различных форматах.
Как и любая система, реализованная в соответствие с методологией ETL, система состоит из следующих модулей: модули экспорта, преобразования и импорта (рисунок 5).
Одним из звеньев описываемой системы является модуль преобразования формата файла. Его реализация выполняется с помощью стандартных средств, имеющихся во многих средах разработки программного обеспечения. Совокупность программных средств, реализующих преобразование данных в различные форматы, объединены в dll-библиотеку, к которой, в случае необходимости, выполняется обращение из программ разбора шаблонов протоколов [8].
Реализация модулей импорта и экспорта данных базируется на использовании метаданных. Метаданные просматриваются, создаются и редактируются пользователем с помощью программы настройки шаблонов протоколов, в которой можно выполнить определение метаданных, описывающих протоколы обмена данными. Описание протокола выполняется с помощью конструкций, задающих правила извлечения данных из БД, структуру файла протокола и правила проверки импортируемых данных [8].
Сервер БД
Рисунок 5 - Модель организации взаимодействия в разнородной распределенной информационной системе
Программные средства разбора шаблонов протоколов реализуют машинный анализ метаданных. Для определенного протокола здесь в соответствие с настройками, заданными шаблоном, выполняется генерация текстового файла, содержащего программный код, запуск которого приводит к созданию файла протокола. Полученная программа выполняет запрос параметров, определенных в шаблоне, осуществляет выбор данных, с помощью полученного запроса, создает файл протокола, структура которого также соответствует настройке, обращается, в случае необходимости, к модулю преобразования формата файла и отправляет итоговый файл по адресам из списка контактов [8].
Предложенная модель реализации программных средств, состоящая из трех компонентов (модуль импорта, модуль экспорта и модуль преобразования форматов файлов), может применяться не только для интеграции, основанной на организации файлового обмена, но и служить реализацией универсальных интеграционных брокеров системах, где взаимодействие основано на технологиях SOA и ESB.
Предлагаемая схема обмена данными в разнородной распределенной системе достаточно универсальна, но не лишена недостатков, например ограниченность набора целевых форматов файлов в модуле преобразования форматов. Так же, если модуль экспорта выполняет свою работу в соответствием с расписанием автоматических задач, имеющихся в системе, то модуль импорта запускается вручную. Данные проблемы необходимо решать, описанную систему можно развивать. А предложенный подход следует рассматривать как один из вариантов решения задач интеграции.
Литература
1. Алексей Добровольский. Интеграция приложений: методы взаимодействия, топология, инструменты // Открытые системы, 2006. № 9. с. 30-3 4.
2. Глеб Лодыженский. Шлюзы, как средства интеграции баз данных / / JetInfo. Информационный бюллетень, 1998. № 9-10 (64-65). с. 64-65.
3. Леонид Черняк. EDA как очередная инкарнация SOA // Открытые системы, 2006. № 9. с. 24-2 9.
4. Администрирование компьютерных сетей Интеграция приложений на основе WebSphere MQ. Интеграционный брокер и требования к его функциональности. // Адрес в Интернет: admin-
seti.ru/about/clause/2 98/67 9 68 6.
5. Леонид Черняк. Общая шина предприятия // Открытые системы, 2 0 03. № 4. с. 18-19.
6. Скотт Стейначер. ETL - ключ к готовности и корректности данных // Computerworld, 2001. № 4.
7. Дмитрий Ломакин. Вместе — надежнее // Директор ИС, 2 0 07. № 10.
8. Прокофьева И.В., Шибанов С.В., Шевченко О.А. Модель метаданных и программные средства обмена данными между разнородными информационными системами в системе электронных платежей // Научнотехнические ведомости СПбГПУ. СПб.: Изд-во СПбГПУ, 2008. № 1. с. 242-246.
9. Леонид Черняк. Сервисы и сложные системы // Открытые системы, 2 0 07. № 10. с. 28-33.
10. Евгений Авданин. Автоматизация холдингов. Начальный курс. // Директор ИС, 2008. № 2.
11. Наталья Дубова. На пути к SOA // Директор ИС, 2005. № 8.
12. Грегор Хоуп. Программирование без стека вызовов // Открытые системы, 200 6. № 10. с. 45-51.
13. Майк Фергюсон. Беспрепятственное течение данных // Intelligent Enterprise, 2006. № 18.
