Методы и программные средства интеграции приложений с использованием внешней шины тема диссертации и автореферата по ВАК РФ 05.13.11, кандидат наук Шумский, Леонид Дмитриевич

• Шумский, Леонид Дмитриевич
• кандидат наук
• 2015

Оглавление диссертации кандидат наук Шумский, Леонид Дмитриевич

Содержание

Введение

1 Анализ особенностей программных средств, используемых в интеграции приложений

1.1 Общая характеристика программных средств интеграции приложений

1.1.1 Общая формулировка задачи интеграции приложений

1.1.2 Особенности предметных областей, требующих интеграции приложений

1.2 Сравнительная оценка архитектур и интерфейсов существующих интеграционных шин

1.2.1 Постановка задачи интеграции систем и приложений с использованием интеграционной шины класса Ме$5а§е-Опеп1ес1-М1с1111е\\'аге

1.2.2 Сравнительный анализ существующих интеграционных шин

1.3 Сравнительный анализ применяемых моделей концептуализации предметных облаете

1.3.1 Постановка задачи концептуального моделирования, применительно к задачам интеграции

1.3.2 Концептуальные модели и их особенности

1.3.3 Общие категории объектов концептуального моделирования

1.4 Анализ методов моделирования информационных процессов для задач интеграции

1.5 Анализ информационных технологий и вычислительных моделей для обработки данных в предметно ориентированных системах

1.6 Постановка задачи проектирования и реализации внешней интеграционной шины

1.7 Выводы

2 Разработка модели данных, метаданных и процессов для интеграционной шины

2.1 Метод многоуровневого представления информации в интеграционной шине

2.1.1 Основные понятия

2.1.2 Уровни представления информации и связь между уровнями

2.2 Структуры объектов концептуальной модели, применительно к задачам интеграции

2.2.1 Апплнкативное представление категорий объектов концептуальной модели

2.2.2 Использование концептуальной модели предметной области в интеграционной шине

2.3 Структуры объектов контроля интеграционных процессов

2.3.1 Формулировка задачи контроля процесса

2.3.2 Апплнкативное представление объектов

2.4 Моделирование интеграционных процессов

2.4.1 Кодирование Х-исчисления в я-исчисление

2.4.2 Типизация процессов

2.4.3 Абстрактная машина выполнения процесса

2.4.4 Шаги интеграционного процесса

2.4.5 Каналы передачи и получения данных

2.5 Выводы

3 Проектирование программных средств интеграции приложений, скомпонованных в модульную

интеграционную шину

3.1 Требования к интеграционной шине

3.1.1 Общие замечания

3.1.2 Функциональные требования

3.1.3 Технические требования

3.2 Разработка архитектуры и внешних интерфейсов модульной интеграционной шины

3.2.1 Разработка расширяемой архитектуры модульной интеграционной шины

^шт

3.2.2 Проектирование архитектуры основных компонентов интеграционной шины

3.3 Проектирование основных компонентов интеграционной шины

3.3.1 Основные модули разрабатываемой интеграционной шины

3.3.2 Система управления доступом

3.4 Проектирование интерфейсов пользователя

3.5 Выводы

4 Результаты реализации, экспериментальной проверки и внедрения разработанной

интеграционной шины

4.1 Состав и структура программного обеспечения

4.2 Обобщенные сценарии пользователей интеграционной шины

4.3 Результаты внедрения и апробации разработанных подходов к реализации интеграционных сценариев

4.4 Результаты апробации и экспериментальной проверки основных компонентов разработанной модульной интеграционной шины

4.5 Сравнение экспериментально полученных результатов с требуемыми характеристиками

4.6 Основные этапы развития и модернизации компонентов модульной интеграционной шины .

4.7 Выводы

Заключение

Литература

Список использованных сокращений

Приложение 1. Акты о внедрении результатов диссертационного исследования

Приложение 2. REST сервисы взаимодействия с серверным компонентом шины

Приложение 3. Спецификация модуля создания и выполнения интеграционных процессов

Приложение 4. Код реализации химической абстрактной машины

Приложение 5. Запрос на создание таблиц БД серверного компонента шины

Приложение 6. Сериализованный объект процесса

Введение диссертации (часть автореферата) на тему «Методы и программные средства интеграции приложений с использованием внешней шины»

Введение

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

