автореферат диссертации по информатике, вычислительной технике и управлению, 05.13.11, диссертация на тему:Моделирование процессов интеграции информационных систем

кандидата технических наук
Вин Зо
город
Москва
год
2007
специальность ВАК РФ
05.13.11
Диссертация по информатике, вычислительной технике и управлению на тему «Моделирование процессов интеграции информационных систем»

Автореферат диссертации по теме "Моделирование процессов интеграции информационных систем"

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

Вин Зо 003058405

МОДЕЛИРОВАНИЕ ПРОЦЕССОВ ИНТЕГРАЦИИ ИНФОРМАЦИОННЫХ СИСТЕМ

05 13 11 — математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей

АВТОРЕФЕРАТ

диссертации на соискание ученой степени кандидата технических наук

Автор-

Москва -2007

Работа выполнена в Московском инженерно-физическом институте (государственном университете)

Научный руководитель. доктор технических наук, профессор

Щукин Борис Алексеевич

Официальные оппоненты доктор технических наук, профессор

Александров Владимир Михайлович

кандидат технических наук, с н с Филиппов Вячеслав Алексеевич

Ведущая организация Московский государственный институт

электронной техники (технический университет)

Защита состоится 23 мая 2007 г. в 15.30 часов на заседании диссертационного совета Д212 130 03 в МИФИ по адресу 115409, Москва, Каширское шоссе, д31, телефон 323-91-67, в конференц-зале главного корпуса

С диссертацией можно ознакомиться в библиотеке МИФИ

Автореферат разослан 3 апреля 2007 г

Отзывы на автореферат в двух экземплярах, заверенные печатью организации, просьба направлять по адресу: 115409, Москва, Каширское шоссе, д 31, диссертационный совет, Шумилову Ю Ю

Ученый секретарь диссертационного совета, д т н , профессор

Шумилов Ю Ю

Общая характеристика работы

Актуальность

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

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

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

Таким образом, актуальность выбранной темы определяется тенденцией разработки программных комплексов информационных систем как композиций сервисов (SAAS -Software As A Service). Роль моделирования и тестирования при интеграции получающихся сервисов в распределенную

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

Цели и задачи работы

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

В ходе исследования решены следующие задачи

1. Проанализированы современные технологии интеграции

информационных систем 2 Проанализированы роль и место тестирования в процессе интеграции

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

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

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

Методы исследования

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

Научная новизна и практическая значимость работы

Научная новизна данного исследования состоит в том что

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

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

Практическая значимость работы заключается в том, что-1 Разработан эмулятор локальной платежной сети, заменяющий ее при проведении анализа взаимодействия (тестирования) процессинговой системы банка с локальной платежной сетью Взаимодействие организуется путем обмена сообщениями по специальному протоколу, построенному на основе стандарта ISO 8583 Эмулятор разработан на языке Visual Basic 60 с использованием интерфейса прикладного программирования Wrnsock и СУБД MS Access Доступ к данным в эмуляторе выполняется с помощью технологии ADO

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

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

4 Разработана сеть Петри взаимодействия процессинговой системы с локальной платежной сетью, обменивающихся сообщениями Сеть Петри разработана с использованием среды CPN Tools

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

Реализация и внедрение результатов работы:

Разработанные в диссертации методики и модели процесса интеграции на основе использования информационно-программных эмуляторов интегрируемых систем использованы в учебном процессе кафедры «Кибернетика» МИФИ в курсе для студентов Союза Мьянма «Современные методы и средства проектирования информационных систем» и подготовке диссертаций на соискание степени магистра

Апробация работы:

Основные результаты диссертации докладывались и обсуждались на ежегодных научных сессиях МИФИ (2004, 2005, 2006, 2007 гг.), на международном научно-техническом семинаре «Современные технологии в задачах управления, автоматики и обработки информации» (2005, 2006 гг.) и на всероссийской межвузовской научно-технической конференции студентов и аспирантов, МИЭТ (2007 гг.).

