Содержание к диссертации
Введение
1. Моделирование процессов интеграции 7
1.1. Обзор технологий интеграции информационных систем 7
1.1.1. Координация данных 7
1.1.2. Основы интеграции с использованием XML и web-сервисов 10
1.2. Роль и место тестирования в процессе интеграции 13
1.2.1. Виды тестирования 14
1.2.2. Тестирование взаимодействия процессинговых систем при интеграции 16
1.3. Постановка задачи диссертации 20
Выводы 21
2. Модели, используемые при моделировании процессов интеграции 22
2.1. Моделирование взаимодействия интегрируемых подсистем на базе
раскрашенных сетей Петри 23
2.1.1. Сеть Петри как инструмент моделирования 23
2.1.2. Сеть Петри для подсистемы-клиента и подсистемы-сервера 25
2.2. Программные эмуляторы 31
2.2.1. Организация сценариев моделирования 31
2.2.2. Тестовая база данных 33
2.2.3. Как формируются сообщения 34
2.2.4. Как проверяются получаемые сообщения 36
Выводы 37
3. Компоненты эмулятора 38
3.1. Коммуникация в эмуляторе 38
3.1. СУБД для эмулятора 44
Выводы 47
4. Моделирование процессов интеграции на примере локальной платежной сети 48
4.1 Интеграция банка в локальную платежную сеть 48
4.2. Сеть Петри для взаимодействия процессинговых систем 52
4.2.1. Модуль для подсистемы-клиента (Acquire) 52
4.2.2. Модуль для подсистемы-сервера (Issuer) 54
4.2.3. Иерархическая сеть, связывающая Acquire и Issuer 55
4.2.4. Анализ полученных результатов 56
4.3. Эмулятор локальной сети процессинговых систем 60
4.3.1. Формирование сообщения-запроса 67
4.3.2 Синтаксический анализ сообщения 72
4.3.3 Семантический анализ сообщения-ответа 76
4.3.4 Схема тестовой базы данных 78
4.3.5 Реализация эмулятора на базе VB 6.0 83
Выводы 91
Заключение 92
Список литературы
- Основы интеграции с использованием XML и web-сервисов
- Сеть Петри для подсистемы-клиента и подсистемы-сервера
- СУБД для эмулятора
- Модуль для подсистемы-клиента (Acquire)
Введение к работе
Современные информационные системы обслуживают бизнес, для которого бесконечные изменения и усовершенствования — необходимая составляющая конкурентоспособности. Многочисленные реорганизации компаний требуют перестройки информационных систем, при этом временные и бюджетные ограничения заставляют разработчиков отдельных проектов добавлять к этой и без того сложной сети новые связи и новые приложения, которые никак нельзя назвать открытыми. Все это приводит к ситуации, в которой приложения, вновь вводимые сегодня, завтра попадут в разряд «унаследованных» [1].
Одним из приемов борьбы со сложностью предметной области является декомпозиция. Создавать локально функционирующие подсистемы, ориентированные на поддержание работы определенных подразделений предприятия, проще, быстрее, дешевле. Результат виден быстрее. Однако, так как на предприятиях практически все взаимосвязано и взаимозависимо, в реально функционирующих информационных системах приходится как-то обеспечивать взаимодействие разрозненных приложений. Используются методы интеграции «по данным», методы на основе приема/посылки сообщений между приложениями. Продвинутые методы интеграции основаны на использовании автономных «информационных брокеров», берущих на себя роль посредников в обмене сообщениями между приложениями. Вслед за интеграцией по данным стали говорить об интеграции процессов и т.д. В настоящий момент на рынке предлагаются целые платформы интеграции, например, [2], маркетинговые материалы по которым обещают решить все имеющиеся проблемы, и заложить основу для решения проблем будущего. Активно обсуждаемая сервис ориентированная архитектура [3], позволяющая строить составляющие бизнеса из базовых конструктивных блоков, фактически требует построения информационных подсистем в виде отдельных служб, услуги которых доступны в режиме 24*7.
В процессе интеграции автономных, слабо связанных информационных подсистем вырабатывается некоторый протокол их взаимодействия, который требует тщательного тестирования. Это тестирование практически невозможно, по крайней мере, нецелесообразно проводить в процессе реального взаимодействия подсистем. Практика интеграции, например, процессинговых подсистем банков при вступлении последних во всемирные платежные сети или в локальные платежные сети активно использует программные эмуляторы для этих целей [4].
Целью диссертации является исследование и разработка методов и инструментальных программных средств для моделирования процессов взаимодействия локальных информационных подсистем предприятий, получаемых при их интеграции.
Актуальность выбранной темы определяется тенденцией разработки программных комплексов как сервисов (SAAS - Software As A Service) [38], что требует дополнительных усилий при тестировании взаимодействия сервисов.
Для достижения поставленной цели в диссертации решены следующие задачи:
Проанализированы современные технологии интеграции информационных систем.
Проанализированы роль и место тестирования в процессе интеграции.
Разработана методика моделирования процесса интеграции на основе использования информационно-программных эмуляторов интегрируемых подсистем.
Разработана модель информационно-программного эмулятора на основе использования сетей Петри.
Разработано экспериментальное приложение, в котором продемонстрированы разработанные методы на примере моделирования процесса интеграции процессинговых систем.
Для решения поставленных задач в диссертации использованы методы моделирования программных систем с помощью сетей Петри, методы и средства объектно-ориентированного проектирования и программирования. Для реализации экспериментального приложения использованы средства реляционных и постреляционных баз данных и XML-технологии.
В диссертации получены следующие новые научные результаты:
Разработана методика моделирования процесса интеграции на основе использования информационно-программных эмуляторов интегрируемых подсистем.
Разработаны модели и средства для построения программной и информационной компоненты для моделирования процесса интеграции.
Основные научные результаты, выносимые на защиту:
Предлагаемая методика моделирования процесса интеграции на основе использования информационно-программных эмуляторов интегрируемых подсистем.
Модели и средства для построения программной и информационной компоненты для моделирования процесса интеграции.
Разработанные в диссертации методики и модели процесса интеграции на основе использования информационно-программных эмуляторов интегрируемых подсистем использованы в учебном процессе кафедры «Кибернетика» МИФИ в курсе для студентов Союза Мьянма «Современные методы и средства проектирования информационных систем» и подготовке диссертаций на соискание степени магистра.
Во введении обоснована актуальность темы диссертации, её научная новизна и практическая значимость, сформулирована цель работы.
В первом разделе диссертации рассматриваются современные тенденции развития технологий интеграции информационных систем, роль и место моделирования и тестирования в процессе интеграции. Рассматриваются виды тестирования. Приведен подход к моделированию информационной системы на примере подсоединения нового банка к международной платежной сети VISANET. В конце первого раздела диссертации поставлена цель и конкретные задачи диссертационного исследования.
Во втором разделе диссертации проанализированы модели взаимодействия интегрируемых подсистем на базе раскрашенных сетей Петри для отработки протоколов взаимодействия подсистем, отработки сценариев взаимодействия и т.д. Рассмотрено взаимодействие двух информационных подсистем, при котором одна из них работает в режиме клиента, то есть инициирует запросы к другой подсистеме, а вторая - в режиме сервера, то есть отвечает на поступающие запросы. Предлагается метод построения модели взаимодействующих подсистем, как в режиме клиента, так и в режиме сервера. Построенные модели используются для подмены одной из подсистем при отработке протоколов их взаимодействия.
Третий раздел диссертации посвящен технологическим вопросам реализации эмулятора. Первый вопрос, который обязательно надо решить, это вопрос о коммуникации эмулятора с удаленной интегрируемой подсистемой. С этой целью анализируется интерфейс сокетов и показывается, что интерфейс WinSock позволяет реализовать все функции, необходимые для функционирования эмулятора. Второй, не менее важный вопрос, связан с выбором СУБД для хранения тестовой базы данных. Так как в современных условиях технология интеграции, в основном, ориентируется на обмен XML-сообщениями между интегрируемыми подсистемами, СУБД должна быть ориентирована на эффективную работу с текстовой информацией и хранение многозначных полей переменной длины. Однако в ряде случаев использование СУБД,
поддерживающей реляционную модель данных, также позволяет эффективно реализовать все функции хранения и доступа к тестовым данным.
Четвертый раздел диссертации посвящен экспериментальной проверке предлагаемой методики путем построения эмулятора процессинговой системы, работающего в режиме клиента (Acqu і г е) ив режиме сервера (I s s ue г), и моделированию взаимодействия процессинговых систем по протоколу ISO 8583 при объединении их в локальную платежную сеть раскрашенными сетями Петри. Архитектура эмулятора построена на базе шаблона MVC, что позволило реализовать два варианта контроллера, и общую модельную часть. Контроллеры ориентированы на функциональное и нагрузочное тестирование интегрируемых подсистем. «Модель» эмулятора выполнена в виде совокупности «команд», которые реализуют различные функциональные преобразования и извлечение тестовых данных из СУБД. При взаимодействии процессинговых систем, с целью получения максимальной компактности сообщений используются специальные структуры сообщений, и специальные форматы полей (ISO 8583). Это потребовало реализации специальной «команды» формирования сообщений и разработки специального редактора для формирования тестовой базы данных.
В заключении приводятся основные выводы и результаты диссертации.
Достоверность полученных результатов подтверждается как экспериментами на моделях интеграции, когда взаимодействующие подсистемы заменены их эмуляторами, так и экспериментами с заменой эмулятором одной из подсистем.
Основные результаты диссертации докладывались и обсуждались на ежегодных научных сессиях МИФИ (2004, 2005, 2006, 2007 гг.) и на международном научно-техническом семинаре «Современные технологии в задачах управления, автоматики и обработки информации» (2005,2006 гг).
Основные результаты диссертации опубликованы в тезисах докладов на научных сессиях МИФИ и международном научно-техническом семинаре «Современные технологии в задачах управления, автоматики и обработки информации».
Основы интеграции с использованием XML и web-сервисов
Рассмотрим базовые понятия, связанные с подходом к организации взаимодействия и интеграции информационных подсистем с помощью web-сервисов.
Первое, что следует отметить, - этот подход к интеграции связан с использованием открытых стандартов, в их разработке принимают участие такие ведущие 1Т-компании, как Microsoft и IBM, а также органы стандартизации интернет сообщества в лице консорциума W3C [12,13] и 0ASIS[12].
Первый пункт определяет второй: данные технологии не зависят от платформы и не требуют от предприятий, чьи подсистемы интегрируются, использовать идентичные операционные системы и СУБД.
В основе этого подхода лежит XML - мета-язык для представления данных. Термин «мета» используется потому, что XML-документ не только содержит в себе данные, но также несет информацию, описывающую эти данные. XML является такой же универсальной и базовой технологией для представления, трансформации и обмена данными, как транспортный протокол TCP/IP для Интернета.
XML предоставляет общий формат для пересылки данных между подсистемами. При этом сами данные могут по-прежнему храниться в базах данных во внутренних форматах СУБД, используемых для управления этими базами, но в случае необходимости их пересылки в другую подсистему они будут трансформироваться в формат XML, как в промежуточный формат, понимаемый всеми. Уже сегодня стандарт XML поддерживается поставщиками основных программных продуктов, в том числе и СУБД.
Подход к интеграции на базе web-сервисов не устраняет необходимости в использовании программного обеспечения промежуточного слоя для пересылки сообщений, поскольку поток XML-документов должен быть соответствующим образом маршрутизирован и, при необходимости, трансформирован для того, чтобы быть понятым целевой подсистемой.
Так как XML-документы имеют текстовый формат и могут анализироваться сетевыми экранами, они могут проходить за границы предприятий. Это значит, что XML предлагает единое решение как для интеграции в пределах корпоративных подсистем (EAI), так и для В2В-интеграции предприятий [35].
Передовые продукты интеграции класса систем управления бизнес-процессами (ВРМ), такие как Microsoft BizTalk Server, не только используют XML как формат обмена данными, но также используют синтаксис языка XML для описания бизнес-логики, контроля маршрутов и потоков прохождения сообщений и документов. Microsoft, IBM и ряд других поставщиков разработали язык Business Process Execution Language for Web Services (BPEL4WS) [8,13,14] в качестве стандартного языка описания бизнес-процессов, в основе которого лежит XML. Новые подсистемы, разработанные с использованием этого языка, легче интегрировать в общие бизнес-процессы, а логика бизнес-процессов становится более доступной для модификации.
Развитие этого подхода неизбежно приведет к тому, что новые прикладные подсистемы все в большей степени будут разрабатываться как web-сервисы, то есть компоненты, функциональные возможности которых доступны для пользователей и других подсистем по сети интернет/интранет. Это требует более глубокого анализа потребностей других прикладных подсистем, что может быть реализовано в рамках анализа бизнес процессов и выполнения потоков работ как цепочек взаимосвязанных служб.
Рассмотрим процесс взаимодействия подсистем в децентрализованной, распределенной среде. При разработке подсистемы, которой требуется доступ к web-сервису, используется регистр UDDI [13,14] или внутренний регистр предприятия для поиска необходимого web-сервиса. В этом регистре должны быть опубликованы все необходимые для взаимодействия интерфейсы. Для этих целей разработан язык WSDL [13,14]. При функционировании, подсистема вызывает web-сервис и отправляет ему XML-сообщение, используя SOAP[14] конверт и протокол HTTP в качестве транспорта для доставки.
Ниже перечислены основные принципы применения XML и web-сервисов для организации взаимодействия подсистем в децентрализованной, распределенной среде: В качестве основного механизма интеграции используется web-сервис. В качестве стандарта обмена данными используется XML. Осуществляется «слабое связывание» информационных подсистем на основе пересылки сообщений в виде XML-документов. Организуется отраслевой, региональный или корпоративный регистр для публикации web-сервисов. Эти регистры создаются на базе стандарта UDDI (OASIS).
Сеть Петри для подсистемы-клиента и подсистемы-сервера
Прежде чем рассматривать вопрос о моделировании взаимодействия интегрируемых подсистем на базе сетей Петри, рассмотрим с самых общих позиций структуру программы-эмулятора, которая используется для замены одной из подсистем.
Программа-эмулятор - это достаточно сложная программа, которую целесообразно строить на основе взаимодействия процессов. Фактически - это целый программный комплекс, предназначенный для решения конкретной задачи моделирования. Каждый из процессов использует для решения задачи либо свои собственные данные и обменивается с другими процессами только результатом своей работы, либо работает с общей областью данных, разделяемых между разными процессами [31].
В основу архитектуры программы-эмулятора целесообразно положить шаблон Model-View-Controller (MVC) [37]. В этой архитектуре (Рис. 2.1) контроллер (Controller) отвечает за логику моделирования, то есть за последовательность действий эмулятора, различные команды модели (Model) - за те или иные функциональные преобразования, а представление (View) - за вывод пользователю результатов моделирования.
Архитектура программы-эмулятора в стиле шаблона MVC
Логику программ, построенных на основе взаимодействия процессов, очень удобно моделировать, используя раскрашенные сети Петри [19,20,21]. Если программа-эмулятор построена в стиле шаблона MVC, то сети Петри дают возможность построить целую гамму ее моделей, начиная от использования простых сетей Петри для моделирования логики контроллера, до построения полного ее аналога в виде раскрашенной сети, в которой раскрыты все команды, выполняющие функциональные преобразования. Заметим, что построенная таким образом сеть Петри является и моделью интегрируемой подсистемы и ее вполне можно использовать в связке с реальной подсистемой при отработке их взаимодействия. Единственное, что ограничивает подобной применение -быстродействие сети.
Сеть Петри для подсистем ы-клиента
Построим сеть Петри для одного из вариантов контроллера MVC для эмулятора подсистемы-клиента. Рассмотрим простейший вариант, когда контроллер последовательно запускает процессы, связанные с формированием запроса, затем запускает процесс, который отправляет сформированный запрос серверу, и ждет ответа. 4r»:-j;tb;!iniji!.a Рис. 2.2. Сеть Петри, моделирующая последовательный алгоритм контроллера для подсистемы-клиента.
На Рис. 2.2 представлена сеть Петри с вариантом разметки, которая моделирует отработку тесткейса в режиме подсистемы-клиента. Сеть имеет 12 позиций и 7 переходов. Позиции: 1. Позиция «Test Case». В начале моделирования позиция содержит N фишек, по числу шаблонов отрабатываемого тесткейса. Каждое срабатывание перехода «Get Transac» уменьшает число фишек в этой позиции на 1. 2. Позиция «Next Send». В начале моделирования позиция содержит 1 фишку, определяющую запуск сети. 3. Позиция «Current Transac» получает фишку в результате срабатывания перехода «Get Transac». Соответствует шаблону запроса. 4. Позиция «Message» получает фишку в результате срабатывания перехода «Create Message». Соответствует сформированному запросу. 5. Позиция «Outgoing Msg», Соответствует отправленному запросу.
СУБД для эмулятора
Что касается данных предметной области, то есть данных интегрируемых подсистем, то это с очень большой вероятностью реляционные таблицы небольших размеров, подготовка которых определяется конкретной ситуацией. Поэтому основное внимание следует уделить второй составляющей, а именно подготовке шаблонов сообщений и организации их хранения.
Протокол взаимодействия интегрируемых подсистем определяет конечное число типов сообщений. Каждый тип сообщения определяется на множестве полей, перечень которых задается либо международным стандартом, либо отраслевым стандартом, либо стандартом предприятия. В силу того, что практически повсеместно принят в качестве стандарта обмен XML-сообщениями, целесообразно определить структуру типов сообщений с помощью DTD или XML схемы. XML схема более подходит для этих целей, так как она детально определяет форматы полей и поэтому может быть эффективно использована на этапе синтаксического анализа.
Однако следует иметь в виду, что в предлагаемой методике моделирования сообщения не хранятся в базе данных, они формируются непосредственно перед отправлением. Шаблоны сообщений, которые существенно проще самих сообщений, могут храниться и в других структурах.
Детализируем схему, представленную на рис. 2.5. Тест TestID Данные, общие для всех шаблонов теста Тесткейс TestCaselD Данные, общие для всех шаблонов тесткейса Шаблон ответа сервера ResServID Поля шаблона ответа сервера / Шаблон проверки ответа сервера ResCheckID Поля шаблона проверки ответа сервера / Шаблон запроса клиента ReqClientID Поля шаблона запроса клиента Рис. 3.3. Вариант схемы базы данных для хранения шаблонов сообщений.
Схема, представленная на рис. 3.3, вполне работоспособна. На ней каждая вертикальная связь выражает отношение типа 1 :N, а каждая горизонтальная - отношение типа 1:1. Однако, если учесть, что все типы сообщений имеют, в общем случае, разные поля по номенклатуре и количеству, то возникают сомнения в ее реализуемости соответствующими реляционными таблицами. Слишком много пустых полей может быть в этих таблицах. Такие структуры эффективно поддерживаются в СУБД типа D3 {39], к тому же СУБД D3 очень эффективно работает с текстовыми полями переменной длины, что очень характерно для базы шаблонов. Аналогичные рассуждения можно сделать относительно СУБД Cache [40], однако их применение целесообразно только в случае достаточно объемных тестовых баз.
Если, все же, ориентироваться на реляционные таблицы, и, например, на реляционную СУБД типа MS Access [41,42], то возможны два варианта: Для шаблонов сообщений одного типа организовать отдельную таблицу; Организовать хранение полей сообщения в соответствии с их номерами (именами). В каждом варианте следует декомпозировать третий слой в иерархии, представленной на рис 3.4. Если декомпозировать таблицу ReqClientID Поля шаблона запроса клиента и организовать хранение полей сообщения в соответствии с типами сообщений в соответствующем стандарте, то получим следующую схему:
Шаблон запроса клиента ReqClientID MessaqeType RecMesID Рис. 3.4. Развитие схемы базы данных для хранения шаблонов сообщений. Однако при данном варианте декомпозиции требуется создавать столько дополнительных таблиц, сколько типов сообщений: MessaqeType RecMesID Поля шаблона запроса клиента Схема таблицы фиксирует стандартную структуру сообщения заданного типа, при этом поле FieldStatus имеет обычно два значения: «Обязательное» и «Необязательное» Если декомпозировать таблицу
ReqClientID Поля шаблона запроса клиента и организовать хранение полей сообщения в соответствии с их номерами (именами) в соответствующем стандарте, то получим следующую схему: Шаблон запроса клиента ReqClientID Данные, общие для всех полей шаблона Поля шаблона запроса FieldNum JFieldValue
Рис. 3.5 Развитие схемы базы данных для хранения шаблонов сообщений.
Схема, представленная на рис 3.5 является очень гибкой. Добавление и удаление полей из шаблона сообщения любого типа выполняется очень просто, что существенно при отработке протоколов. Однако при данном варианте декомпозиции требуется создавать дополнительную таблицу: FieldNum MessageType FieldStatus Эта таблица необходима для фиксации стандартной структуры сообщения заданного типа, при этом поле FieldStatus имеет обычно два значения: «Обязательное» и «Необязательное» Несмотря на то, что вариант создания таблиц по типам сообщений проще, при реализации экспериментального эмулятора была выбрана схема базы данных с
Модуль для подсистемы-клиента (Acquire)
В моделируемом процессе запросы не различаются по типам, то есть представляют практически однородные заявки, которые различаются только идентифицирующим номером. Клиент посылает запрос и ждет заданное время получение ответа.
Если ответ не приходит в заданное время или не проходит синтаксический и семантический контроль, то посылается запрос с тем же идентификационным номером. Если ответ приходит в заданное время и проходит синтаксический и семантический контроль, то идентификационный номер увеличивается на единицу. Таким образом, считается, что ответ на запрос получен только в том случае, если ответ приходит в заданное время и проходит синтаксический и семантический контроль. В любом другом случае посылается повторный запрос.
Рассмотрим смысл условий и событий, происходящих в модуле. Условия, моделируемые позициями: send - посылаемые сообщения, A (Out) - выходная позиция модуля, D (In) - входная позиция модуля, Response - полученный ответ (до синтаксического анализа), Syntax Checked -ответ, прошедший синтаксический анализ, Received Response - ответ, прошедший семантический анализ, АСК - событие - ответ на запрос получен Current MsgNo - текущий номер сообщения, Next Try-следующее сообщение, Count - счетчик, Limit - норма времени, Тimeout - таймаут. События, моделируемые переходами:
Send Message - посылка сообщения, Get Response - получение сообщения, Syntax Check - синтаксический анализ, Semantic Check- семантический анализ, Clock Tick - включение таймера, Alarm - заканчивается время ожидания, Retry - повторная посылка сообщения.
В соответствии с правилами функционирования, временная сеть Петри срабатывает по тактам (тикам) [29]. Такту срабатывания можно сопоставить некоторый промежуток времени. В представленной на рис. 4.3 сети, на первом такте может сработать переход «Send Message», если исходная разметка помещает фишку в позицию «Next Try». Когда переход действительно произойдет, по одной фишке будет помещено в позиции А и Count. Выполнится условие, дающее возможность сработать переходу «Get Response», как только будет получен ответ от процесса Issuer. Описанный процесс продолжится, аналогичным образом сработают переходы Retry, Clock Tick и Alarm. Описание сети для моделирования представлено следующими множествами «цветов», переменными и функциями. colset INT = int timed; colset Tranc=string; colset TestCase=product INT Tranc timed; var wait,n: INT; var trans:Tranc; colset NetDelay = int with 25..75; fun DEL() = NetDelay. ran () ;
Рассмотрим результаты моделирования сети, представленной на рис. 2.2. В результате моделирования получается log файл, хранящий всю информацию о выполненных переходах, на каком шаге и в какое системное время фишки входили в каждую позицию. В таблице 4.1 представлен обработанный фрагмент log-файла.
Из таблицы 4.1 видно, что сообщение Transaction!., было обработано за 19 шагов, при этом было затрачено 388 тиков времени, сообщение Transaction2 было обработано за 7 шагов, при этом было затрачено 85 тиков времени и т.д. Этот log файл получен при моделировании сети при вероятности потери сообщения равной 40%. Разделив общее время моделирования на количество обработанных транзакций, получим среднее время обслуживания одного сообщения. На Рис. 4.6,а представлены результаты моделирования сети Петри, которая представляет работу клиента, при которой сервер был заменен переходом «Outer_World» со случайным временем срабатывания. На горизонтальной оси указана вероятность потерь сообщения в процентах, а на вертикальной - среднее время обслуживания одного сообщения (в тиках