Актуальность темы исследований. В настоящее время в большинстве отраслей экономики существенно увеличивается число используемых на предприятиях готовых КИС и сторонних приложений [1,2]. Например, согласно данным компании IDC российский рынок облачных и SaaS решений за последние пять лет вырос более чем в два раза и к 2016 году должен составить более 14 млн. долларов США. Помимо увеличения количества КИС, управляемых самостоятельно, предприятия активно передают на аутсорсинг выполнение части своих информационных задач. По прогнозам Gartner, к 2016 году мировой рынок ИТ аутсорсинга превысит объем 360 млн. долларов США. Российский рынок ИТ аутсорсинга также активно развивается [3]. Все эти факторы требуют разработки методов и программных средств, решающих задачи интеграции данных и информационных процессов при условии минимального изменения исходного кода интегрируемых приложений или КИС.

За последнее время произошло качественное изменение программных средств, используемых для решения задач интеграции, связанное с тем, что предприятия используют разработки сторонних компаний, а не собственные. Это накладывает ограничения на способы коммуникации, форматы передаваемых данных, логику обработки и маршрутизации, надежность передачи блоков данных. Наиболее современным программным средством интеграции, удовлетворяющим этим ограничениям является внешняя интеграционная шина (интеграционная шина) класса Message Oriented Middleware (MOM) [4,5]. Собственные интеграционные шины создаются и развиваются такими компаниями как SAP [6], Oracle [7], IBM [8], Software AG [9] и многими другими [4,10]. Эти продукты предназначены для реализации интеграционных сценариев, включающих в себя небольшое количество заранее определенных шагов, однако используемые ими методы и модели не обеспечивают полноценного описания и решения задач интеграции в соответствии с бизнес-процессом с динамической структурой.

Решением задачи разработки методов и моделей, позволяющих адекватно представить интегрируемые корпоративные информационные системы, интеграционные процессы и предметную область интеграции занимались Атовмян И.О., Иванов М.А., Клименко C.B., Лебедев Г.С., Хетагуров Я.А., Чуканов В.О. (корпоративные информационные системы), Калшшченко Л.А., Когаловский М.Р., Миронов A.M. (моделирование информационных процессов), Ступни-ков С.А., Кузнецов С.Д. (автоматизированный синтез концептуальных моделей). За рубежом решением аналогичных задач занимались A-W Scheer (событийные цепочки), J.L. Peterson, W.P.

van der Aalst (применение сетей Петри), W. Fokkink, R.M Dijkman, J.A. Bergstra (классическая алгебра процессов), R. Milner, G. Boudol, D. Sangiorgi (теория моделирования процессов на исчислениях). В рамках организации АСМ создана отдельная группа, занимающаяся разработкой методов описания взаимодействия - SIGDOC, в задачу которой входит исследование методов проектирования всех аспектов информационного взаимодействия. В настоящее время получены решения, позволяющие моделировать информационные процессы общего вида, но не позволяющие создавать достаточно детализированные модели интеграционных процессов, для разработки на их основе инструментальных средств реализации интеграционного взаимодействия. Разработанные подходы к моделированию информационных систем, их предметной области и их взаимодействия не связаны с подходами к моделированию информационных процессов. Их соединение может быть выполнено с использованием подхода аипликативного моделирования, разработанного Вольфенгагеном В.Э.

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

• разработка метода моделирования предметной области интеграции, ориентированного на синтез моделей интегрируемых систем;

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

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

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

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

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

Метод исследования. При проведении исследований и разработок использовались методы моделирования процессов в соответствии с подходами аппликативных вычислительных

систем, модели исчисления Л-конверсий, я-исчисления, семантики выполнения процессов, концептуального моделирования, темпоральной логики, объектно-ориентированного программирования, функционального программирования.

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

Достижение поставленной цели потребовало решения следующих задач:

1) Выполнение анализа существующих средств концептуального моделирования предметной области и определение общих категорий моделируемых объектов;

2) Выполнение анализа существующих средств моделирования информационных процессов и вычислений в предметно-ориентированных областях;

3) Разработка способа представления информации, позволяющего формулировать требования к настройкам и алгоритмам интеграционной шины;

4) Разработка необходимых моделей процессов, концептуальных моделей предметной области и моделей объектов контроля процесса;

5) Проектирование интеграционной шины, ее архитектуры и программных и пользовательских интерфейсов. Формулировка требований, которым должна удовлетворять реализация;

6) Программная реализация интеграционной шины, отвечающей поставленным требованиям;

