авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:   || 2 |
-- [ Страница 1 ] --

РОССИЙСКОЙ АКАДЕМИИ НАУК

СИБИРСКОЕ ОТДЕЛЕНИЕ

Федеральное государственное бюджетное учреждение наук

и

Институт систем информатики им. А.П.

Ершова

УДК 004.738.5:004.942

На правах рукописи

ПЛАТОНОВ ЮРИЙ ГЕОРГИЕВИЧ

МЕТОДЫ ОБЕСПЕЧЕНИЯ ИНТЕГРАЦИИ

СЛАБОСВЯЗАННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

05.13.11. – Математическое и программное обеспечение вычислительных

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

Научный руководитель - д.ф.-м.н., профессор Марчук А.Г.

Новосибирск - 2013 Оглавление Введение Глава 1. Современные технологии, использованные автором 1.1 Типовые подходы к обеспечению интеграции информационных систем и обмена данными между ними............................................................................... 1.2 Сервисно-ориентированная архитектура (Service-oriented Architecture SOA). 1.3 Архитектурный шаблон проектирования Command and Query Responsibility Segregation (CQRS)............................................................................................. 1.4 Выводы.................................................................................................... Глава 2. Интеграция программных модулей автоматизации жизненного цикла программного обеспечения для нужд предприятий с повышенными требованиями к качеству конечного программного продукта 2.1 Описание предметной области................................................................... 2.2 Метод перевода информационных систем на сервисно-ориентированную архитектуру........................................................................................................ 2.3 Выводы.................................................................................................... Глава 3. Решение задач интеграции произвольных независимых информационных систем 3.1 Интеграция независимых информационных систем, созданных ранее третьими фирмами............................................................................................................ 3.1.1 «Открытые» информационные системы................................................ 3.1.2 «Закрытые» информационные системы с внешним API.......................... 3.1.3 Информационные системы с закрытым программным кодом................... 3.2 Обеспечение масштабируемости объединенной системы.............................. 3.3

Защита от несанкционированного доступа.................................................. 3.4 Возможности интеграции независимых информационных систем, созданных ранее третьими фирмами, с перспективой дальнейшей работы на устройствах с ограниченными вычислительными ресурсами........................................................ 3.4.1 Проблема недостаточности вычислительных ресурсов и свободного файлового пространства на стороне «клиента».................................................. 3.4.2 Авторизация и безопасность передачи данных в подобных системах...... 3.4.3 Штатная работа спроектированной системы......................................... 3.4.4

Работа в условиях недоступности сервера............................................ 3.4.5 Перспективы развития и особенности взаимодействия мобильного клиентского приложения и корпоративного приложения..................................... 3.5 Выводы.................................................................................................... Глава 4. Интеграция нескольких информационных систем методом «Business Community» 4.1 Модификация метода «Business Community» для «Облачных вычислений»

(Cloud computing)............................................................................................... Заключение Литература Приложение 1. Примеры конечных автоматов, описывающие жизненный цикл исполнительных документов Приложение 2. Экспериментальные данные для сравнительного анализа шардинга баз данных в информационных системах с повышенным требованием к качеству кода Введение Современное производство демонстрирует устойчивые тенденции к глобализации, будь то объединение нескольких независимых производств (или этапов производства) в один сложный производственный комплекс или добавление новых процессов к уже существующей совокупности.

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

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

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

Именно эти осложненные обстоятельства формируют предметную об ласть настоящего исследования.

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

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

Если отсутствует возможность реорганизации программного кода включенных приложений (по техническим, либо экономическим, при чинам).

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

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

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

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

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

2. Интеграция информационных систем, имеющих жесткие ограничения на аппаратные ресурсы;

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

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

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

В работе исследуются способы модификации шаблона архитектурного проектирования CQRS (Command-Query Responsibility Segregation) и рас сматриваются способы интеграции независимых информационных систем.

Основные принципы предложенных автором методов базируются на сочета нии SOA (Service-Oriented Architecture) и использовании шаблона CQRS.

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

Объект исследования – распределенные слабосвязанные информаци онные системы и методы обеспечения информационного взаимодействия между ними.

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

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

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

Основными требованиями к предлагаемым методам являются:

Возможность применения для сложной системы на предприятиях с по вышенными требованиями к качеству конечного программного про дукта;

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

