Интеграция разнородных инженерных систем на основе шины и архитектуры SOA в рамках обновленной платформы MULTI-D

Валерий Широков, инженер, АО «ИК АСЭ»

Александр Шаманин, главный специалист, АО «ИК АСЭ»

В статье рассматривается способ интеграции корпоративных систем в концепции сервис-ориентированной архитектуры с применением единого хранилища данных в рамках новой платформы MULTI-D в АО «ИК АСЭ». Рассматриваются преимущества, которые дает использование сервисно-ориентированной архитектуры для интеграции программ. Приводятся замечания к действующей архитектуре и преимущества создаваемой системы.

Проектирование интеграционного решения с использованием сервисно­ориентированной архитектуры

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

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

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

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

Применительно к специфике задачи построения единой интеграционной шины, обеспечивающей взаимодействие инженерных систем, следует определить основные проблемы, которые потребуется разрешить [1]:

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

Задача интеграции разнородных инженерных проектных систем обычно возникает в следующих типовых случаях:

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

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

1. Наиболее простым способом интеграции является асинхронная выгрузка/загрузка данных, выполняемая в ручном или полуавтоматическом режиме. При этом совместимость достигается путем использования одного из распространенных форматов хранения данных (XML, как наиболее современный вариант). Реализация процедуры требует полного понимания структуры и семантики хранимых данных в интегрируемых системах.
2. Более глубокая степень интеграции достигается в случае реализации процедур обновления данных в одной системе по запросу из другой системы. При таком варианте исполнения помимо работы с данными требуется реализация прикладного API сетевого удаленного доступа с применением технологий CGI, RPC, CORBA, SOAP и др., а взаимодействие систем называется клиент­серверным и может быть симметричным или асимметричным.
3. Гораздо более сложным в осуществлении является вариант с использованием промежуточного (связующего) программного обеспечения (middleware) [1].

Наиболее существенный недостаток первых двух способов интеграции — ограничение на количество взаимодействующих конечных систем. С его увеличением число реализуемых интеграционных процедур будет расти в геометрической прогрессии. На практике подобные процедуры обычно выполняются не более чем для пары взаимодействующих систем. В других случаях уместно использование архитектуры сервисной шины.

На рынке программного обеспечения с функцией service bus в настоящее время существует множество программ, из них самыми известными являются Oracle Service Bus и IBM WebSphere Enterprise Service Bus. Важным фактом является то, что данное ПО относится к проприетарному и его предлагают зарубежные вендоры. После введения санкций необходимость перехода к использованию OpenSource­решений почувствовали многие компании и органы государственной власти. Правительство РФ установило запрет на госзакупки иностранного ПО, который действует с 1 января 2016 года. В соответствии с ним заказчики обязаны закупать российское программное обеспечение, за исключением случаев, когда ПО с необходимыми эксплуатационными, функциональными или техническими характеристиками в России отсутствует. Подсчеты аналитиков говорят, что в России расходы компаний на проприетарное ПО таких мировых гигантов, как SAP, IBM, Oracle, Microsoft, в среднем в пять­шесть раз превышают траты на аналогичные конкурентные и качественные решения свободного программного обеспечения. Так, по итогам 2014 года на решения SAP госструктуры потратили 5,6 млрд руб. [2].

Архитектура сервисной шины (service bus) предполагает рассмотрение процессов интеграции с точки зрения межсервисного взаимодействия (SOA), передачи сообщений или обработки событий. При этом определяется архитектурный шаблон интеграционного решения, тип взаимодействия, эксплуатационные и другие аспекты [3]. К архитектурным шаблонам интеграции в концепции SOA относятся следующие [3]:

1.  Поддержка сервис­фасада — решает проблему доступа к конечным системам, не имеющим вид сервиса, посредством сервис­ориентированного интерфейса. Для API унаследованных систем должен быть реализован соответствующий адаптер сервиса. Возможна и реализация обратной задачи — организация точки входа для приложений, которые не могут использовать SOA.
2.  Виртуализация сервиса — способ взаимодействия между сервисами с помощью дополнительных уровней абстракции, то есть сервис представлен в виде виртуального сервиса с расширением функционала. Он может быть использован для селекции запросов между различными сервис­провайдерами.
3.  Шлюз — осуществляет необходимые согласования запросов на границе взаимодействия сервисов, не затрагивая при этом прикладной (верхний) уровень сообщений. При помощи шаблонов типа «шлюз» решаются задачи построения единой системы безопасности, преобразования различных протоколов SOA (например, SOAP и XML RPC или REST), а также журнализации и аудита.
4.  Интегрирующий сервис­фасад — включает интеграционную логику для использования нескольких сервисов из различных конечных или унаследованных систем для создания бизнес­логики более высокого уровня. Представляет интерес как основа для интеграции систем на основе общей семантики данных.

Задачу интеграции конечных информационных систем будем рассматривать исходя из следующих основных ограничений:

• интегрируемые системы являются полностью разнородными, то есть могут быть реализованы на разных платформах и иметь принципиально различную архитектуру [4];
• внутренняя организация данных конечных систем скрыта с точки зрения промежуточной системы, а используемая в конечных системах модель данных не обязательно является реляционной;
• конечные информационные системы не имеют общей системы безопасности;
• способом взаимодействия с конечными системами является сервис­ориентированный «фасад». При его отсутствии он должен быть реализован в виде специальных адаптеров [5].

Платформа Multi­D сегодня

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

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

Цель настоящего исследования — применение сервис­ориентированной архитектуры к построению единой шины для обновленной платформы MULTI­D для связи проектных систем в области электроэнергетики с использованием онтологии.

SOA в Multi­D

Опираясь на представленные исходные положения и ограничения, предлагается концептуальная архитектура интеграционной платформы Multi­D, представленная на рисунке.

Описываемая концепция построения интеграционной платформы Multi­D основывается на следующих исходных положениях:

1. Обрабатываемая интеграционной платформой информация, равно как и все результаты ее работы, располагаются в едином хранилище данных (ЕХД).
2. ЕХД представляет собой географически распределенное централизованное хранилище информации, позволяющее:
   • хранить большие (Big Data) объемы данных (тысячи терабайт — десятки петабайт);
   • предоставлять доступ к хранимой информации (выборка данных) с приемлемыми задержками;
   • обеспечивать приоритет доступа к информации в соответствии с частотой обращения к данным («горячие», «теплые» и «холодные» данные).
3. Источниками обрабатываемой интеграционной платформой информации являются любые внешние, по отношению к ней, информационные системы, выгружающие обозначенные данные в ЕХД.
4. Графический интерфейс пользователя должен представлять собой единый web­интерфейс визуализации данных.
5. Все используемые при разработке интеграционной платформы библиотеки, каркасы разработки и программные компоненты должны распространяться по лицензиям программного обеспечения с открытым исходным кодом.

Ядром интеграционной платформы Multi­D является совокупность двух технических решений: интеграционная шина и единое хранилище данных. На первое возлагаются задачи по передаче данных в ЕХД и их приведению к общему формату хранения (нормализация информации). На второе — хранение, обработка и выдача поступивших данных в соответствии с назначенной политикой безопасности.

Основой интеграционной шины можно выбрать OSS Apache ServiceMix. Указанное ПО — это пакет композитных приложений, который базируется на концепции корпоративной сервисной шины (ESB) и связывает сервис­ориентированную архитектуру и событийно­ориентированную архитектуру. В него входят:

• Apache ActiveMQ — промежуточное программное обеспечение, основной задачей которого является преобразование сообщения из протокола системы­отправителя в протокол системы­получателя;
• Apache Camel — программный каркас разработки интеграции приложений;
• Apache CXF — программный каркас разработки и обеспечения web­сервисов.