7) Экспериментальная проверка работоспособности разработанных моделей, алгоритмов и программных средств.

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

Основные научные результаты, полученные автором, состоят в следующем:

1) Разработаны оригинальные методы моделирования интеграционных процессов на основе теории лг-исчисления, моделирования предметной области интеграции, сообщений

и объектов контроля интеграционного процесса на основе типизированного Л-исчисления;

2) Разработан оригинальный метод представления и обработки сообщений интеграционного процесса и сущностей предметной области, связанных с сообщениями, позволяющий создавать референтные модели интеграционных процессов нового типа и анализировать на основе передаваемых сущностей соответствие выполняемого процесса его модели;

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

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

5) Разработаны и исследованы программные средства реализации интеграционного взаимодействия, обеспечивающие выполнение всех ключевых задач интеграционной шины, оформленные в виде программной библиотеки-ядра интеграционной шипы; Практическая значимость проведенных исследований определяется преимуществами

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

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

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

• организации, автоматизации и контроля существующих процессов предприятия;

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

• передачи выполнения бизнес-процессов предприятия или их частей внешним организациям без потери контроля над этими процессами или доступа к их данным.

Основные результаты, выносимые на защиту:

1) Методы моделирования предметной области интеграции, объектов контроля интеграции, а также структуры и внутренней логики интеграционных процессов, оснащенные языковыми средствами;

2) Семантика выполнения программ, реализующих интеграционные процессы, учитывающая все специфичные для таких процессов шаги и действия, написанных на разработанном языке;

3) Программный инструмент для организации интеграционного взаимодействия, реализованный в виде внешней интеграционной шины, основанной на системе моделирования и выполнения интеграционных процессов в предметной области, а также модульная архитектура такой шины.

Апробация работы. Теоретические и практические результаты работы доложены на следующих научных конференциях:

• Всероссийская объединенная научная конференция "Интернет и современное общество" (IMS 2011) (Санкт-Петербург);

• 17-ая Байкальская всероссийская конференция "Информационные и математические технологии в науке и управлении". (Иркутск 2012);

• 15-th and 16-th International Conference on Enterprise Information Systems (ICEIS) (2013 Angers, 2014 Lisbon);

• Научно-практическая выставка Talling Walls Lab (Москва/Берлин 2013);

• Third International Conference Society for Knowledge Organization (ISKO) (2013 Marrakech)

• international Conference on Science & Engineering in Mathematics, Chemistry and Physics (ScieTech 2014) Jakarta 2014

• 11-th International Conference on e-Business ICE-B (Вена, 2014)

• 2-ая и 3-я Международная конференция Аппликативные Вычислительные Системы

(2010, 2012) (Москва)

• Научные сессии МИФИ 2012, 2013, 2014

По результатам выполненных исследований опубликовано 21 печатная работа, в том числе 7 работ, проиндексированных в базе Scopus и 3 работы в журналах, включенных ВАК РФ в перечень ведущих рецензируемых научных журналов и изданий.

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

Результаты внедрения разработанных методологий и подходов позволяют сделать вывод о достоверности и обоснованности научных и практических результатов работы.

Структура и объем работы. Диссертация состоит из введения, четырех глав, заключения, списка литературы и шести приложений. Общий объем основного текста, без учета приложений — 167 страниц, с учетом приложений - 201 страница. Диссертация содержит 38 рисунков и 26 таблиц. Список литературы включает 137 источников.

1 Анализ особенностей программных средств, используемых в интеграции приложений

В ходе исследования особенностей проектирования и реализации программных средств, используемых для интеграции систем и приложений, а также их использования в интеграционных шинах, автором был проведен анализ подходов, моделей, методов и средств для разработки ПО указанного класса [4,10,11]. Были проанализированы существующие архитектуры и готовые коммерческие предложения, их реализующие [6-9]. На основании анализа архитектур и интерфейсов проработанных интеграционных шин были определены компоненты, разработка которых необходима в рамках интеграционной шины. Автором был проведен анализ существующих подходов к концептуальному моделированию предметной области [12-18] и средств моделирования процессов [19-23].

Настоящая глава состоит из шести параграфов.

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

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

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

В четвертом параграфе представлены результаты анализа формальных подходов к моделированию информационных процессов.

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

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

Результаты, изложенные в данной главе, опубликованы в работах [24-26].