Обеспечение гибкого (настраиваемого) взаимодействия между подсис темами.

Научная новизна:

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

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

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

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

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

На основе результатов исследований описаны и внедрены новые мето ды обеспечения интеграции подсистем:

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

Метод динамически настраиваемой интеграции «Business Community»;

Метод динамически настраиваемой интеграции «Business Community»

для «Облачных вычислений»;

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

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

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

Передана в промышленную эксплуатацию подсистема «Документо оборот» ИС «АСПИД», разработанная для ОАО ИСС им. Решетнева (г. Же лезногорск).

Переданы в промышленную эксплуатацию мобильные приложения «TRIS for iPad» и «TRIS for iPhone».

Апробация. Основные положения диссертации докладывались на сле дующих конференциях, конкурсах и семинарах:

8 Международная Ершовская конференция (8 PCI 11). Секция «Науко емкое программирование» (Новосибирск, 2011);

Конференция ИНФО-2011 (Москва, МИЭМ, 2011);

Семинар ИСИ СО РАН «Системное программирование» и кафедры программирования НГУ, 2012. Тема: «Методы обеспечения интегра ции в распределенных слабосвязанных информационных системах»;

Семинар ИСИ СО РАН «Системное программирование» и кафедры программирования НГУ, 2011. Цикл докладов «Шаблоны программи рования и проектирования».

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

Объем и структура работы: Диссертационная работа состоит из Вве дения, четырех глав, Заключения, Списка литературы и Приложений. Объем диссертации 107 стр. Список литературы содержит 70 наименований. Ра бота включает 29 рисунков и графиков, полученных в результате расчетов на ЭВМ.

На защиту выносятся:

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

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

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

Метод Business Community;

Метод Business Community с использованием технологии «Облачных вычислений» (Cloud computing).

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

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

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

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

Типовые подходы к обеспечению интеграции информацион 1. ных систем и обмена данными между ними Классификация методов интеграции по структуре интеграции, позво ляет выделить принципы p2p («point-to-point») и «Звезда».

Принцип p2p [44-46] базируется на обеспечении внутри интегрирован ной системы связи каждой подсистемы с каждой, когда каждая пара подсис тем имеет свою интерфейсную связь.

«Звезда» [44-46], как принцип построения объединенной системы, ис пользует централизованный принцип управления системами, используя для связи интегрирующую среду.

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

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

Интегрирующая среда «Звезды» с помощью центрального компонента выполняет обмен сообщениями между системами, протоколирование и мо ниторинг состояния, выполнение сценариев транзакций и т.д.

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

Интеграция процессов достигается за счет создания «сквозных про цессов». Этот способ не подразумевает существенных изменений при ложений, участвующих в интеграции на различных этапах процесса.

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

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

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

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

Фоновое копирование данных может использоваться только, как спо соб односторонней интеграции информационных систем [48]. Для его реали зации необходимо организовать шлюз, доступный для обеих интегрируемых систем, и настроить некоторые специализированные приложения для от правки-приема пакетов данных. Наиболее простой реализацией такого спо соба интеграции является организация доступа к определенной части файло вой системы информационной системы - «приемника» данных, в то время как система - «отправитель» данных с помощью различных транспортных протоколов [51 - 53] (Http, ftp и т.д.) динамически размещает необходимую информацию в виде набора файлов в файловой системе «приемника».

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

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

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

Репликации можно классифицировать следующим образом [8, 9]:

По времени взаимодействия – «репликация реального времени» (ко гда объединять и синхронизировать данные приходится немедленно) и «отложенная репликация».

По направлению движения данных – «односторонняя репликация»

(процесс, когда данные только одной системы не подвергаются изме нению), и «многосторонняя репликация».

По способу передачи данных – «детерминированная репликация»

(использующая при синхронизации данных гарантированный канал связи), и «вероятностная» или «недетерминированная репликация»

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

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

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

Создание репликации с использованием универсальных СУБД, таких, как Microsoft SQL Server [49] или Oracle [50];

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

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

Возможность работы системы как при наличии гарантированного ка нала связи, так и при отсутствии такового;

Надежность;

Возможность реализации для любых платформ;

Возможность работы всех интегрируемых систем с обобщенным хра нилищем данных;

Гибкость в разрешении конфликтов.

Недостатками данного способа будут:

Нетривиальность проектирования «обобщенной системы»;

Сложность конфигурирования;

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

Сервисно-ориентированная архитектура (Service-oriented Ar 1. chitecture SOA) Под сервисно-ориентированной архитектурой мы будем понимать подход к разработке программного обеспечения, основанный на создании слабосвязанных модульных программных компонентов, имеющих стандар тизированные интерфейсы, и последующем объединении их. Такие модули удобно реализовывать, как набор web-сервисов, связанных с помощью SOAP [5] протокола.

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

Основой SOA можно считать технологию Enterprise Service Bus (ESB) [6], которая позволяет обеспечивать унифицированный механизм взаимодей ствия программных компонентов.

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

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

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

Использование независимых от реализации интерфейсов для опреде ления сервисов.

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

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

Система Внутренний код и процессы Код интерфейса, представляющего собой хорошо инкапсулированные сервисы взаимодействующие протоколы Контракт Совместные процессы и определения интерфейсов взаимодействующие протоколы Код интерфейса, представляющего собой хорошо инкапсулированные сервисы Внутренний код и процессы Система Рис. 2 - Применение SOA для интеграции информационных систем Enterprise Service Bus в классической сервисно-ориентированной архи тектуре представляет собой инфраструктуру, которая обеспечивает маршру тизацию доставки запросов сервиса требуемому поставщику сервиса, обес печивает возможность замены одного сервиса другим, независимо от разме щения сервиса и протоколов связи. На Рис. 2 ESB представлен центральной частью схемы, обеспечивающей межсистемное взаимодействие.

Рассмотрим отношение инфраструктуры SOA к ESB подробнее (см.

Рис. 3).

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

Взаимодействие системы с внешними компонентами, как предлагаю щими, так и запрашивающими сервис, осуществляется с помощью шины данных типа ‘business-to-business’.

В то же время, взаимодействие внутренних компонентов осуществля ется через ESB.

Каталог маршрутизации сервиса необходим для организации маршру тов ESB.

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

Внешние Внутренние Диспетчер компоненты, компоненты, бизнес запрашивающие запрашивающие сервисов сервис сервис Enterprise Service Bus Шина B2B маршрутизация, трансформация, Каталог безопасность итд маршрутизации Внешние Внутренние компоненты, компоненты, Каталог бизнес предлагающие предлагающие сервисов сервис сервис Инфраструктура сервис ориентированной архитектуры Рис. 3 - Роль ESB в организации SOA Необходимым минимальным набором функций, которым должен об ладать ESB, является:

Поддержка средств интеграции с поставщиками сервисов;

Настраиваемая маршрутизация сервисов;

Поддержка, как минимум, одного транспортного протокола;

Управление адресацией и наименованием сервисов;

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

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

Обычно SOA реализация выстраивается, как сеть взаимосвязанных сервисов, использующих в качестве внешних сервисов Web-сервисы, в каче стве транспортного протокола - HTTP, а в качестве поддержки парадигмы запрос/ответ - SOAP/HTTP [43].

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

Так как архитектура поддерживает легкое встраивание дополнитель ных сервисов, при проектировании системы важно будет определить общую модель безопасности системы, способы авторизации сервисов и надлежащий уровень безопасности транспортного протокола (HTTP c базовой аутентифи кацией по идентификатору пользователя, либо HTTPS).

В целом следует отметить, что теория проектирования SOA систем еще находится в стадии исследования и развития.

Архитектурный шаблон проектирования Command and Query 1. Responsibility Segregation (CQRS) Архитектурный шаблон проектирования CQRS является одной из ос новных технологий, применяемых в настоящем исследовании и позволив ших разработать и внедрить новые технологии построения интеграции сла босвязанных систем.

Основная концепция построения шаблона проектирования CQRS была предложена Бертраном Мейером [2]. Позднее Грегом Юнгом [1] были сфор мулированы общие принципы построения этого шаблона.

Для удобства понимания общей сути, рассмотрим шаблон проектиро вания CQRS в сравнении с абстрактной корпоративной информационной системой.

В настоящий момент наиболее распространенной архитектурой корпо ративных систем является так называемая трехуровневая архитектура [3] (см Рис. 4).

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

Основными достоинствами такого подхода являются:

Масштабируемость на уровне одного слоя серверной части, Высокая безопасность данных, Высокая надежность, Низкие требования к техническим характеристикам клиентских терми налов, Низкие требования к каналу связи между «тонким клиентом» и серве ром приложения, Конфигурируемость (из-за независимости частей сервера друг от дру га).

К недостаткам следует отнести:

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

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

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

Для упрощения проектирования таких систем они предложили исполь зовать основную парадигму CQRS – разбить весь поток взаимодействия ме жду серверной частью и «тонким клиентом» на 2 канала (для чтения и редак тирования).

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

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

Это существенно упростило и ускорило разработку серверной части.

Поскольку все используемые сервисы взаимосвязаны, но независимы между собой, модель серверной части может быть представлена, как отдель ный сервис. При этом модель можно описать, исходя из понятий и аспектов бизнес-логики, сформулированных в терминах заказчика, что дает возмож ность применить для реализации модели проблемно-ориентированное про ектирование (Domain Driven Design) [4, 54, 55, 56].

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

определяется список сущностей и служб системы.

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

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

Рассмотрим упрощенную модель серверной части информационной системы, с архитектурой, использующей CQRS (см. Рис. 5).

Тонкий клиент Команды Описание области Запрашиваемые знаний (Domain Запросы к данным данные model) События Блок денормализации Данные Журнал событий адаптированные (Event Storage) на чтение (Cache) Сервер приложений Рис. 5 - Принципиальная модель взаимодействия «тонкого клиента» и серверной части системы с архитекту рой, использующей шаблон CQRS Как видно на рисунке, в этом случае пользователю предоставляются заранее подготовленные данные из хранилища данных, адаптированных на чтение.

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

Использование CQRS в модели серверной части системы обеспечивает при разработке сразу ряд преимуществ:

Сокращение времени проектирования приложений за счет использова ния возможностей Domain Driven Design;

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

Низкие требования к ресурсам клиентской части, поскольку реализа ция «тонкого клиента» позволяет делегировать «серверу приложений»

системы большинство функций обработки данных, оставляя «тонкому клиенту» только функции отображения данных;

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

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

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

Предотвращает возникновения некоторых «плавающих ошибок»

(«heisenbug») за счет строгого протоколирования взаимодействия меж ду всеми блоками серверной части системы и логической простотой самих блоков;

Хорошо вписывается в методологию контрактного программирования [10].

К недостаткам подхода следует отнести:

Большая сложность администрирования серверной части;

Сложность создания многопоточного программного обеспечения;

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

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

Выводы 1. В данной главе кратко рассмотрены типовые методы обеспечения ин теграции независимых информационных систем и представлены различные типы интеграции, а также приведены структура и технология применения сервисно-ориентированной архитектуры и архитектурного шаблона Command and Query Responsibility Segregation (CQRS), как методов, лежащих в основе проведенных автором исследований и использованных им для раз работки собственных методов интеграции систем.

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

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

В ходе дальнейших исследований автором предложены описанные в Главах 2, 3 и 4 методы интеграции информационных систем, основанные на расширении сферы применения шаблона CQRS в рамках дополнения техно логии использования сервисно-ориентированной архитектуры.

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

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

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

В этом случае к программному продукту предъявляются повышенные требования к качеству и надежности. Это, в свою очередь, обязывает обеспе чивать продукт полной проектной документацией, формат которого опреде лен ГОСТ [22] и ГОСТ Р ИСО 9001-2008 [23].

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

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

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

Метод перевода информационных систем на сервисно 2. ориентированную архитектуру С точки зрения проектирования в свете вышеизложенных требований автор предлагает искать решение в виде некоторого сочетания технологий 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].

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

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

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

Опубликовать Обязательные поля:

* Исполнитель;

Создавший ЗАЗ отв. за ПО * Отв. за ПО;

получает роль "Владелец" Добавить ЗАЗ * Утверждающий;

для этого ЗАЗ {роль: Отв. за ПО} * Начальник сектора;

* Изделие;

Черновик * Дата начала;

* Компонент/Сборка;

Опубликовать Предварительно должны * Версия;

{pоль: Владелец} быть получены подписи:

1. Исполнитель.

2. Отв. за ПО.

