Дипломная работа: Интеграция компонентов портала для проведения лингвистических исследований

Язык BPEL

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

Язык XPDL

Основным противником BPEL является выдвигаемый консорциумом WfMC язык XPDL, хотя сам WfMC дробит области применения двух языков и даже определяет их 77 взаимодополняющими. XPDL был создан для сохранения и передачи диаграммам бизнес-процессов между программными решениями, один из которых предопределен для имитирования процесса, другой для чтения и редактирования, третий для выполнения процесса внутри BPMS, поддерживающей XPDL [11].

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

1.5 Анализ существующих инструментальных средств по управлению взаимодействия сервисов

Система Serena Business Manager

Serena Business Manager (SBM) - платформа для управления бизнес-процессами предприятия любого масштаба и организации эффективного взаимодействия сотрудников и рабочих групп в рамках выполнения ими процессов, направленных на достижение стратегических целей компании (рис. 1.6).

Рисунок 1.6. Serena Business Manager

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

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

Система Oracle BPEL Process Manager

Oracle BPEL Process Manager это инструмент для создания и исполнения бизнес-процессов. Данное редство предоставляет комплексную и базированную на открытых стандартах методологию к созданию, разворачиванию и координации сквозными бизнес-процессами, которые могут располагать в себе как задачи для пользователей, так и автоматические действия (рис. 1.7).

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

Рисунок 1.7. Oracle BPEL Process Manager

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

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

Система Ansible

Ansible -- программный продукт без клиентской части с открытым исходным кодом для удаленной координации конфигурациями, созданное Майклом Де Хаанном в 2012 году

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

Рисунок 1.8.Пример сценария для Ansible

Преимущества такого решения - оно является открытым. Затраты на интеграцию в систему будут минимальными.

К недостаткам можно отнести тот факт, что решение имеет ряд недоработок и не является универсальным инструментом управления

Сравнение инструментов по критериям

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

Универсальное решение.

Низкие затраты на внедрение инструмента.

Наличие открытого кода.

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

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

Представим результаты сравнения в таблице (таблица 1.1).

Таблица 1.1 - Итоги сравнения инструментальных средств

1.6 Технология Windows Workflow Foundation

В разрабатываемом координаторе модуль редактирования бизнес-процессов будет реализован с использованием технологии Windows Workflow Foundation (WWF) [12]. Данная технология позволяет управлять рабочими процессами с помощью трех основных типов процессов: последовательный процесс, конечный автомат и процесс, управляемый правилами. Пример рабочего процесса продемонстрирован на рисунке 1.9.

Рисунок 1.9.Пример рабочего процесса в WWF

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

1.7 Технология Windows Presentation Foundation

Интерфейсная часть координатора будет выполнена при использовании технологии Windows Presentation Foundation (WPF) [13]. WPF в сочетании с WWF позволяет настраивать элементы управления при разработке в нужном виде для разработчика. Такие настройки элементов управления делают редактирование процессов универсальным и абстрагированным от конкретной предметной области.

1.8 Технология Windows Communication Foundation

Модуль интерпретации будет использовать Windows Communication Foundation (WCF) [14]. Данная технология позволяет создавать веб-сервисы, отличительной чертой которых является поддержка сессий. Такой подход способен осуществлять многопользовательскую работу в системах, примером которой является лингвистический портал. Использование данного подхода позволяет создать универсальный инструмент.

1.9 Порт фреймворка log4net

В модуле интерпретации есть необходимость в проверке выполнения рабочих процессов. Для этого необходим инструмент логирования, который бы позволял отслеживать этапы вызовов методов сервисов. Таким инструментом будет являться порт фреймворка log4net [15]. Такой порт совмещает в себе ряд преимуществ фреймворка Apache log4j с новыми возможностями .Net платформы. Пример результата логирования отображен на рисунке 1.10.

Рисунок 1.10. Пример логирования с помощью log4net

1.10 Выводы по главе

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

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

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

2.1 Формализация требований

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

Рисунок 2.1. Текущая архитектура портала

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

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

Рисунок 2.2. Диаграмма прецедентов

Опишем в расширенном виде каждый прецедент, чтобы понимать действия акторов и реакцию сервиса на эти действия:

Название: Добавление компонента.

Акторы: Администратор.

Краткое описание: администратор добавляет по ссылке компонент портала в редактор бизнес-процессов

Триггер: открыть редактор бизнес-процессов портала.

Взаимодействие актора с системой описано в таблице 2.1.

Таблица 2.1 - Развернутое описание прецедента «Добавление компонента»

Название: Удаление компонента.

Акторы: Администратор.

Краткое описание: администратор удаляет компонент из редактора бизнес-процессов

Триггер: открыть редактор бизнес-процессов портала, добавить компонент.

Взаимодействие актора с системой описано в таблице 2.2.

Таблица 2.2 - Развернутое описание прецедента «Удаление компонента»

Название: Добавление бизнес-процесса.

Акторы: Администратор.

Краткое описание: администратор создает бизнес-процесс из методов добавленных компонентов.

Триггер: открыть редактор бизнес-процессов портала, добавить компоненты.

Взаимодействие актора с системой описано в таблице 2.3.

Таблица 2.3 - Развернутое описание прецедента «Добавление бизнес-процесса»

Название: Изменение бизнес-процесса.

Акторы: Администратор.

Краткое описание: администратор изменяет бизнес-процесс.

Триггер: открыть редактор бизнес-процессов портала, добавить компоненты, добавить бизнес-процесс.

Взаимодействие актора с системой описано в таблице 2.4.

Таблица 2.4 - Развернутое описание прецедента «Изменение бизнес-процесса»

Название: Удаление бизнес-процесса.

Акторы: Администратор.

Краткое описание: администратор удаляет бизнес-процесс.

Триггер: открыть редактор бизнес-процессов портала.

Взаимодействие актора с системой описано в таблице 2.5.