Основные результаты диссертации опубликованы в тезисах докладов на научных сессиях МИФИ, международном научно-техническом семинаре «Современные технологии в задачах управления, автоматики и обработки информации» и на всероссийской межвузовской научно-технической конференции студентов и аспирантов, МИЭТ

Публикации:

Основные положения диссертационной работы опубликованы в 5 печатных работах

Структура и объем работы:

Диссертация содержит 4 главы, введение и заключение, 40 рисунков и 16 таблиц

Общий объем - 98 страниц машинописного текста Список использованных источников содержит 44 наименования

Содержание работы

Во введении обосновывается актуальность темы диссертационной работы и приводится ее краткая характеристика.

Формулируются цель работы и задачи исследования Представляются основные положения, выносимые на защиту

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

В настоящее время интеграция информационных систем, в большинстве случаев, подразумевает обмен сообщениями в режиме Remote Procedure Call (RPC) на базе использования систем гарантированной доставки сообщений (например, IBM MQSeries), хотя не исключается и обмен файлами Если необходимо связать только две подсистемы, то подход типа «точка-точка» является вполне приемлемым. Если же требуется интегрировать локальную подсистему или отдельное приложение в распределенную информационную систему, то в последней обычно существует специальный компонент, через который осуществляется интеграция Часто это специальная обслуживающая подсистема, называемая интеграционным брокером, который получает сообщения от многих подсистем и направляет их соответствующим адресатам В современном варианте - это корпоративная сервисная шина (ESB - Enterprise Service Bus) Например, при интеграции банка в платежную сеть роль такого брокера выполняет специальная функция в процессинговой системе головного банка сети.

На сегодняшний день брокеры сообщений могут объединять большое количество взаимодействующих подсистем, образуя по определению компании Gartner Group «корпоративную нервную систему»

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

стандартов электронной коммерции - OASIS В основе этого подхода лежит XML - мета-язык для представления данных XML является такой же универсальной и базовой технологией для представления, трансформации и обмена данными, как транспортный протокол TCP/IP для Интернета.

Преимуществом этого подхода является то, что он предлагает методологически единое решение как для интеграции в пределах предприятия (EAI - Enterprise Application Integration), так и для В2В-интеграции между предприятиями

Ниже перечислены основные принципы применения web-сервисов для организации взаимодействия подсистем в децентрализованной, распределенной среде

• В качестве основного механизма интеграции используется web-сервис

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

• Организуется отраслевой, региональный или корпоративный регистр для публикации web-сервисов Эти регистры создаются на базе стандарта UDDI (OASIS).

Каково место моделирования и тестирования в процессе интеграции7

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

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

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

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

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

Во второй главе рассмотрены модели, используемые при моделировании процессов интеграции

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

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

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

Рис. 1 .Сеть Петри, моделирующая последовательный алгоритм обработки сообщений подсистемой-клиентом.

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

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

в ответ на сообщение-запрос от клиента.

Рис. 2. Сеть Петри, моделирующая последовательный алгоритм обработки сообщений подсистемой-сервером.

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

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

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

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

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

Команда -В

Прел ст авла яящ

Рис. 3. Архитектура эмулятора в стиле шаблона MVC.

В основу архитектуры программы-эмулятора целесообразно положить шаблон Model-View-Controller (MVC). В этой архитектуре (Рис. 3) контроллер (Controller) отвечает за логику моделирования, то есть за последовательность действий эмулятора,

Контроллер

Модель

I KOMäKgg -2 'Команда»!- .'■

различные команды модели (Model) - за те или иные функциональные преобразования, а представление (View) - за вывод пользователю результатов моделирования

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

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

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

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

• Шаблон сообщения,

• Последнее отправленное сообщение-запрос (request),

• Сообщение-ответ на последнее отправленное сообщение-запрос (response),

• Тестовая база данных интегрируемых подсистем Поля сообщения заполняются в следующем порядке.

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