3. Отв. за КП (если указан). [создание версии] Аннулировать {роль: Владелец || Отв. за ПО} Версия Подготовлен в разработке [подписание] {роль: Начальник [подписание] ЗАЗ сектора и дата работ {роль: Начальник утвержден даты подписи сектора} Начальника сектора} Аннулировать [отмена подписи] {роль: Владелец {роль: Начальник || Отв. за ПО} сектора} Принят [отмена подписи] {роль: Начальник Аннулировать сектора и работы {роль: Владелец не были начаты} || Отв. за ПО} В работе утвердить [отмена [согласование] подписи этапа] {роль:

этап “Разработка” Утверждающий} {роль: любой Отв.} завершен Работы завершены Промежуточное состояние, отменено указывающее что все работы отменить утвердить утверждение завершены. Пропускается если утверждение {роль: ЗАЗ этап "Разработка" исключен {роль:

Утверждающий} Утверждающий} Версия Утвержден утверждена [перенос версии Принять в архив] [версия в Базовый архив перенесена {роль: Архивариус} отменить утверждение в архив] {роль: Утверждающий} В архиве Аннулирован Версия в архиве Рис. 6 - Описание жизненного цикла документа «Отчет об изменении / дополнении программного модуля»

Соответственно, обобщенная информационная система должна быть спроектирована, как показано на предложенной автором схеме (см. Рис. 7).

Рабочая станция Рабочая станция Рабочая станция Рабочая станция Рабочая станция Внутренние сервисы Сервис Сервис подготовки взаимодействия печати с «тонким Запуск внутренней клиентом»

синхронизации данных через специальный сервис Сервис управления, для Сервисная шина оповещений изолированных баз данных сообщений Серверная часть, Сервис верификации спроектированная с ввода данных использованием CQRS Шина «B2B»

Сервисы для доступа и работы с Сервисы для доступа и работы с данными репозиториями Сервис Сервисы связи внешних управления интегрированных приложений Сервис Сервис Файл управления управления репозиторием БД БД Сервис Приложение управления аутентификации Файл пользователей репозиторием Данные, Данные,адаптирова адаптированые для Приложение ные для чтения записи для автоматического тестирования Сервис Данные, Специализированные управления адаптированые для приложения (конструктор БД записи ская документация в Файл сервер Файл сервер инженерных приложениях, различные экономические программы) Рис. 7 - Принципиальная схема объединенной системы Как видно из Рис. 7, серверная часть приложения спроектирована с ис пользованием SOA.

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

Блок «Сервисная шина сообщений» представляет собой укрупненный узел ESB.

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

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

Детальное описание данного блока и отличия его реализации от техно логии, описанной Юнгом [1], автор рассматривает при описании блока дос тупа и работы с базами данных.

Левее блока серверной части на рисунке расположена стандартная ши на B2B [59], с помощью которой могут быть проинтегрированы различные программные комплексы, имеющие внешние API или протоколы взаимодей ствия. Они могут быть разработаны как позднее обобщенной системы, так и ранее. Авторами их могут быть как инженеры, реализующие обобщенную систему, так и сторонние команды разработчиков. На рисунке примеры по добных программ представлены блоком сервисов внешних приложений.

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


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

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

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

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

Рассмотрим работу сервиса доступа и работы файл-репозитория на временной диаграмме (см. Рис. 8 и Рис. 9).

Внутренний сервис Сервис управления ФР Сервис управления ФР Сервис управления БД Сохранение файла Получение внутреннего имени Передача внутреннего имени Сообщение о результате Удаление. модификация файла Получение внутреннего имени Передача внутреннего имени Удаление файла Передача результата Сообщение о результате Рис. 8 – Последовательность сохранения, модификации и удаления файлов в объединенном репозитории Рассмотрим подробнее диаграмму последовательностей, возникающих при сохранении, модификации и удалении файла, представленные на Рис. 8.

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

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

В качестве внутреннего имени автором при проектировании использо валась система глобальных идентификаторов (Globally Unique Identifier GUID), предложенную компанией Microsoft [23].

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

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

Немногим отличается картина при удалении или модификации файла.

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

Рассмотрим последовательность поиска информации, содержащейся в файлах объединенного репозитория (см. Рис. 9).