1.1 Общая характеристика программных средств интеграции приложений

1.1.1 Общая формулировка задачи интеграции приложений

Интеграция приложений и программных систем является неотъемлемой частью современной программной индустрии. Особенно активно средства объединения потоков данных и

вычислений развиваются в области корпоративных систем [27,28]. Однако, не для каждого предприятия и не для каждой сферы деятельности применимы интеграционные решения.

Прежде чем описывать различные предметные области и их особенности, необходимо определить какими именно могут быть интеграционные решения. В настоящее время, к этой группе программных средств относится целый ряд технологий, различающихся по выразительной мощности и степени воздействия на разрабатываемую систему. Анализ истории развития средств интеграции показывает тенденцию к разработке средств высокоуровневого взаимодействия, позволяющих организовывать интеграционное взаимодействие с минимальным изменением интегрируемых систем и приложений и открывая интеграционным контрагентам минимум внутренней инфраструктуры (рисунок 1.1.). Исключением является разработка механизма 11РС, удаленного вызова процедур, которая активно развивалась параллельно с большинством низкоуровневых средств взаимодействия, благодаря своей востребованности в корпоративном секторе [29].

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

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

______________jv - ............ ■•■^■м-

»?

ш £

ш г>

I °

1 °

П) о

St го

3 1

1 го

» S

3

тз

S

ь

0

зе

го

1 X Sc

CD W

о> S 5

0 >

го

St

Q

со

S

п>

1

О) •<

■о

0 го

1 Л)

Бизнес-процесс

Концептуаль ная модель

Брокеры сообщений

Сообщения

Внешние интерфейсы, API

Распределен ная база данных

Предлагаемое решение

| J Enterprise Service Bus

j I Корпоративные шины предприятия

1 f SAP Netweaver Process Integration, IBM WebSphere,

1 MQ System I ORACLE ESB, Software AG WebMethods

J Системы управ«ния сообщениями ~ j ч,

j MSMQ, Java MQ 1

Distributed Objects ~• ■■■....... >«........ . , .

Системы совместного использования программных объектов по внешним интерфейсэс

. Remote Procedure Call (RPC) C0RBiiava ш> -NET Re™!ing S

J Система открывает интерфейсы части своих функций для доступа по определенным протоколам и получение соответствующего 1 сообщения запускает выполнение требуемой функции, результат выполнения которой возвращается в синхронном ответе J SAP RFC, JSON RPC, XML-RPC

Distributed Tuples

Несколько приложений используют общую, распределенную базу данных DDMS, JDBC, ODBC

го I

w «-

$> W

5 х

2 о

° ^

« £

St ®

Г> х

ч п>

а го

s о

Л> Л)

Сетевые протоколы

Средства операционной системы

Socket, Stream, Pipe

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

BSD Socket, Java Socket, POSIX Socket, TU API

Общая память

| Shared Memory

; Несколько процессов, использующих одну область оперативной памяти 1 Boost, POSIX, Shm

isscl

Hals.

Ж

JL99S, 12

_2QQ0_

НОЖ

ГЙШЕ

Для обмена данными между различными приложениями может использоваться множество различных подходов и технологий. Они могут различаться но сложности решаемых задач, надежности, производительности и множеству других параметров. Каждое такое средство было разработано для решения конкретных задач интеграции и ни одно из них не может быть использовано как универсальное средство обмена данными между приложениями и программными системами. Для того чтобы интеграционная шина могла использоваться для обмена данными между широким спектром различных систем и приложений, она должна поддерживать различные средства и протоколы передачи данных [31,32]. Целью данного обзора является определить наиболее значимые из них и определить их специфику.

1.1.1.1 Низкоуровневые средства интеграции