Задача приведения данных, поступающих на вход интеграционной шины, к обобщенному (нормализованному) виду хранения информации в ЕХД посредством выполнения соответствующих трансформаций ETL будет возложена на приложение OSGi, развернутое в рамках модульной среды исполнения приложений OSGi Apache Karaf, также входящей в состав OSS Apache ServiceMix [6].

Концептуальная архитектура интеграционной платформы Multi-D

Системообразующим элементом ЕХД выбрана OSS NoSQL СУБД Apache Cassandra. Это распределенная СУБД класса NoSQL, рассчитанная на создание высоко масштабируемых и надежных хранилищ огромных массивов данных.

Общая концепция интеграции заключается в том, что промежуточная система, построенная по архитектуре сервисной шины, предоставляет клиенту набор возможных сценариев взаимодействия, таких, например, как:

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

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

Заключение

По мнению авторов, воплощение данной концепции архитектуры с использованием свободно распространяемого программного обеспечения позволит:

• создать единое понимание целевого состояния взаимодействия данных;
• упростить доступ участников проектов к необходимой им информации ввиду разграничения доступа;
• управлять знаниями, типовыми решениями, несоответствиями, а также отслеживать версионность знаний об объектах онтологии [7].

Кроме того, авторы считают, что наиболее продуктивным подходом к интеграции разнородных систем является сочетание архитектуры сервисной шины и интеграционной логики на основе семантической сети (онтологии). Постройку онтологии для унификации данных предлагается вести на основании стандарта ISO 15926 [8], использование которого позволяет как объединить потоки, так и создать единую модель данных не только в корпоративных, но и в инженерных программных комплексах от разных поставщиков.

Процесс взаимодействия строится следующим образом: онтология не хранит данные предметной области, а извлекает необходимые данные из ЕХД конечных систем в соответствии с архитектурным шаблоном «интегрирующий сервис­фасад» для выполнения операций логического вывода [9].

Как показывает опыт создания сервисных шин, отсутствие семантических связей между различными сервисами не позволяет полноценно вести обмен данными между конечными системами, а существующая «плоская» система каталогизации с использованием примитивных фильтров не обеспечивает эффективного поиска необходимого сервиса. Несмотря на большой объем фактически хранимых данных, использование их для аналитических целей и построения сложных сервис­фасадов затруднено [10].

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

Список использованной литературы:

1. Касаткин А. Средства middleware и их классификация. PC Week // 1999. № 19 (193).
2. Гореткина Е.Д. СПО в России — от Москвы до самых до окраин, электронный ресурс [Электронный ресурс] // PC Week/RE № 7 URL https://www.itweek.ru/foss/article/detail.php?ID=184736.
3. Уайли Х., Ламброс П. Шаблоны взаимодействия приложений в корпоративных системах: Интеграционные решения с использованием продуктов IBM Enterprise Service Bus. 2010.
4. Mark Richards. The Role of the Enterprise Service Bus. No Fluff Just Stuff Symposium // InfoQ. 2006.
5. Binildas C.A. Service Oriented Java Business Integration. Birmingham­Mumbai: Packt Publishing, 2008. 414 с.
6. Divid Salter, Frank Jennings. Building SOA Based Composite Applications Using NetBeans.
7. IDE 6. Birmingham: Packt Publishing, 2008. 288 с. Guarino N., Oberle D., Staab S. Handbook on ontologies: What Is an Ontology?/ S. Staab, R. Studer // Springer. 2009. P. 2­3.
8. ГОСТ Р ИСО 15926­2­2010 Системы промышленной автоматизации и интеграция. Интеграция данных жизненного цикла для перерабатывающих предприятий, включая нефтяные и газовые производственные предприятия.
9. Горшков С. Технологии Semantic Web для интеграции информационных систем. 2013.
10. Бахтизин В.В., Бородаенко Ю.В. Модели интеграционных решений на предприятии и их надежность // Доклады Белорусского государственного университета информатики и радиоэлектроники. 2007.