Сервис поиска Сервис управления ФР Сервис управления ФР Сервис управления БД Поиск содержимого Передача маски поиска Получение вн. имен файлов Получение вн. имен файлов Передача вн. имен файлов Получение вн. имен файлов Передача файлов с результатами Объединие и передача результатов Рис. 9 – Последовательность поиска информации, содержащейся в файлах объединенного репозитория Следует отметить, что все файлы репозитория заранее проиндексиро ваны с помощью популярной библиотеки полнотекстового поиска Lucene [24, 25] и индексы обновляются асинхронно после успешного завершения операций в репозитории (добавления, модификации или удаления файла).

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

Далее тот оповещает все сервисы, находящиеся в пуле, о начале полно текстового поиска.

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

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

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

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

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

Рассмотрим работу сервиса доступа и управления базами данных на временной диаграмме (см. Рис. 10), описывающей работу пула сервисов управления базами данных.

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

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

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

Эта последовательность сообщений сделана в концепции классическо го шаблона CQRS [1] без каких-либо изменений.

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

Внутренний сервис Сервис БДЧ Очередь БД Блок шардинга Сервис БДЗ Сервис БДЗ Запрос данных Передача данных Передача данных Сообщение с данными в терминах клиента Запрос на сохранение данных Передача на обработку Запрос на запись данных Запрос на запись данных Запрос на сихронизацию Запрос на сихронизацию Объединенный запрос на сихронизацию Рис. 10 – Последовательность обработки запросов на чтение и сохранение данных из Сервиса доступа и управления БД.

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

Для реализации пула сервисов, управляющего базами данных, адапти рованных на запись, автор модифицировал часть шаблона CQRS и объеди нил его с технологией шардинга (sharging) [26, 27]. Многими авторами работ по технологии шардинга доказано, что однозначного алгоритма разделения базы на несколько частей не существует, так что архитектор при проектиро вании подобных систем, должен подходить к каждой системе индивидуаль но, анализируя структуры ее базы данных.

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

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

Для исследования автор создал два опытных образца базы данных и провел эксперименты.

В качестве основы для эксперимента были выбраны два сервера, с ус тановленными на них тремя копиями MS SQL сервера на каждом.

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

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

Для горизонтального шардинга был применен следующий алгоритм:

на первой (заранее выбранной) копии MS SQL создается дополнительная таблица типа ключ-значение, где ключ - это идентификационный номер типа Guid объекта + названия типа документа, значение – путь нахождения копии MS SQL сервера.

Все объекты разбиваются по пакетам (в эксперименте использовалась мощность пакета в 250 записей).

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

В данном разделе автор приводит лишь итоговые графики замеров (см.

Рис. 11 - Рис. 13).


Графики иллюстрируют зависимость времени поиска документа (в мс) от объема выборки (в тыс. документов).

Очевидно, что исследуемое время поиска будет, помимо количества документов, зависеть и от количества используемых в шардинге серверов с установленными на них копиями MS SQL Server 2012.

Графики, рассчитанные для различного количества копий MS SQL серверов, выделены разными цветами.

Рис. 11 – Диаграмма среднего времени поиска для горизонтального шардинга График, построенный для случаев использования горизонтального шардинга (как более оптимального и широко применяемого, например, в об лачных вычислениях), наглядно иллюстрирует, что при использовании гори зонтального шардинга базы данных, достаточно установить пять копий MS SQL с ограниченным временем поиска данных, а добавление шестой копии не влечет за собой принципиального изменения времени поиска и, соответ ственно, расположения линии графика.

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

Рис. 12 – Диаграмма среднего времени поиска для вертикального шардинга Диаграмма, приведенная на Рис. 13, позволяет сопоставить эффектив ность вертикального и горизонтального шардинга для фиксированного объ ема выборки.

Горизонтальная ось диаграммы отображает количество используемых копий MS SQL Server, а вертикальная - время поиска в мс.

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

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

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

Для инициирования сессии и идентификации пользователя использу ется Windows Active Directory [28, 29] или специализированное сертифици рованное приложение.

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

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

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

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

6. Простота реализации и интеграции приложений, разработанных ранее третьими фирмами Эта характеристика является сильной стороной предложенного реше ния, так как легкая конфигурируемость и достаточно многофункциональный API позволяет сделать интеграцию с обобщенной системой новых сервисов малозатратной. Что касается реализации самой системы, то использование технологий Domain Driven Design в среднем снижает затраты на проектиро вание на 20%, так как количество обсуждений, исправлений и разницы в по нимании процессов между заказчиком и командой программистов сокраще но до минимума.

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

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

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