Обзор и анализ средств обмена данными между приложениями необходимо начать со средств, разработанных для передачи данных между прикладными приложениями, использующих наиболее простые средства. К таким средствам относятся низкоуровневые механизмы. К данным механизмам относятся системные сигналы, реализованные в операционных системах, механизмы семафоров, каналов и SocketoB, с помощью которых различные приложения, запущенные в одном окружении, могут обмениваться элементарными сообщениями, например, они могут передать сигнал о том, что их выполнение завершилось и вернуть код завершения, или передать указание прекратить выполнение другому приложению и или заблокировать определенный логический или физический ресурс. Кроме сигналов операционной системы можно использовать существующие низкоуровневые средства взаимодействия, такие как CORBA [33,34] или D-Bus [35]. CORBA - это спецификация, позволяющая интегрировать изолированные программные системы на уровне программного кода. По данной спецификации программный код должен быть оформлен в пакет, к которому могут обращаться прочие приложения, используя определенные интерфейсы. Стандартизированы отображения объектов CORBA в объекты языков программирования для большинства современных ООП языков. D-Bus - система межпроцессного взаимодействия, которая позволяет прикладным приложениям обмениваться данными в пределах одной операционной системы. Особенно широко D-Bus используется в UNIX системах, однако существует ее вариант и для Windows. Если CORBA предоставляет спецификацию оформления приложения, чтобы оно могло быть вызвано из другого приложения, то D-Bus — это интеграционная шина, которая инициализируется системным демоном и в которую приложения передают сообщения. Каждое сообщение D-Bus, передаваемое по шине, имеет своего отправителя и получателя (кроме широковещательных сообщений).

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

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

1.1.1.2 Средства обмена структурированными сообщениями

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

1. XML/RPC - Данный протокол относится к одним из первых, созданных для передачи данных в формате XML. Сообщение в данном формате трактуется как вызов определенного метода в системе-получателе с передаваемыми параметрами. В протоколе XML/RPC определяется набор базовых типов данных, которые могут передаваться, к которым относятся - массив данных, дата и время, бинарный формат, строка, числа (целые либо десятичные), булевы значения и структуры (ассоциативные массивы). Данного набора типов данных хватает для описания простой передачи данных, однако если требуется описать более сложные структуры

данных или определить собственные типы - приходится использовать более сложную схему. Существенным преимуществом использования данного протокола передачи является его исключительная простота в использовании. Фреймворк!!, которые поддерживают данный протокол, существуют на всех современных и широко используемых языках программирования, для использования вызовов по XML/RPC нет необходимости создавать и публиковать полное описание веб-сервиса на языке WSDL. Кроме того, для еще большего упрощения синтаксиса сообщении, передаваемых по данному протоколу вместо XML для структуризации данных можно использовать JSON;

Список литературы диссертационного исследования кандидат наук Шумский, Леонид Дмитриевич, 2015 год

Список

существующих процессов.

Данные процессы могут быть изменены или добавлены как подпроцессы к

редактируемому

ienrtft«MvFPrttf

Рабочая область.

Графическое представление разрабатываемо го процесса

Настройки адаптера.

Настройки, сохраненные в _процессе_

¡CAJscis-flcwia" D«-sxlop

Ar.-liiw foldpi

—7-- UewnpUon beltings

/48

¿63 data

I

Область имен.

Имена выбранного блока процесса. Технический код, название данных и связанные настройки адаптера

Список примитив 08.

Элементар ные

процессы, которые могут быть использов аны для построени я процесса - передача данных, получение данных, функция, условное ветвление

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

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

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

Рисунок 4.6. Экранная форма логирования и мониторинга, экранная форма основного

экрана

В

¡V1 ronsforrratkms

Я Pi ОС*** Idrto»

ИU

дао

stop £ sa ftebMh

I 1

Основной экран

Данная экранная

форма представляет

основную

информацию об

интеграционной

шине — на ней

находится список

активных

интеграционных

процессов,

выполняемых

процессов,

отображается

состояние

подключения к

интеграционному

серверу и его статус,

а также содержатся

элементы

управления

модулем

выполнения

процессов

щшшшшшшшшяшшт

