Содержание к диссертации
Введение
Глава 1. Современные технологии, использованные автором 10
1.1 Типовые подходы к обеспечению интеграции информационных систем и обмена данными между ними 10
1.2 Сервисно-ориентированная архитектура (Service-oriented Architecture SOA) 15
1.3 Архитектурный шаблон проектирования Command and Query Responsibility Segregation (CQRS) 20
1.4 Выводы 26
Глава 2. Интеграция программных модулей автоматизации жизненного цикла программного обеспечения для нужд предприятий с повышенными требованиями к качеству конечного программного продукта 27
2.1 Описание предметной области 27
2.2 Метод перевода информационных систем на сервисно-ориентированную архитектуру 28
2.3 Выводы 43
Глава 3. Решение задач интеграции произвольных независимых информационных систем 45
3.1 Интеграция независимых информационных систем, созданных ранее третьими фирмами 45
3.1.1 «Открытые» информационные системы 46
3.1.2 «Закрытые» информационные системы с внешним API 49
3.1.3 Информационные системы с закрытым программным кодом 52
3.2 Обеспечение масштабируемости объединенной системы 53
3.3 Защита от несанкционированного доступа 56
3.4 Возможности интеграции независимых информационных систем, созданных ранее третьими фирмами, с перспективой дальнейшей работы на устройствах с ограниченными вычислительными ресурсами 61
3.4.1 Проблема недостаточности вычислительных ресурсов и свободного файлового пространства на стороне «клиента» 65
3.4.2 Авторизация и безопасность передачи данных в подобных системах 66
3.4.3 Штатная работа спроектированной системы 67
3.4.4 Работа в условиях недоступности сервера 70
3.4.5 Перспективы развития и особенности взаимодействия мобильного клиентского приложения и корпоративного приложения 75
3.5 Выводы 77
Глава 4. Интеграция нескольких информационных систем методом «Business Community» 80
4.1 Модификация метода «Business Community» для «Облачных вычислений» (Cloud computing) 89
Заключение 94
Литература 97
- Сервисно-ориентированная архитектура (Service-oriented Architecture SOA)
- Метод перевода информационных систем на сервисно-ориентированную архитектуру
- Информационные системы с закрытым программным кодом
- Модификация метода «Business Community» для «Облачных вычислений» (Cloud computing)
Введение к работе
В настоящей диссертационной работе рассматриваются методы обеспечения взаимодействия между слабосвязанными информационными системами, то есть системами, изначально независимыми, но теоретически пригодными для построения межсистемного взаимодействия. В работе предложена новая концептуальная модель, позволяющая расширить область применения CQRS и представлена новая методология интеграции, разработанная на основе использования модифицированного шаблона CQRS (Command-Query Responsibility Segregation), обеспечивающая высокий уровень межсистемного взаимодействия.
Объект исследования – распределенные слабосвязанные информационные системы и методы обеспечения информационного взаимодействия между ними.
Актуальность темы. С увеличением сложности программных комплексов на фоне общемировой тенденции глобализации, проблема интеграции двух и более информационных систем является весьма актуальной и, в целом, часто исследуемой.
При этом стандартные методы интеграции зачастую не способны удовлетворить всем современным требованиям в части надежности используемого программного обеспечения, целостности структуры базы данных, экономической разумности ведения разработок и прочих аспектов.
Кроме того, появление на рынке целого класса мобильных устройств повысило пользовательский интерес к использованию этих устройств в качестве рабочих станций.
В настоящее время методы интеграции, позволяющие обеспечить настраиваемое (гибкое) взаимодействие между подсистемами в составе объединенного информационного комплекса, автору не известны.
Целями диссертационной работы являются разработка концептуальной модели, описывающей объединенную ИС и позволяющей интегрировать несколько слабосвязанных подсистем на основе использования модифицированного шаблона CQRS. Модель предполагает использование новой методологии построения объединенной информационной системы, включающей в себя теоретическое и экспериментальное обоснование новых методов построения интеграции и использующей в своем описании механизм «слабых» связей.
Основными требованиями к предлагаемым методам являются:
Возможность применения для сложной системы на предприятиях с повышенными требованиями к качеству конечного программного продукта;
Корректная работа методов при разработке сложных систем с возможным использованием в качестве рабочих станций устройств с небольшими ресурсами (например, мобильных);
Обеспечение гибкого (динамически настраиваемого) взаимодействия между подсистемами.
Научная новизна:
-
-
Разработана модификация CQRS как шаблона, дающего возможность обеспечить информационное взаимодействие в слабосвязанных системах, посредством чего расширена научная область его применения.
-
Разработана методология построения интеграции, использующая преимущества сервисно-ориентированной архитектуры (SOA) и модифицированного шаблона CQRS, пригодная для потребностей предприятий с повышенными требованиями к качеству ПО.
-
Предложен не имеющий в настоящее время аналогов метод разработки сложных промышленных приложений с возможностью их дальнейшего использования на устройствах с ограниченными вычислительными ресурсами (в т. ч. мобильными) с обеспечением высокого уровня безопасности данных и сохранением полного набора функций по отношению к стационарному прообразу.
-
На основе авторской модификации шаблона CQRS разработан метод создания информационного сообщества, позволяющий обеспечить гибкое взаимодействие нескольких гомогенных систем («Business Community»). Под гомогенными системами здесь подразумеваются информационные системы, имеющие одинаковую предметную область и предназначенные для автоматизации предприятий, работающих в близких отраслях, но использующих разное программное обеспечение.
Практическая значимость:
Предложенное автором значительное расширение области применения архитектурного шаблона CQRS позволяет организовывать информационное взаимодействие систем, не подвергая их при этом значительной модернизации и с невысокими трудозатратами.
Методы разработаны для сложных условий построения интеграции и могут быть применены в следующих случаях:
на предприятиях с высокими требованиями к ПО;
при построении производственных комплексов с возможностью удаленной работы пользователей на современных мобильных устройствах, в том числе при неустойчивом Интернет-соединении;
для случаев, когда условия и состав интеграции не устойчивы, т.е. периодически возникает необходимость добавлять и исключать системы из интеграции, а также открывать и закрывать часть данных для внешнего доступа без риска для остальных данных.
Все предлагаемые методы обеспечивают высокий уровень безопасности данных.
В рамках реализации предлагаемых технологий передана в промышленную эксплуатацию подсистема «Документооборот» ИС «АСПИД», разработанная для ОАО ИСС им. Решетнева (г. Железногорск).
Кроме того, переданы в промышленную эксплуатацию мобильные приложения «TRIS for iPad» и «TRIS for iPhone», разработанные для компании Recruitment Systems Pty Ltd (Австралия).
Апробация. Основные положения диссертации докладывались на следующих конференциях, конкурсах и семинарах:
8 Международная Ершовская конференция (8 PCI 11). Секция «Наукоемкое программирование» (Новосибирск, 2011);
Конференция ИНФО-2011 (Москва, МИЭМ, 2011);
Семинар ИСИ СО РАН «Системное программирование» и кафедры программирования НГУ, 2012. Тема: «Методы обеспечения интеграции в распределенных слабосвязанных информационных системах»;
Семинар ИСИ СО РАН «Системное программирование» и кафедры программирования НГУ, 2011. Цикл докладов «Шаблоны программирования и проектирования».
Методы исследования включают в себя методы математической логики, методы теории множеств, методы конечных автоматов, методы языков программирования, объектно-ориентированный анализ, вычислительный эксперимент, технологии документно-ориентированного программирования, и разработки, управляемой моделями.
Объем и структура работы: Диссертационная работа состоит из Введения, четырех глав, Заключения и списка литературы. Объем диссертации -107 стр. Список литературы содержит 70 наименований. Работа включает 29 рисунков и графиков, полученных в результате расчетов на ЭВМ.
Сервисно-ориентированная архитектура (Service-oriented Architecture SOA)
Рассмотренные выше способы могут быть в больше или меньшей степени эффективно реализованы в случае, когда существует возможность изменить код приложения и постоянный канал для организации интеграционной шины. В противном случае стоит обратиться к таким технологиям, как фоновое копирование данных и репликация данных со способами разрешения конфликтов.
Фоновое копирование данных может использоваться только, как способ односторонней интеграции информационных систем [48]. Для его реализации необходимо организовать шлюз, доступный для обеих интегрируемых систем, и настроить некоторые специализированные приложения для отправки-приема пакетов данных. Наиболее простой реализацией такого способа интеграции является организация доступа к определенной части файло вой системы информационной системы - «приемника» данных, в то время как система - «отправитель» данных с помощью различных транспортных протоколов [51 - 53] (Http, ftp и т.д.) динамически размещает необходимую информацию в виде набора файлов в файловой системе «приемника».
Дальнейшая обработка этих файлов может осуществляться специальном приложением, которое проверяет вводные данные на безопасность, после чего объединяет их с данными системы - «приемника».
Таким образом, к достоинствам способа фонового копирования следует отнести отсутствие необходимости изменения интегрируемых информационных систем, отсутствие необходимости в постоянном канале связи между системами и дешевизна реализации. К недостаткам относится сравнительно невысокая применимость, потому что подобная интеграция возможна только на уровне данных, а не потоков или бизнес-логики, вследствие чего при попытках реализации способа нередко возникают конфликты.
Репликацию данных, как способ интеграции, целесообразно использовать, когда интегрируемые систем могут использовать одни и те же данные или часть из них, но разделены пространственно и не имеют постоянного канала, либо разобщены, исходя из бизнес-логики.
Репликации можно классифицировать следующим образом [8, 9]: По времени взаимодействия - «репликация реального времени» (ко гда объединять и синхронизировать данные приходится немедленно) и «отложенная репликация». По направлению движения данных - «односторонняя репликация» (процесс, когда данные только одной системы не подвергаются изме нению), и «многосторонняя репликация». По способу передачи данных - «детерминированная репликация» (использующая при синхронизации данных гарантированный канал связи), и «вероятностная» или «недетерминированная репликация» (репликация происходит только в выделенных сеансах связи или при нимающая система не имеет возможности в любой момент времени дополнительно опросить передающую систему, если возникла необходимость). По способу анализа информации - «репликация по текущему состоя нию» (если полученные данные сопоставляются с текущими данными базы данных сразу по мере их получения системой-«приемником»), и «дельта-репликация» (если анализ полученных данных происходит сразу для всего пакета информации).
Важно также отметить, что репликация данных, при всей простоте общей идеи, может вызвать значительные затруднения при реализации, для устранения которых разработчики традиционно прибегают к двум основным способам: Создание репликации с использованием универсальных СУБД, таких, как Microsoft SQL Server [49] или Oracle [50]; Разработка специализированного дополнительного сервиса, взаимодействующего непосредственно с принимающей данные информационной системой [48]. Этот способ является более гибким, но его реализация является нетривиальной задачей, поскольку разработчику приходится брать на себя ответственность за разрешение возможных конфликтов.
Репликация данных, как способ интеграции, обладает рядом неоспоримых достоинств: Возможность работы системы как при наличии гарантированного канала связи, так и при отсутствии такового; Надежность; Возможность реализации для любых платформ; Возможность работы всех интегрируемых систем с обобщенным хранилищем данных; Гибкость в разрешении конфликтов. Недостатками данного способа будут: Нетривиальность проектирования «обобщенной системы»; Сложность конфигурирования; Возможность применения только для систем, имеющих единый формат базы данных.
Метод перевода информационных систем на сервисно-ориентированную архитектуру
В данной главе кратко рассмотрены типовые методы обеспечения ин теграции независимых информационных систем и представлены различные типы интеграции, а также приведены структура и технология применения сервисно-ориентированной архитектуры и архитектурного шаблона Command and Query Responsibility Segregation (CQRS), как методов, лежащих в основе проведенных автором исследований и использованных им для разработки собственных методов интеграции систем.
Кроме того, в главе указано, что, несмотря на неоспоримые достоинства классических подходов к интеграции, для целого ряда информационных систем (или систем в определенных условиях) интеграция представляет собой достаточно нетривиальную задачу, о системных исследованиях которой автору не известно.
Между тем актуальность подобных исследований и решений с каждым годом растет вследствие постоянно увеличивающейся сложности объединенных информационных пространств, больших объемов данных, сложных условий хранения и режимов доступа к данных, многообразия ранее реализованных программных комплексов, и многообразия устройств доступа к данных.
В ходе дальнейших исследований автором предложены описанные в Главах 2, 3 и 4 методы интеграции информационных систем, основанные на расширении сферы применения шаблона CQRS в рамках дополнения технологии использования сервисно-ориентированной архитектуры. Глава 2. Интеграция программных модулей автоматизации жизненного цикла программного обеспечения для нужд предприятий с повышенными требованиями к качеству конечного программного продукта
Современное производство часто ставит перед разработчиком ПО задачу обеспечения информационного взаимодействия между автоматизированными системами для случаев, когда хорошо изученные и описанные в Главе 1 стандартные технологии обеспечения интеграции не гарантируют качественного результата.
В частности, существует определенное количество предприятий, где ошибки в работе программного обеспечения могут привести к крайне неблагоприятным последствиям, поэтому к его качеству изначально предъявляются повышенные требования. Специфика предприятий такого рода описана в разделе 2.1, а предложенная автором технология интеграции, позволяющая удовлетворить высокие требования к качеству и безопасности ПО – в разделе 2.2.
Рассмотрим современное предприятие, конечным продуктом производства которого является сложный программно-инструментальный комплекс, предназначенный для работы в сложных условиях, и рассмотрим перспективы полной автоматизации его производственного цикла.
В этом случае к программному продукту предъявляются повышенные требования к качеству и надежности. Это, в свою очередь, обязывает обеспечивать продукт полной проектной документацией, формат которого определен ГОСТ [22] и ГОСТ Р ИСО 9001-2008 [23].
Кроме того, при разработке ПО часто приходится сталкиваться со сложной системой контроля над прохождением этапов производственного цикла, и необходимостью, практически, на каждом этапе применять программное обеспечение, разработанное третьей фирмой-разработчиком, которое по тем или иным причинам не может быть изменено или заменено. Часто такое программное обеспечение представляет собой программный модуль, автоматизирующий конкретный участок производственного процесса, имеющий некоторый набор входных и выходных данных, представленный в виде нескольких файлов и внешнего API [57, 58].
Таким образом, учитывая большое количество этапов производства и сложность каждого в отдельности, процесс объединения подобного предприятия в единую информационную систему представляет многоэтапную задачу.
Исключение дублирующейся документации, которая появляется на этапе входных - выходных данных, а также уменьшение влияния «человеческого фактора» на процесс контроля над успешным прохождением этапов жизненного цикла ПО, дают существенный экономический эффект при реализации общей автоматизации подобных предприятий.
С точки зрения проектирования в свете вышеизложенных требований автор предлагает искать решение в виде некоторого сочетания технологий SOA и CQRS.
Для достижения гибкости в создании системы контроля автором предложено использовать метод управления доступом на основе ролей (Role Based Access Control, RBAC) [24-26]. Модель этой технологии была предложена Феррайоло (Ferraiolo) и Куном (Kuhn) в 1992 году. Суть же модели сводится к следующему: 1. Существует некий субъект (S - subject), определяющийся системой в момент идентификации пользователя. 2. Существует роль (R - role), некоторая рабочая функция пользователя, множество которых назначается субъекту при авторизации пользователя. 3. Существует ряд наборов разрешений (P - permission), представляющий собой множество прав доступа к объектам системы. 4. Сессия (SE - session) – взаимно-однозначное соответствие субъекта набору ролей или набору разрешений. 5. Назначения субъекта (SA – subject actions), где SA (S x R) - определение всех связей между субъектами и ролями, как «много–ко-многим». 6. Один субъект может иметь несколько ролей. 7. Одну роль могут иметь несколько субъектов. 8. Одна роль может иметь несколько разрешений. 9. Одно разрешение может принадлежать нескольким ролям. Таким образом, по мнению автора, данная модель позволяет достаточно просто настраивать сколь угодно сложный набор разрешений для заданного набора ролей и гибко изменять их в уже работающей информационной системе, что существенно для предприятий такого рода.
Для обработки и контроля всего процесса производства автором было предложено в рамках концепции «SOA+CQRS» создать обобщенный клиентский сервис – «Документооборот».
На Рис. 6, в качестве примера, представлен конечный автомат для документа «Отчет об изменении / дополнении программного модуля», разработанный автором в рамках настоящего исследования на языке UML [68-70]. Автомат реализован, как часть программного комплекса, имеющего возможность модификации всех этапов продвижения документа, и используемый в настоящее время на предприятии ОАО «ИСС» им. ак. Решетнева, являющемся производственной площадкой для внедрения данного метода.
Информационные системы с закрытым программным кодом
К закрытым для воздействия информационным системам следует относить системы, имеющие полностью закрытый программный код, модель данных и файл-репозиторий.
В этом случае у архитектора, пытающегося спроектировать интеграцию с подобной системой, нет никаких доступных способов интеграции, регламентированных фирмой-производителем.
Большинство систем такого типа представляют собой либо системы, спроектированы достаточно давно, когда автоматизация производственных процессов представляла собой весьма отдаленную перспективу, в связи с чем создание дополнительных API рассматривалось архитекторами, как ненужное усложнение системы, либо это закрытые системы, в которых при проектировании применялись дополнительные ограничения, например, на секретность выходной информации, на общие вычислительные ресурсы системы и.т.д.
Для систем этого типа принципиальная схема обобщенной информационной системы будет выглядеть подобно схеме, приведенной на Рис. 15 с тем отличием, что в первоначальной системе какой-либо внешний API не предусмотрен. Она изображена на Рис. 16.
Как видно на схеме, единственная возможность наладить взаимодействие с такой системой может быть реализована только через непосредственную работу с данными, и только в случаях, когда исходная система предоставляет доступ к базе данных и хранилищу файлов, что обозначено на схеме пунктирными линиями.
Никаких иных способов интеграции системы такого типа не предоставляют. Обеспечение масштабируемости объединенной системы Обратимся к рассмотрению проблемы масштабируемости, т.е. обеспечения корректного взаимодействия между системами в случаях, когда объем потока пересылаемых между ними данных заметно увеличивается, либо функциональные возможности объединенной системы расширяются.
Воспользуемся авторской классификацией систем, приведенной в разделе 3.1, и рассмотрим перспективы масштабируемости обобщенной системы для случаев, когда одна из систем, включенных в интеграцию, относится к одному из трех типов, а вторая представляет собой абстрактную подсистему, причем интегрирующий модуль состоит из Web-сервиса для коммуникаций и согласованного с ним набора dll-библиотек.
Центральные части схем, приведенных на Рис. 14 - Рис. 16, демонстрируют способы организации интегрированного пространства.
Рассмотрим сначала перспективы масштабируемости для интеграции, когда одна из систем имеет закрытый программный код, но обладает внешним API.
Для систем этого (второго) типа передача данных осуществляется только посредством API, который, в свою очередь, представляет собой строго ограниченный набор функций, а, также, имеет строго ограниченную пропускную способность, определяемую собственными свойствами API.
Таким образом, масштабирование такой системы путем увеличения нагрузки на API в общем случае не возможно.
Если реализация системы второго типа позволяет осуществлять доступ к базе данных и/или файл-репозиторию (обозначенный пунктирными линиями на Рис. 15), то это обеспечивает дополнительную возможность интеграции, допускающей масштабирование.
В этом случае информационное взаимодействие обеспечивается непосредственно на уровне данных.
Данный способ интеграции, бесспорно, гарантирует быстрое взаимодействие, но требует дополнительных мер обеспечения безопасности данных и системы в целом. Аналогичная возможность интеграции на уровне данных доступна и для систем третьего типа (с полностью закрытым программным кодом). В этом случае взаимодействие обозначено пунктирными линиями на Рис. 16. Других способов интеграции для систем третьего типа не существует.
Таким образом, становится очевидным, что второй и третий типы представляет собой простые для реализации (в случаях, когда она возможна), но, одновременно, жесткие варианты интеграции, не подразумевающие дальнейшего развития. То есть, если для существующей интеграции существенно увеличится объем потока информацией или в процессе эксплуатации системы потребуется добавить к ней дополнительные задачи, решить это можно будет только полной перестройкой подсистемы с привлечением команды программистов.
Если масштабирование системы возможно, существует несколько «точек роста» обобщенной системы, которые можно эффективно использовать для решения задач масштабирования (т.е. увеличения нагрузки на существующую систему, или обеспечения участия данной системы в новых задачах по интеграции без ее существенного изменения).
Модификация метода «Business Community» для «Облачных вычислений» (Cloud computing)
Данная глава посвящена описанию разработанных автором способов интеграции независимых информационных систем.
Классический подход, применяемый к интеграции информационных систем, предполагает создание специального модуля интеграции. Данный модуль использует в качестве базы данных базу данных исходной системы, и имеет собственный интерфейс для взаимодействия с внешними системами.
В рамках авторской концепции, существенно расширяющей сферу использования классических методов, для систем с открытым кодом дополнительный модуль-транслятор, принадлежащий объединенной системе, может быть реализован в виде dll а дополнительную часть системы для работы с новым ядром, следует описать в терминах метаязыка.
Далее, для систем «закрытого» типа с внешним API такой модуль, по авторской идее, должен быть оформлен в виде dll библиотеки и запускаться как Windows-сервис [34] или Web-сервис [35].
Предложенные методы гарантируют защиту от несанкционированного доступа к данным и возможность масштабирования объединенной системы.
Все экспериментальные исследования проводились на площадке, предоставленной компанией Recruitment Systems Ltd Pty (Австралия, http://www.Recruitment systems.com/) при апробации и внедрении автором своих методик, разработанных в рамках проектов Tris Enterprise и Tris Mobile (2011, 2012 гг.). В качестве первоначальной информационной системы была выбрана корпоративная система TRIS, которую следует относить к классу закрытых систем с внешним API.
Кроме того, в данной главе автором проведены исследования возможности интеграции независимых систем любого типа, созданных ранее третьими фирмами, с перспективой дальнейшей работы на устройствах с ограниченными ресурсами.
В качестве результата этих изысканий, автором предложен и описан метод, позволяющий организовать рабочее место пользователя корпоративной информационной системы, где в качестве рабочего компьютера пользователь применяет какое-либо современное мобильное устройство (iPad, iPod, netbook и т.д.)
Общей особенностью этих устройств является ограниченность общих и вычислительных ресурсов, что, как правило, не позволяет использовать на них программы, разработанные для стационарных компьютеров. Автор предлагает свой метод решения этой проблемы, основанный на использовании модифицированного шаблона CQRS.
Шаблон позволяет существенно снизить сетевой трафик; достаточно просто, с точки зрения реализации, применить такие технологии, как Domain model [1] и Data Transfer Object [43], поэтому, по мнению автора, позволяет вполне успешно решать проблему несоответствия между высокими требованиями, предъявляемыми к корпоративным системам и ограниченными возможностями пользовательских устройств, на которые будет устанавливаться клиентская часть такого приложения.
Предлагаемый метод включает описание технологии организации мобильной работы с корпоративным приложением с учетом защиты передаваемых данных. Использование предлагаемой методики позволяет работать с корпоративной системой как в случае стабильного сетевого соединения, так и в случае отсутствия сети.
В случаях устойчивой связи с сервером в распоряжении мобильного пользователя находятся все ресурсы базы данных и все выполняемые им изменения сразу же сохраняются серверной частью приложения.
Если связь с сервером прервана, пользователь работает автономно, используя хранилище данных на своем мобильном устройстве. Хранилище
данных сохраняет информацию об объектах центральной БД в том объеме, который доступен на конкретном мобильном устройстве. Выполненные в момент отсутствия связи будут сохранены в центральной БД сразу же после восстановления связи с сервером, причем метод позволяет проверять сохраняемые данные на совместимость и гарантирует сохранение их целостности.
Ввиду невысокой трудоемкости при реализации метод открывает достаточно широкие перспективы для дальнейшего развития и использования на современном рынке приложений для мобильных устройств.
Данный метод был апробирован при разработке приложения «TRIS Mobile», разработанного по заказу компании Recruitment Systems Pty Ltd (Австралия) и в настоящее время находящегося в промышленной эксплуатации.
В целом, по мнению автора, метод может быть успешно применен для любой стандартной корпоративной системы, поскольку использует универсальную технологию, не зависящую от особенностей проектирования и разработки первоначальной системы.
Похожие диссертации на МЕТОДЫ ОБЕСПЕЧЕНИЯ ИНТЕГРАЦИИ РАСПРЕДЕЛЕННЫХ СЛАБОСВЯЗАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ
-