В настоящее время авторская технология внедрена и успешно исполь зуется в подсистеме «Докуметооборот» информационного комплекса «АС ПИД», разработанного для нужд предприятия ОАО «ИСС» им. ак. Решетнева (г. Железногорск).

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

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

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

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

Соответствующая классификация, введенная автором в статье [30], предполагает следующее деление всех систем:

«Открытые» информационные системы;

«Закрытые» информационные системы с внешним API;

Информационные системы с закрытым программным кодом.

Проведем исследования каждого класса в отдельности на предмет ин теграции серверной части приложения данного класса с внешними система ми.

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

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

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

В качестве мета-языка могут выступать как широко известные и попу лярные, такие, как Пайтон (python) [31], так и написанные фирмой создателем данной информационной системы.

Как было сказано выше, авторское исследование было проведено, как попытка спроектировать объединенную сервисно-ориентированную инфор мационную систему с использованием модифицированного архитектурного шаблона CQRS.

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

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

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

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

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

Остальные блоки схемы иллюстрируют схему обобщенной системы с открытым кодом. Рассмотрим ее подробнее.

Интерфейс внешней системы Внешний интерфейс взаимодействия, с интегрированными системами Интерфейс взаимодействия Команды с пользователем Предметная Дополнительная Запрос к область, часть системы, данным описанная описанная на метаязыком метаязыке Сервис Закрытое описания ядро обобщенной транслятор системы Шина сообщений Хранилище База данных файлов Данные, Блок адаптированные денормализации для чтения Неизменяемая часть системы Рис. 14 – Схема интеграции информационных систем с открытым кодом с использованием шаблона проек тирования CQRS При проектировании обобщенной системы в предметную область пер воначальной системы встраивается предложенный автором дополнительный модуль взаимодействия, написанный на том же метаязыке, что и предметная область первоначальной системы.

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

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

Синхронизация данных и исполнение команд на изменение данных, осуществляются через дополнительную часть системы.

3.1.2 «Закрытые» информационные системы с внешним API К информационным системам с внешним API следует относить систе мы, имеющие закрытый программный код, модель данных и файл репозиторий.

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

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

Для систем с закрытым кодом с внешним API может быть спроектиро вана система, изображенная на Рис. 15.

Интерфейс внешней системы Внешний интерфейс взаимодействия, с интегрированными системами Интерфейс взаимодействия с пользователем Команды Закрытое ядро Запрос к системы данным Сервис Модуль описания внешнего обобщенной API системы Шина сообщений Хранилище База данных файлов Данные, Блок адаптированные денормализации Исходная система для чтения Рис. 15 – Схема интеграции информационных систем с внешним API с использованием шаблона проектиро вания CQRS Первоначальную систему данного типа можно представить, как неко торое закрытое ядро, имеющее коммуникации с модулем внешнего API, ба зой данных, файл-репозиторием и модулем графического интерфейса для взаимодействия с пользователя системы.

Графически первоначальная система представлена на Рис. 15 с правой стороны, и представлена, как «Исходная система». Тогда интеграционное окружение можно спроектировать, как показано в правой части рисунка.

Взаимодействие с исходной системой осуществляется непосредственно че рез сервис описания обобщенной системы.

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

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

Для создания обратных связей автор создал систему триггеров [32, 33], которые позволили обеспечить синхронизацию базы данных первоначальной системы с интеграционным окружением и его базой данных, адаптированной на чтение. На Рис. 15 эти связи обозначены пунктиром.

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

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

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

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

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

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

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

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

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

Никаких иных способов интеграции системы такого типа не предос тавляют.

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

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

Центральные части схем, приведенных на Рис. 14 - Рис. 16, демонстри руют способы организации интегрированного пространства.

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

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

Таким образом, масштабирование такой системы путем увеличения на грузки на API в общем случае не возможно.

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

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

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

Аналогичная возможность интеграции на уровне данных доступна и для систем третьего типа (с полностью закрытым программным кодом). В этом случае взаимодействие обозначено пунктирными линиями на Рис. 16.

Других способов интеграции для систем третьего типа не существует.

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

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

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

Другими «точками роста» общей производительности системы явля ются шина сообщений и сервис описания обобщенной системы.



Pages:   || 2 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.