Home Adapters Т^) Transformations «{^¡^ Process fcditor J^eJ Logs

▼ Message Monitor

Refresh Display Stop Repeat

Message Id Status Process naate Time from Time to

SS90< ai 7 46?4 876f Su<« pss SendRet eivePioc ?014 05 ?f> 10:71:010 ?014 OS ?fi 19 ?? 0(1 0

ШШШвШШШЁЁШЁШЁШШЯЁЁШ

► Process Monitor

► System logs and ti

Ihtw

20*4 05 Л"*? 1010 ¿014 05 2Ь 1921.01 0 2014 05 26'9221»0 2014 05 26 19 22 00 0

F«t4\,tu

Step type

pi SUrled

tmrnal Input

[ <l"rr-i 1 K|1[«JI I .•( .I • и FireJit-d

ааооаоьс-09/a-4Ю6-91C4-P/959t eeo08«x 097a 4PJt. 9V4 e7»9t

Форма логирования и мониторинга

Данная экранная форма реализует работу с журналами интеграционной шины. Она позволяет просмотреть три основных ракурса -монитор сообщений (копий выполненных интеграционных процессов), монитор процессов (данные в разрезе процесса) и системные мониторы. Из данной формы осуществляется управление «зависшими» или ошибочными запусками

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

Форма логировапия и мониторинга позволяет просматривать сообщения о состоянии интеграционной шины в трех основных ракурсах - в рамках отдельных сообщений, в разрезе интеграционных процессов и просмотр системных сообщений. Ракурс системных сообщений необходим для проверки самых общих состояний интеграционной шины и определения наиболее серьезных ошибок. Анализ интеграции в разрезе интеграционных процессов необходим для определения нагрузки интеграционной шины, выделения наиболее часто выполняемых процессов, анализа «проблемных» интеграционных процессов. То есть данный ракурс является в большей мере демонстрационным.

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

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

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

148

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

Рисунок 4.7. Сценарий работы эксперта предметной области

Подключение к интеграционном у серверу

Выбор решаемой задачи

концептуальной

предметной области

Изменение схем сообщений и

Изменение правил проверки сообщений

Мониторинг типов

сообщений в интеграционной

Сообщить об ошибке исходной

Завершение работы

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

4.3 Результаты внедрения и апробации разработанных подходов к реализации интеграционных сценариев Разработка и исследование подходов к реализации интеграционных сценариев и процессов велась в течении нескольких лет. Применение результатов исследований и разработок производилось в компании ООО БерингПойнт при выполнении проектов для Государственной корпорации по атомной энергии «Росатом». Задачей данных проектов была реализация

149

взаимодействия центрального приложения - ЕОС-Закупки с рядом систем ГК, а также внешних приложений и систем.

Основной задачей, которая стояла при разработке интеграционных сценариев, являлось обеспечение информационного взаимодействия единой отраслевой системы закупок ГК Роса-том со всеми связанными системами для автоматизации процессов планирования, проведения и завершения (контрактования) закупок. При разработке сценариев необходимо удовлетворить требованиям ряда документов, регламентирующих такое взаимодействие, а именно: единый отраслевой стандарт закупок ГК Росатом [132], федеральные законы Российской Федерации, регламентирующие объявление, проведение и контроль закупок 94 ФЗ [133], 223 ФЗ [134] и 44 ФЗ [135], атакже специальные распоряжения, инструкции и прочие внутренние документы. Принимая во внимание все ограничения, необходимо было обеспечить синхронизацию данных между всеми затрагиваемыми системами, установить правила обработки возникающих ошибок и предусмотреть варианты работы интеграционных сценариев в случаях, когда одна из затрагиваемых систем недоступна или должна быть исключена из взаимодействия.

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

Технически разработанные сценарии реализовывались с помощью продукта SAP Net Weaver Process Integration (SAP PI) версии 7.11 (SP 9). В данной интеграционной шине настроены все разработанные интеграционные сценарии, однако для полноценной работы системы потребовалось как расширение ее типовой функциональности, так и использование собственных разработок. Расширение функциональности интеграционной шины проводилось на языках программирования SAP АВАР и Java, разработка собственных приложений велась на языках программирования Python и F#. Выбор этих языков для реализации обусловлен требованиями группы поддержки и техническими особенностями инфраструктуры, в которой выполняются разработанные решения.

Использование специально разрабатываемых подходов к интеграции для решения всех поставленных задач оправдано, во-первых, крайне объемным и разнородным интеграционным

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

•у/'Г» .'I*-* 'Witf"!*1 ЦП

"¡•■lllp

оос о

zakupki. __ gov.ru (Э4ФЗ, 22ЭФЗ, 44ФЗ)

ЗакупкаДоговор

ротокол

Статистика

С

FTP

Планзакупок

План закупок

О

^т* Договор

,. fr, I

Статусы документов

Контра гс

План закупок

\> Договор

Потребность XI

Материалы

Потребность

SAPSRM S<

"EOC-Закупки"

XI 3.0

1С ERP

SAP ERP

Предписания алобы

Пр южение

ЭТП

SOAP^r Протокол \^3[акупка

Предложения Контрагент

Закупка

ротокол

\0 Статистика

О

Статусы документе

Контрагент

Материалы

Предписания Статистика Договор /ПрсшкоЯЗакупка

Особенность приведенного ландшафта интеграции заключается в следующем:

1. Несколько SAP систем, для которых заранее можно определить правила подключения, но количество которых заранее неизвестно и может изменяться в ходе проектов тиража (для SAP ERP), или реализация которых может существенно изменяться в зависимости от внешних обстоятельств (для ЕОС НСИ);

2. Вхождение в интеграционный ландшафт систем, выполняющих идентичные функции, но реализованных с помощью различных технических средств (SAP ERP и 1С ERP). Наличие таких систем обязывает учитывать особенности реализации каждого компонента, сохраняя единый интерфейс доступа;

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

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

4. Использование различных средств взаимодействия с системами (XI 3.0, SOAP, FTP и т.д.) требует разработки интеграционных процессов в максимально общем виде без привязок к конкретным технологиям данных.

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

Таблица 4.3. Системы, участвующие в разработанных интеграционных сценариях

Система Кол-во сценариев, в Кол-во вовлечен- Кол-во исходных

которых участвует си- ных объектов объектов

стема

ЕОС - Закупки 12 52 24

АС ПИРЗ 5 19 9

ЭТП 7 36 8

ООС 4 7 2

ERP 3 9 1

ЕОС НСИ 6 9 9

Для каждого из разрабатываемых процессов строился атрибутный состав, содержащий описания всех сообщений, входящих в данный процесс, относительно каждой системы. Пример заголовка такого атрибутного состава приведен в таблице 4.4. Набор таких документов, разрабатываемых для каждого сценария служит одной из спецификаций для интеграционных контрагентов. Для автоматизированной генерации атрибутных составов в виде файлов Excel было разработано программное средство на языке ¥# и набор VB макросов для кастомизации представления результатов под различные нужды.

Габлица 4.4. Пример заголовка атрибутного состава интеграционного процесса

Software component Object

Name Vers ion URI Type Interface Operation Role Message Description

PreparedProced ure Inb ProcedureCreate Request PreparedProc edure Закупочная процедура

PreparedProced ureResp Out ProcedureRespCre ate Request PreparedProc eriureResp Подтверждение получения ЗП

PreparedProtoc ol Inb ProtocolCreate Request PreparedProt ocol Протокол

BE_C_PROCURE MENT 1.0 urn:bearing-point.com:Procure- Service Interface PreparedProtoc olResp Out ProtocolRespCreat e Request PreparedProt ocolResp Подтверждение получения протокола

ment:ETP:Procedure ProcedureFile_l nb FileCreate Request ProredureFile Файл закупочной процедуры

ProcedureFileRe sp Out FileRespCreate Request ProcedureFile BS5E Подтверждение получения файла закупочной процедуры

ProcedurePublic ation Out PublicationCreate Request ProcedurePu blication Публикация закупочной процедуры

Software component Object

ProcedurePublic ationResp Inb PublicationRespCr eate Request ProcedurePu blicationResp Подтверждение получения публикации закупочной процедуры

PreparedProced ure Out ProcedureCreate Request PreparedProc edure Закупочная процедура

PreparedProced ureRespJnb ProcedureRespCre ate Request PreparedProc edureResp Подтверждение получения ВП

PreparedProtoc ol Out ProtocolCreate Request PreparedProt ocol Протокол

urn:bearing-point.com:SRM:Procure-ment:ETP:Procedure PreparedProtoc olRespJnb ProtocolRespCreat e Request PreparedProt ocolResp Подтверждение получения протокола

BE_l_PROCURE MENT_SRM 1.0 Service Interface ProcedureFile_0 ut FileCreate Request ProcedureFile Файл закупочной процедуры

ProcedureFileRe spjnb FUeRespCreate Request ProcedureFile Resp Подтверждение получения файла закупочной процедуры

ProcedurePublic ation Inb PublicationCreate Request ProcedurePu blication Публикация закупочной процедуры

ProcedurePublic ationResp_Out PublicationRespCr eate Request ProcedurePu blicationResj) Подтверждение получения публикации закупочной процедуры

После определения всех используемых схем и систем, задействованных в интеграционных сценариях, была построена каноническая модель предметной области интеграции. Каноническая модель предметной области содержит схемы всех участвующих в интеграции объектов. Фрагмент заголовка предметной области представлен на рисунке 4.9. За основу при построении канонической схемы брались схемы систем-источников, а для всех прочих систем определись правила трансформации, переводящие каноническое представление в формат, требуемый конечной системой.

В соответствии со схемами данных для каждого сообщения были настроены проверки

153

валидации, позволяющие проверить, что данные поступившего сообщения могут быть разложены в каноническую модель и использованы при выполнении интеграционного процесса. Использование валидации сообщений в соответствии со схемой позволило существенно уменьшить количество ошибок в конечных системах и упростило подключение новых систем в интеграционный ландшафт. Для такой проверки валидации в SAP PI есть встроенный механизм, однако для его активации необходимо вручную форматировать выгружаемые из системы схемы и раскладывать их в соответствующие папки на сервере, определяемые для каждого интеграционного интерфейса каждой системы. Очевидно, что для большого объема точек, в которых требуется валидация, этот способ слишком затратен. Для автоматизации включения валидации по схемам был разработан набор скриптов на языке Python, задачей которых является автоматическое форматирование выгружаемых XSD схем, создание корректной структуры папок на сервере, где выполняется интеграционная шина и корректное копирование схем.

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

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

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

Таблица 4.5. Пример настройки правила уведомлений

Описание Ошибка при отправке сообщения с ЭТП AKD Активное правило

Категория ошибок CBA27_PURJETP_OUT Системная категория, с которой связаны ошибки по данному правшу

Компонент отправителя DMZBSAKD* Код системы отправителя

Интерфейс отправителя * Данная ошибка описывается только пространством имен

Пространство имен отправителя urn:bearingpoint.com:Procurement:ETP* Группа интерфейсов, для которых применимо это правило

Компонент получателя * Правило работает для всех систем, получающих сообщения от указанного отправителя

Интерфейс получателя *

Пространство имен получателя *

Указание места возникновения ошибки Без ограничений Указание на конкретный интеграционный сервер

Для решения поставленных задач в соответствии с подходом, представленным в раз-

деле 2.3, были разработаны наборы критичных состояний и событий, которые были связаны с правилами формирования уведомлений интеграционной шины SAP PI. Использование таких правил позволило существенно снизить уровень «шума» в получаемых пользователями поддержки уведомлениях и, соответственно, увеличить скорость реагирования на возникающие критичные ошибки. Также были применены разработанные расширения на языке SAP АВАР, позволившие увеличить количество данных в передаваемых сообщениях пользователю. В соответствии с рекомендациями SAP для примененных разработок, мониторы сообщений были настроены таким образом, чтобы упростить пользователям поддержки поиск и определение ошибочных сообщений.

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

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

Рисунок 4.10. Графики нагрузки интеграционной шины ГК Росатом

Количество сообщений прошедших через интеграционную шину

опт 13 моя 13 дек 13 *пв.14 фев.14 мар 14 апр 14 май 14

Среднее количество сообщений по дням недели

20000 15000 ( 16000 1400G 12000 10000 8000 6000 400С 2000

\

\

Среднее время обработки сообщения в зависимости от размера сообщений (в кб.)

190 00 290.00 390.00 190,00 59С.0С 690.00 790.00 890 00 990.00

-кол-во сообщений регистрации

Кол-во сообщений заявки -кол-во сообщений процедуры — Кол-во сообщений протоколы

4567123456712345

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

Использование результатов диссертационной работы позволило реализовать в срок качественные интеграционные решения, одобренные специалистами Заказчика, переданные в сопровождение и успешно функционирующие в промышленной эксплуатации. Использование методов и средств, предложенных в диссертации, реализованных с помощью продукта SAP Net Weaver Process Integration, позволило реализовать надежное и масштабируемое решение, упростило поддержку разработанных решений, упростило эксплуатацию системы.

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

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

Данная интеграционная платформа оснащена набором коннекторов - программных приложений, осуществляющих связь интеграционной платформы с внешними системами и приложениями. Такое программное средство содержит определение правил подключения к приложению, системе или источнику данных и реализует задачи сериализации/десериализа-ции данных и их связь с внутренней моделью предметной области (рисунок 4.11.). Коннекторы могут быть двух видов - связанные с конкретными приложениями или связанные с одним из известных В2В стандартов обмена данными.

Рисунок 4.11. Поток сообщений в интеграционной платформе ТуПр

Синтаксическая валидация

Семантическая валидация

Логическая валидация

Трансформа ^ ция к корневым концептам

Семантическая Синтаксическая валидация валидация

Трансформа ция во внешнюю модель

Сериализа ция