Пермский филиал федерального государственного автономного
образовательного учреждения высшего образования
«Национальный исследовательский университет
«Высшая школа экономики»
Факультет экономики, менеджмента и бизнес-информатики
Выпускная квалификационная работа
студента образовательной программы «Программная инженерия»
по направлению подготовки 09.03.04 Программная инженерия
Интеграция компонентов портала для проведения лингвистических исследований
Каликова Анастасия Рамилевна
Рецензент к.т.н., доцент, доцент кафедры программного обеспечения вычислительной техники и автоматизированных систем А.В. Греков
Руководитель к.ф.-м.н., доцент, доцент кафедры информационных технологий в бизнесе Е.Б. Замятина
Пермь, 2018 год
Аннотация
В работе описывается процесс разработки координатора бизнес-процессов web-портала для проведения лингвистических исследований. В тексте представлены анализ предметной области, формализация требований, проектирование интегратора бизнес-процессов, реализация интегратора. Также был описан процесс тестирования готового продукта и представлены пути дальнейшего развития.
Работа содержит 63 страницы, 3 приложения, 30 изображений.
2018 г. Кафедра информационных технологий в бизнесе.
бизнес лингвистический интегратор проектирование
Оглавление
Введение
Глава 1. Анализ предметной области коммуникаций компонентов в информационных системах
1.1 Анализ архитектурных решений
1.2 Анализ шаблонов взаимодействия
1.3 Анализ стандартов управления событиями
1.4 Анализ языков моделирования бизнес-процессов на базе XML
1.5 Анализ существующих инструментальных средств по управлению взаимодействия сервисов
1.6 Технология Windows Workflow Foundation
1.7 Технология Windows Presentation Foundation
1.8 Технология Windows Communication Foundation
1.9 Порт фреймворка log4net
1.10 Выводы по главе
Глава 2. Формализация требований к разрабатываемому координатору сервисов и его проектирование
2.1 Формализация требований
2.2 Обоснование трудоемкости разработки
2.3 Техническое задание
2.4 Проектирование координатора сервисов портала
Глава 3.Реализация и тестирование координатора сервисов 2
3.1 Реализация редактора бизнес-процессов
3.2 Реализация интерпретатора бизнес-процессов
3.3 Работа координатора на примере композиций сервисов
3.4 Публикация сервиса
Заключение
Библиографический список
Приложения
Введение
На сегодняшний день многие информационные системы выполняют ряд сложных функций, использующих трудоемкие вычисления. Для оптимизации работы часть компонентов перемещается в Интернет. Примером такой системы является лингвистический портал, разрабатываемый в рамках проекта «Разработка программного обеспечения для проведения корпусных исследований английского языка» [1]. Главными задачами портала являются анализ научной речи и упрощение преподавания английского языка для академических целей [2,3].
Архитектура лингвистического портала содержит различные компоненты, среди которых: хранилище корпусов, компонент разметки корпуса, компонент сбора статистики, компонент по взаимодействию с пользователем, тонкий клиент и т.д. Эти компоненты, взаимодействуя между собой, должны взаимодействовать с использованием единой модели коммуникации. В сильно связанных архитектурах при изменении одного из компонентов иногда приходится модифицировать некоторые интегрированные с ним компоненты системы, что показывает недостаток текущей архитектуры портала, а именно не полную автономность компонентов.
Портал является гетерогенным, так как компоненты реализованы в разных средах разработки и выполняют только одну конкретную задачу. При взаимодействии компонентов нужно контролировать возникающие связи между ними при передаче сообщений и данных. Поэтому система должна работать корректно вне зависимости от того, реализован ли компонент на платформе .Net Framework или использует GATE Developer для аннотирования и язык сценариев Jape и т.п.
Также нужно отметить, что автономность компонентов влияет на их коммуникацию, требуя от системы процессно-ориентированного взаимодействия и сервис-ориентированной архитектуры [4,5]. Такой подход выстраивает вызовы компонентов в определенном порядке для решения тех или иных задач пользователя. В рамках разработки появляется проблема отсутствия корректного взаимодействия всех компонентов портала как единой системы. Так как разрабатываемый лингвистический портал может в дальнейшем расширяться в своих функциональных требованиях, то возникает потребность в разработке сервиса, который при выполнении интеграции компонентов портала учитывает, что могут появляться новые компоненты.
Объектом данного исследования является архитектура порталов. Предметом исследования являются методы взаимодействия компонентов в сервис-ориентированной архитектуре.
Целью данного исследования является проектирование и реализация интеграции компонентов портала для проведения лингвистических исследований.
Для достижения поставленной цели необходимо решить следующие задачи:
Выполнить анализ существующих методов интеграций компонентов информационных систем с сервис-ориентированной архитектурой; определить методы, которые будут использоваться в разрабатываемом сервисе.
Сформулировать требования к разрабатываемому программному продукту; выполнить проектирование сервиса интеграции и описать его место в общей архитектуре лингвистического портала;
Выполнить программную реализацию сервиса; провести тестирование, отладку полученного инструментального средства, выполнить его доработку и разработать документацию пользователя и программиста.
В области управления web-сервисами на сегодня существует несколько подходов к интеграции компонентов системы в сервис-ориентированной архитектурой. Среди них общая база данных, обмен файлами, удаленный вызов и асинхронный обмен сообщениями. У данных подходов есть ряд своих преимуществ и ограничений. В рамках данного исследования проведен сравнительный анализ данных методов [6], сделан выбор в пользу управляемой событиями модели доставки данных без запроса, а также проведен анализ языков моделирования бизнес-процессов на базе XML [7] и выбор модели, которая используется для проведения интеграции компонентов портала.
Работа состоит из 3 глав. В первой главе рассмотрены существующие решения, позволяющие осуществлять передачу данных между компонентами системы, и выбор инструментария в рамках выбранного решения. Также сформулированы требования к разрабатываемому сервису. Вторая глава содержит описание этапа проектирования сервиса и его место в архитектуре портала. В третьей главе описан процесс реализации, а также - подробный процесс тестирования сервиса.
Глава 1. Анализ предметной области коммуникаций компонентов в информационных системах
На первом этапе реализации проводится анализ предметной области: анализ возможных архитектурных решений, шаблонов взаимодействия; рассматриваются протоколы управления событиями, а также существующие программные подходы решения проблемы и ограничения этих подходов.
1.1 Анализ архитектурных решений
Так как лингвистический портал должен быть расширяемым, была выбрана сервис-ориентированная архитектура, позволяющая системе дополняться независимыми гетерогенными модулями. Из этого следует, что в самом начале этапа анализа необходимо определиться с архитектурным шаблоном портала.
Многоуровневый шаблон архитектуры
Данный подход подразумевает разбивку системы на уровни, каждый из которых выполняет свою логику (рис. 1.1).
Рисунок 1.1. Многоуровневый шаблон архитектуры
Преимуществом такого разбиения является тот факт, что каждый уровень легче модифицируется в соответствии со своей логикой. Недостатками такого подхода заключается в затруднении понимания системы и понижении производительности.
Архитектурный шаблон посредника (mediator)
Данный подход определяет связывающее звено между большим количеством составляющих системы. Отбрасывается потребность в организации прямого связывания модулей между собой, что в свою очередь повышает функциональную связность компонентов системы. Также этот шаблон позволяет без значительных усилий подключать новые модули, определяя их роль в системе.
Недостатки такого шаблона заключаются в наличии самого посредника. Сбои в работе такого звена могут привести к недоступности всей системы.
Архитектурный шаблон «Модель-Представление-Контроллер»
В подходе MVC (Model-View-Controller) логика работы с данными и пользовательским интерфейсом разделена (рис. 1.2).
Рисунок 1.2. Шаблон «MVC»
Наличие такого разделения позволяет модифицировать интерфейсы, а также генерировать их различные варианты. Однако недостатком такой концепции является падение скорости функционирования системы из-за усложнения коммуникации в логике.
Клиент-серверный шаблон архитектуры
Клиент-серверный шаблон бывает полезен в системах, где пользователи имеют доступ к лимитированному числу ресурсов. Такой подход увеличивает расширяемость и гибкость системы. Но при этом сервер может стать слабым звеном системы, при его отсутствии становится неработоспособна вся система.
1.2 Анализ шаблонов взаимодействия
Следующий шаг заключается в анализе шаблонов взаимодействия модулей в системах. Данный анализ позволит определить пару архитектурный шаблон-шаблон взаимодействия, которая в наибольшей степени удовлетворяет требованиям лингвистического портала.
Управляемая событиями модель доставки данных без запроса
Данная концепция определяет, что в системе должны быть модули-слушатели, которые ожидают наступления событий от пользователя. Доставляемые события запускают соответствующие обработчики событий, которые в свою очередь позволяют выполнить определенный шаблон действий (рис. 1.3).
Рисунок 1.3. Управляемая событиями модель доставки данных без запроса
Синхронный режим запрос/ответ
Некоторые системы требуют в своей бизнес-логике строгое соблюдение изоляции и координации транзакций, где необходимо дожидаться ответа вызываемого компонента. В данной модели пользователи сами могут контролировать простои в своей работе в рамках сессии, что позволяет ускорить работу системы и быстро локализировать сбои (рис. 1.4).
Рисунок 1.4. Синхронный режим запрос/ответ
Асинхронная модель
Данная концепция придерживается стиля «запустил и забыл». После действия пользователь продолжает работать с системой, параллельно с этим происходит обработка пользовательского запроса. Такая модель ответов, которая может только информировать, очень редко используется при работе с сервисами. Поддерживается такой шаблон взаимодействия без каких-либо усилий (рис. 1.5).
Рисунок 1.5. Асинхронная модель
1.3 Анализ стандартов управления событиями
Предметная область портала показывает, что порядок вызовов компонентов в ответ на действия пользователей определены, поэтому лучший вариант для системы это использование шаблона «Посредник» с использованием модели, управляемой событиями. Следующий шаг подразумевает анализ принятых стандартов в рамках выбранных шаблонов по процессно-ориентированному взаимодействию.
Стандарт WSFL
WSFL (Web Service Flow Language) - стандарт, разработанный Microsoft, позволяющий описывать как публичные, так и частные процессы [8]. При таком стандарте нет модуля, отвечающего за обмен сообщениями. Каждый модуль является независимым участником процесса, где организацию обмена сообщений выполняет новый экземпляр потока участника (модуля), инстанциирующего данный поток. Данную концепцию называют «хореографией» сервисов. Языки, описывающие такое взаимодействие и входящие в этот стандарт: WS-CDL (Web Service Choreography Description Language) и ebXML (Electronic Business using eXtensible Markup Language).
Стандарт BPEL4WS
BPEL4WS (Business Process Executive Language For Web Service) - стандарт, разработанный Microsoft, IBM, Siebel, BEA Systems и SAP, выполняющий оркестровку сервисов [9]. Под оркестровкой здесь понимается, что существует исполняемый процесс, позволяющий организовывать взаимодействие бизнес-процессов внутри системы. Остальные участники также являются независимыми, но друг с другом напрямую не общаются. Языки, описывающие такое взаимодействие и входящие в этот стандарт: BPEL (Business Process Executive Language) и XPDL (XML Process Definition Language).
1.4 Анализ языков моделирования бизнес-процессов на базе XML
При взаимодействии модулей системы независимо от того, какой шаблон они используют для этого, необходимо корректно описывать порядок вызова модулей в рамках текущего бизнес-процесса. Для этого существуют определенные языки описания и моделирования бизнес-процессов. Проведем анализ языков, осуществляющих оркестровку модулей системы.