2 Заполняются все поля, однозначно определяемые данными идентификаторами,

3. Заполняются все остальные поля Шаблон сообщения-запроса содержит определение каждого поля i-oro сообщения

• Literal, Конкретное значение, задаваемое пользователем (например, конкретный номер кредитной карты)

• (<, >, <=, >=, #, =) last request, Значение, формируемое в соответствии со значением поля последнего отправленного запроса Для знака «=» используется константа «Сору from request»

• (<, >, <=, >=, #, =) response, Значение, формируемое в соответствии со значением поля последнего полученного ответа Для знака «=» используется константа «Сору from response»

• (<, >, <=, >=, #, =) (name_table,key,atr_name), name_table - имя таблицы базы данных;

key - имя (номер) поля формируемого сообщения, значение которого уже сформировано и представляет идентификатор записи таблицы name_table

atr_name - атрибут таблицы базы данных Значение, формируемое в соответствии со

значением атрибута atr_name таблицы базы данных name_table

(<, >, <=, >=, #, =) (fîeld_num), field_num - номер (имя) поля формируемого сообщения, значение которого уже сформировано Значение, формируемое в соответствии со значением уже сформированного поля сообщения

• Unique Value, Значение, формируемое генератором уникальных значений

• Valid Value; Значение, формируемое генератором случайных чисел в соответствии с форматом поля

• Non Valid Value; Значение, не соответствующее формату поля

• Field Omitted, Значение опущено

Более просто, но аналогично, формируется ответ в эмуляторе сервера

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

• Шаблон для проверки каждого поля сообщения-ответа;

• Все поля последнего отправленного сообщения-запроса (request),

• Разобранное по полям (то есть прошедшее синтаксическую проверку) сообщение-ответ на последнее отправленное сообщение-запрос;

Шаблон для проверки сообщения-ответа содержит определение правильности каждого поля i-oro сообщения-ответа.

• Literal, Конкретное значение, задаваемое пользователем (например, конкретный номер кредитной карты).

• (<, >, <=, >=, #, =) request, Значение поля сообщения-ответа должно сравниваться со

значением поля сообщения-запроса Для знака «=» можно использовать константу «Сору from request»

• Valid Value, Значение поля должно входить в заданный список значений

• Field Omitted, Поля не должно быть в ответе.

• Non Checked; Значение поля не проверяется Построенные по такой методике тесткейсы позволяют

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

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

Для коммуникации эмулятора и интегрируемой подсистемы интерфейс типа сокетов предоставляет все необходимые средства для создания соединения и совместной работы с интегрируемой подсистемой Интерфейс сокетов обеспечивает возможность взаимодействия между процессами независимо от того, выполняются они на одном компьютере или на разных Кроме того, интерфейс предоставляет единый набор функций для работы с различными стеками протоколов WinSock позволяет работать со всеми распространенными протоколами связи, но для поставленной задачи наиболее интересно взаимодействие по протоколу TCP/IP, используемому для создания приложений клиент - сервер

Спецификация Wmsock описывает стандарт, по которому программы windows обязаны общаться с сетями TCP/IP Интерфейс Winsock не входит в состав windows, а реализован в виде динамически загруженной библиотеки DLL. Модуль Winsock.dll находится между стеком протоколов TCP/IP и клиентским приложением Он управляет интерфейсом к стеку TCP/IP

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

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

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

Так как в современных условиях технология интеграции, в основном, ориентируется на обмен XML-сообщениями между интегрируемыми подсистемами, СУБД должна быть ориентирована на эффективную работу с текстовой информацией и хранение многозначных полей переменной длины С этой задачей лучше всего справляются постреляционные СУБД типа Cache или D3. Возможен выбор XML базы данных В силу того, что практически повсеместно принят в качестве стандарта обмен XML-сообщениями, целесообразно определить структуру типов сообщений с помощью DTD или XML схемы XML схема более подходит для этих целей, так как она детально определяет форматы полей и поэтому может быть эффективно использована на этапе синтаксического анализа приходящего сообщения.

Обобщенная схема базы шаблонов тестов представлена на рис. 4 На ней каждая вертикальная связь выражает отношение типа 1 N, а каждая горизонтальная - отношение типа 1 1 Для управления данными в реализованном эмуляторе выбрана СУБД MS Access. Это связано с тем, что в выбранной предметной области (локальные платежные сети) сообщения должны быть максимально компактны - это далеко не XML Так как все типы сообщений имеют, в общем случае, разные поля по номенклатуре и количеству, то схема базы данных определялась декомпозицией по полям стандарта ISO 8583 Этот вариант является наиболее гибким, хотя и несколько более сложным в реализации

Тест

Рис 4 Иерархическая схема базы данных для хранения шаблонов сообщений.

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

Для демонстрации предлагаемых методов был построен эмулятор локальной платежной сети, который позволяет заменить эту сеть при тестировании процессинговой системы нового банка, при его включении в локальную платежную сеть. Эмулятор может работать как в режиме клиента (Acquire), так и в режиме сервера (Issuer). На рис 5 представлен экран для управления работой эмулятора в режиме клиента

ПиЦ:Т«*с J

_. ■ .. —j

Рис. 5. Управление работой в режиме клиента (Acquire).

Архитектура эмулятора построена на базе шаблона MVC, что позволило реализовать два варианта контроллера, и общую модельную часть. Контроллеры ориентированы на функциональное и нагрузочное тестирование интегрируемых подсистем. «Модель» эмулятора выполнена в виде совокупности «команд», которые реализуют различные функциональные преобразования и извлечение тестовых данных из СУБД. При взаимодействии процессинговых систем, с целью получения максимальной компактности используются специальные структуры сообщений и специальные форматы полей (ISO 8583). Это потребовало реализации в модели специальной «команды» формирования сообщений и разработки специального редактора для формирования тестовой базы данных. На рис. 6 представлен фрагмент тесткейса, в котором представлен пример шаблона запроса на авторизацию (1100) - разрешение эмитента на выдачу запрашиваемой суммы и пример шаблона ответа эмитента (1110).

На рис.7 представлен сгенерированный запрос и полученный на

него ответ,

•ï q?*Wi &U ктдо «дот CtftC.it ft™

Щ^М&мЬиЬх*-,^ -.'У И*.''

[Серу torn re-qoasl j [Co^ï from r«|u»«{]

t2 Дата и местное ер в

23 Порядковый «оивр

32 Номер финах&воп

37 Уникальный номер

36 Код .шерюаци,!

39 Кед агеета

41 Номер термйнальн!

4в ;Допслк*те*»чая пн

49 Код ааллтъ трачза

Ы MAC Data

102 Номер счёта 1

103 Номер с чйта 2 128 MAC Dala

___2 Номер «рты (PAN) 6409999901439624

__ 3 Кед oipa&ma ¡Valid Value]

_ * C^WîTilfflKfA

6 Обща* сумма владелец» картам™ j=(4)|

9 Курс конвертации транзакции е велюту 0'N-a (Field oîtiille-dj

_ 11 STAN [Unty* vaioal

__Дат* и м««ное время окончания сделки [VeWValoej

_ 14 Даг# О«нч»*ИА |=(CARDi.OATE)|

_ 15 Дат* рлечбтжн-о периода p/*d Value)

_ 16 Категория торговца (VaMVtfuej

_ 22 П»р^мстры ■ ovkh оЁслржмваниа ¡Vatid V»iu4j

_ 23 ПорЛДчоеый номер карты ]Fi«« 0ffl4ted|

_ 32 Hauap финансового институте Acqàre jVabd Vafoe]

_ 35 "rat* 2 Data i=(CAfl02.TRACK_2)j

_ 37 ; УкнвМЫшЗ номер транзакции [Unique Vslue|

__ 41 Номер терминальное устройства fVabdVilutJ

_ 43 Пад^миры-:*рммиаяыого устройства jVaMVi)»*]

±_ 45 T»cJt 1 Data HCARM.TRACKJ)]

(jTjjTjj (ИЕЗЁЙ* *

Рис.6, Вариант шаблона запроса и шаблона ответа в базе эмулятора.

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

Ц Report For Ate quire

.......Ш

X

И 100Ш 000000 ИООООООООЗОООООООСОО 100001 ОООЮООООООЮОООООООООООООО

l<554S999990I429624i010ilB444444ö677

оош mil012pi234jS784Q

Test: 07.04. 2007 15:34:50 Transaction Type: 1100

Bilmask.:F4.36.44.01.28.A8 .AO .00,00.00.00.00.10.00.00.00

11001111010000И 011001 ООО 10050000001001Ol000101Ol ООП 101 ООО 00 DQOQ0GQO ОООООООООOOOOOOÜООООООООООООООООО0010000000000оооооооооооооооооо 1б548РЮ9901429624Щ10110444444б677й444444бе77001111051012 1 4 45 56 DS070J Itr 1J123412X3412X12110?34567 S99S3754S9999P01429ää^DOS 07 ¡01178699360OQ 04133456789098P1234567008ABCDE12324991654899999014 29626031484084009345678901

Tesr : 07 . 04 . 2007 i 5 : 34: БЭ *

Transaction Type :1110 Biimask: 7030.00.01 .OS .80.£0.00

Vi

I i

Ш

Content of Request: Send Filet) Wo 02: 5469939901423524

Send FiieciNoÜ3:101011 m

Send Filed Ho 04. 04444446677 Send Fried No 06: 04444446677 Send Filed Noll: 001111 Send Filed No12. 051012144556 Send Filed No14: 0307 Send Fifed No 15: 051C15 Send Fried MolS: 1234 Send Filed Mo22: 12X3412X1211 Send Filed Mo 32: 345678330

Send Filed Mo 35: 37548393990142S624D0S0710117SS393600004 Send Filed No 37:12345678S098 Sj?nd Filed No 41: PI 234567

Рис.7. Фрагмент отчета о результатах тестирования.

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

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

О 10 20 30 40 50 60

вероятность потерь сообщения в процентах

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

в&роятностъ пот&рь сообщения в процентах

Рис.8,б. Количество повторных обращений в зависимости от потерь сообщений в сети.

Основные результаты работы

При выполнении данной работы получены следующие основные результаты.

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

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

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

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

Основные публикации по теме диссертации

1 Вин Зо. Использование раскрашенных сетей Петри для моделирования // «14-я Всероссийская межвузовская научно-техническая конференция студентов и аспирантов, Микроэлектроника и информатика - 2007», - М МИЭТ, 2007

2 Вин Зо Анализ походов интеграции приложений //Современные технологии в задачах управления, автоматики и обработки информации. Труды XV Международного научного технического семинара Сентябрь 2006 г., Алушта - М.' МИФИ, 2006

3. Вин Зо Использование Web-сервисов в Cache' // Научная сессия МИФИ-2006 Сборник научных трудов В 15 томах Т 2. Программное обеспечение технологии. - М МИФИ, 2006.

4 Вин Зо Походы к интеграции технологий баз данных // Современные технологии в задачах управления, автоматики и обработки информации Труды XIV Международного научного технического семинара Сентябрь 2005 г, Алушта - Самара Самарский государственный аэрокосмический университет, 2005.

5 Вин Зо, Зо Вин Аунг. Разработка прототипа информационной системы "Регистратура"// Научная сессия МИФИ-2004 Сборник научных трудов В 15 томах Т2. Программное обеспечение технологии М МИФИ, 2004

Подписано в печать 19 04 2007 г Исполнено 20 04 2007 г Печать трафаретная

Заказ № 399 Тираж 75 экз

Типография «11-й ФОРМАТ» ИНН 7726330900 115230, Москва, Варшавское ш , 36 (495) 975-78-56 www autoreferat ru

Оглавление автор диссертации — кандидата технических наук Вин Зо

Введение

1. Моделирование процессов интеграции.

1.1. Обзор технологий интеграции информационных систем.

1.1.1. Координация данных.

1.1.2. Основы интеграции с использованием XML и web-сервисов.

1.2. Роль и место тестирования в процессе интеграции.

1.2.1. Виды тестирования.

1.2.2. Тестирование взаимодействия процессинговых систем при интеграции.

1.3. Постановка задачи диссертации.

Выводы

2. Модели, используемые при моделировании процессов интеграции.

2.1. Моделирование взаимодействия интегрируемых подсистем на базе раскрашенных сетей Петри.

2.1.1. Сеть Петри как инструмент моделирования.

2.1.2. Сеть Петри для подсистемы-клиента и подсистемы-сервера.

2.2. Программные эмуляторы.

2.2.1. Организация сценариев моделирования.

2.2.2. Тестовая база данных.

2.2.3. Как формируются сообщения.

2.2.4. Как проверяются получаемые сообщения.

Выводы

3. Компоненты эмулятора.

3.1. Коммуникация в эмуляторе.

3.1. СУБД для эмулятора.

Выводы

4. Моделирование процессов интеграции на примере локальной платежной сети

4.1 Интеграция банка в локальную платежную сеть.

4.2. Сеть Петри для взаимодействия процессинговых систем.

4.2.1. Модуль для подсистемы-клиента (Ac qui re).

4.2.2. Модуль для подсистемы-сервера (Issuer).

4.2.3. Иерархическая сеть, связывающая Acquire и Issuer.

4.2.4. Анализ полученных результатов.

4.3. Эмулятор локальной сети процессинговых систем.

4.3.1. Формирование сообщения-запроса.

4.3.2 Синтаксический анализ сообщения.

4.3.3 Семантический анализ сообщения-ответа.

4.3.4 Схема тестовой базы данных.

4.3.5 Реализация эмулятора на базе VB 6.0.

Выводы

Введение 2007 год, диссертация по информатике, вычислительной технике и управлению, Вин Зо

Современные информационные системы обслуживают бизнес, для которого бесконечные изменения и усовершенствования — необходимая составляющая конкурентоспособности. Многочисленные реорганизации компаний требуют перестройки информационных систем, при этом временные и бюджетные ограничения заставляют разработчиков отдельных проектов добавлять к этой и без того сложной сети новые связи и новые приложения, которые никак нельзя назвать открытыми. Все это приводит к ситуации, в которой приложения, вновь вводимые сегодня, завтра попадут в разряд «унаследованных» [ 1 ].

Одним из приемов борьбы со сложностью предметной области является декомпозиция. Создавать локально функционирующие подсистемы, ориентированные на поддержание работы определенных подразделений предприятия, проще, быстрее, дешевле. Результат виден быстрее. Однако, так как на предприятиях практически все взаимосвязано и взаимозависимо, в реально функционирующих информационных системах приходится как-то обеспечивать взаимодействие разрозненных приложений. Используются методы интеграции «по данным», методы на основе приема/посылки сообщений между приложениями. Продвинутые методы интеграции основаны на использовании автономных «информационных брокеров», берущих на себя роль посредников в обмене сообщениями между приложениями. Вслед за интеграцией по данным стали говорить об интеграции процессов и т.д. В настоящий момент на рынке предлагаются целые платформы интеграции, например, [2], маркетинговые материалы по которым обещают решить все имеющиеся проблемы, и заложить основу для решения проблем будущего. Активно обсуждаемая сервис ориентированная архитектура [3], позволяющая строить составляющие бизнеса из базовых конструктивных блоков, фактически требует построения информационных подсистем в виде отдельных служб, услуги которых доступны в режиме 24*7.

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

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

Актуальность выбранной темы определяется тенденцией разработки программных комплексов как сервисов (SAAS - Software As A Service) [38], что требует дополнительных усилий при тестировании взаимодействия сервисов.

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

1. Проанализированы современные технологии интеграции информационных систем.

2. Проанализированы роль и место тестирования в процессе интеграции.

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

4. Разработана модель информационно-программного эмулятора на основе использования сетей Петри.

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

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

В диссертации получены следующие новые научные результаты:

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

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

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

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

2. Модели и средства для построения программной и информационной компоненты для моделирования процесса интеграции.

Разработанные в диссертации методики и модели процесса интеграции на основе использования информационно-программных эмуляторов интегрируемых подсистем использованы в учебном процессе кафедры «Кибернетика» МИФИ в курсе для студентов Союза Мьянма «Современные методы и средства проектирования информационных систем» и подготовке диссертаций на соискание степени магистра.

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

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

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

Заключение диссертация на тему "Моделирование процессов интеграции информационных систем"

Выводы

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

2. Разработанный эмулятор взаимодействия двух процессинговых систем, обменивающихся сообщениями по протоколу IS08583 Host-To-Host, позволяет проводить тестирование процессинговой системы банка, включаемого в локальную платежную сеть. Эмулятор разработан на языке Visual Basic б. О с использованием интерфейса прикладного программирования Winsock и СУБД MS Access. Доступ к данным в моделирующей программе выполняется с помощью технологии ADO.

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

Заключение

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

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

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

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

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

С целью демонстрации подходов к решению задач, поставленных в диссертации, разработана сеть Петри взаимодействия процессинговых систем, обменивающихся сообщениями по протоколу ISO 8583 Host-To-Host. Сеть Петри разработана с использованием среды С PN Tools.

Разработан эмулятор взаимодействия процессинговых систем, обменивающихся сообщениями по протоколу ISO 8583 Host-To-Host. Эмулятор разработан на языке Visual Basic б.О с использованием интерфейса прикладного программирования

Winsock и СУБД MS Access. Доступ к данным в моделирующей программе выполняется с помощью технологии ADO.

Для проведения тестирования с использованием эмулятора на основании документации по протоколу ISO 8583 Host-To-Host разработана схема тестовой базы данных. Семантически база данных определяет иерархическую структуру, позволяющую задавать сбалансированные тестовые ситуации для клиента (Acquire) и сервера (Issuer), а синтаксически это совокупность реляционных таблиц, связанных друг с другом системой ссылок.

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

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

1. Натис Е. Покорение сложности ИТ // Открытые системы, №7-8,2005.2. «Представьте: Ваши приложения работают вместе!» // www.intersystems.ru/ensemble/technology/imagine/brochure-print.html

2. Биберштейн Н., Боуз С., Фиаммант М., Джонс К., Ша Р. // Компас в мире сервис-ориентированной архитектуры (SOA), М.: Кудиц Пресс, 2007.

3. Описание VTS 2000 // Visa International 1994-1999.

4. Вин Зо. Анализ походов к интеграции приложений // «Современные технологии в задачах управления, автоматики и обработки информации: Труды XV Международного научного технического семинара», Алушта. М.: МИФИ, 2006.

5. Вин Зо. Использование раскрашенных сетей Петри для моделирования // «14-я Всероссийская межвузовская научно-техническая конференция студентов и аспирантов, Микроэлектроника и информатика 2007»,М.:МИЭТ, 2007.

6. Вин Зо. Использование Web-Сервисов в Cache'// «Научная сессия МИФИ-2006. Сборник научных трудов. В 15 томах. Т.2. Программное обеспечение технологии» М.: МИФИ, 2006.

7. William I. A. Brief History of Integration // EAI Journal, 2000.

8. Технологии интеграции государственных информационных систем и организации межведомственного взаимодействия //www.microsoft.com/Rus/Government/analytics/integration/overview.mspx

9. Майерс Г. Искусство тестирования программ // М.: Финансы и кредит, 1982.-176с.

10. OASIS организация по продвижению стандартов для структурированной информации, группа OASIS // www.oasis-open.org

11. Ньюкомер Э. Веб-сервисы. Для профессионалов // СПб.: Питер, 2003,256с.: ил.

12. Луиза Тамре. «Введение в тестирование программного обеспечения» «Introducing Software Testing» :.М.: Мягкая обложка, 368 стр., 2003 г.

13. Стивене Род. «Тестирование и отладка на Visual Basic» :.М.: "ДМК", 2001, стр., 384.

14. Татьяна Кривец. «Кто такие тестировщики» www.software-testing.ru/lib/krivets/testers-definition.htm

15. Jensen К. Coloured Petri nets: A high level language for system design and analysis // Lect. Notes Comput. Sci. -1991. Vol. 483 - P. 343-416.

16. Jensen K. Coloured Petri nets: Basic concepts, analysis methods and practical use// Berlin A. O.: Springer-Verlag, 1996. Vol. 1. Basic concepts.

17. Jensen K. Coloured Petri nets: Basic concepts, analysis methods and practical use// Berlin A. O.: Springer-Verlag, 1996. Vol. 2. Analysis methods.

18. Jensen K. Coloured Petri nets: Basic concepts, analysis methods and practical use// Berlin A. O.: Springer-Verlag, 1997. Vol. 3. Practical use.

19. Бин Д. XML для проектировщиков. M.: Кудиц-Образ, 2004.

20. Franklin С. Visual Basic 6.0 Internet Programming, John Wiley & Sons; Bk&CD Rom edition, 1999.

21. ГазПромБанк, http://www.gazprombank.ru.

22. Описание решения SmartVista processing,http ://www. smartvista.ru/posterminalsupport. shtml

23. Котов В. E. Сети Петри. M.: Наука, 1984.

24. Питерсон Дж. Теория сетей Петри и моделирование систем. М., «Мир», 1984.

25. CPN Tools, http://www.daimi.aau.dk/CPNTools/

26. Kristensen L. М., Christensen S., Jensen К. The practitioner's guide to coloured Petri nets // International Journal on Software Tools for Technology Transfer 1998. - Vol. 2, N2.-P. 98-132.

27. ISO 8583 Host to Host Interface, Версия 1.8, Спецификации внешних интерфейсов, // www.smartvista.ru.

28. Синицын С.В., Налютин Н.Ю. Операционные системы: учебное пособие. М.: МИФИ, 2006,213с.

29. Jensen К, Christensen S., Kristensen L.M. CPN Tools, State Space Manual, January 2006.

30. Кузьмено В.Г. Базы данных в Visual Basic и VBA .Самоучитель.-М.:000«Бином-Пресс»,2004г.- 416с.: ил.

31. Berthomieu В., Diaz М. Modelling and verification of time dependent systems using time Petri nets // IEEE Transact, on Software Eng. -1991. Vol. 17, N 3. - P. 259-273.

32. James F. Enterprise Application Integration Techniques, EAI.ITtoolbox.com.

33. InterSystems Corporation. Ensemble White Paper.

34. Enabling the real time enterprise business activity monitoring with Ensemble //www.intersystems.com/ensemble/technology/realtimebam/RealTimeBAMWP.pdf.

35. Steve B. Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC) // http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html

36. Модель SaaS: предостережения // http://erpnews.ru/doc 1595.html

37. Использование СУБД D3 // http://infoved.ru

38. Труб И.И., СУБД Cache 5: работа с объектами // М.: Диалог-МИФИ, 2006

39. Cecelia L., Neal A. SQL for Microsoft access // Wordware Publishing, Inc, 2005.

40. Cary N. Michael R., Jennifer R. Access 2003 Bible//Wiley Publishing, Inc., Indianapolis, Indiana, 2004.

41. Napper L. Winsock 2.0 // John Wiley & Sons Inc (Computers), Bk&CD-Rom edition, 1997.

42. Barcia R., "JavaServer Faces(JSF) vs Struts", SYS-CON Media, 2004r.