Методы и программные средства интеграции приложений с использованием внешней шины Шумский Леонид Дмитриевич

Содержание к диссертации

Введение

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

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

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

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

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

1.2.1 Постановка задачи интеграции систем и приложений с использованием интеграционной шины класса Message-Oriented-Middleware 21

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

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

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

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

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

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

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

1.7 Выводы 56

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.5 В ывод ы 111

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

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

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

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

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

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

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

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

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

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

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

3.5 Выводы 137

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

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

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

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

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

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

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

164

4.7 Выводы 165

Заключение 166

Литература

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

Введение к работе

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

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

Решением задачи разработки методов и моделей, позволяющих адекватно представить интегрируемые корпоративные информационные системы, интеграционные процессы и предметную область интеграции занимались Атовмян И.О., Иванов М.А., Клименко СВ., Лебедев Г.С, Хетагуров Я.А., Чуканов В.О.

(корпоративные информационные системы), Калиниченко Л.А., Когаловский М.Р., Миронов 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) Экспериментальная проверка работоспособности разработанных моделей, алгоритмов и программных средств.

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

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

7. Разработаны оригинальные методы моделирования интеграционных процессов на основе теории яг-исчисления, моделирования предметной области интеграции, сообщений и объектов контроля интеграционного процесса на основе типизированного -Я-исчисления;

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

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

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

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

задач интеграционной шины, оформленные в виде программной библиотеки-ядра интеграционной шины;

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

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

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

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

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

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

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

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

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

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

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

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

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

Научно-практическая выставка Falling 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 источников.

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

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

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

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

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

SOAP - Simple Object Access Protocol - Данный протокол передачи данных активно используется для передачи данных между системами, идентифицируемыми ссылками URL, в основном с использованием Web Service, для которых SOAP протокол является основой [36,37]. Спецификацией и стандартами для данного протокола занимается консорциум W3C. Данный протокол подразумевает передачу конверта, содержащего заголовок, в котором передаются основные параметры сообщения и тела конверта, в котором находятся данные в формате XML. К сообщению могут передаваться приложения в произвольном бинарном формате, каждое из которых прикладывается в специально оформленной части POST запроса. В заголовке SOAP конверта, помимо стандартных данных, которые описываются в заголовке POST запроса, может передаваться указание на то, какой метод обработки должен быть вызван, что позволяет использовать одну ссылку на целевую систему для различных типов передаваемых сообщений. Аналогично протоколу XML/RPC сообщения SOAP могут использоваться для удаленного вызова процедур. Если указание на вызов определенной процедуры содержится в части SOAP Body, то спецификация вызова должна содержаться в заголовке. Основным преимуществом использования интеграции систем с использованием SOAP протокола является то, что большинство систем, имеющих доступ к сети, поддерживают определенный набор стандартных сервисов, к которым можно обратиться, и добавление новых сервисов или организация интеграционного процесса с корректным вызовом стандартных не составляет особенного труда. Кроме того, за счет простоты формирования и автоматической обработки XML, сообщения достаточно легко трансформировать в необходимый вид. Однако сообщения SOAP подвержены всем недостаткам, характерным для протоколов, основным способом передачи данных в которых является XML - вызов сервиса является довольно затратной процедурой, объем данных, передаваемых по такому протоколу, существенно возрастает за счет избыточности нотации XML. Другим существенным недостатком является то, что для корректной интеграции необходимо обеспечить надежный способ доставки сообщений в систему, что может быть затруднительно;

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

Прежде чем переходить к описанию компонентов разрабатываемого приложения необходимо определить ряд ключевых понятий, на которых будут строиться дальнейшие утверждения. Прежде всего, необходимо определить понятие информации таким образом, чтобы связать методы описания различных аспектов интеграционного взаимодействия между собой и с настройками соответствующих программных средств. Существует множество различных определений термина «информация» [94-96], однако ни одно из них не может быть адекватно использовано в приложении к задачам интеграции. Это связано с тем, что интеграционный процесс в ходе своего выполнения согласно его определению, объединяет множество прочих процессов обмена и обработки данных. Он включает в себя технический обмен сообщениями, маршрутизацию, разбор и формирование блоков структурированных данных в соответствии с имеющийся схемой, а также валидацию и трансформацию данных сообщения в соответствии с концептуальной схемой предметной области. Для покрытия всех этих задач сформулирован метод представления информации в соответствии с задачами интеграции.

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

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

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

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

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

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

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

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

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

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

В целом архитектура интеграционной шины разработана в стиле MVC - Model-View-Controller [127,128], причем этот шаблон используется на любом уровне описания разработки, то есть это верно как для интеграционной шины в целом, так и для компонентов client и web в частности.

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

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

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

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

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

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

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

Трансформации вынесены в отдельный пакет mapping, так как в предлагаемой реализации они отвечают как за изменение данных (пакет model), так и за динамическую маршрутизацию сообщений (пакет core).

Реализация типового серверного компонента интеграционной шины организуется в соответствии со схемой пакетов, представленной на рисунке 3.4. Данный серверный компонент был разработан для выполнения на облачном Java Application Server, для хранения данных использовалась база данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Экспериментальная проверка и тестирование разработанных программных средств подтвердило их соответствие сформулированным требованиям.

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