Обзор архитектуры

Этот раздел перенесён из документации Camunda 7 и в дальнейшем будет доработан с учётом особенностей OpenBPM Engine

OpenBPM Engine — это базурующийся на Java фреймворк. Его главные компоненты написаны на Java, а наш основной фокус состоит в том, чтобы предоставить Java разработчикам инструменты, необходимые им для проектирования, разработки и выполнения бизнес процессов и рабочих алгоритмов на JVM. Тем не менее, мы также хотим сделать технологию нашего движка управления процессами доступной для тех разработчиков, которые пишут не на Java. Именно поэтому OpenBPM Engine также предоставляет REST API, который позволяет вам разрабатывать приложения, подключающиеся к удаленному движку процессов.

OpenBPM Engine может использоваться как отдельный сервер для движка управления процессами, так и в качестве втроенного движка внутри разработанных на Java приложений польщователя. Требование встраиваемости является центральным фактором многих архитектурных решений в рамках OpenBPM Engine. Например, мы много работаем над тем, чтобы наш движок имел малый вес и использовал как можно меньше зависимостей от библиотек третьих сторон. Более того, требование встраиваемости мотивирует наш выбор по программным моделям, например, способность движка участвовать в Spring Managed или JTA транзакциях и поточной модели.

Архитектура движка

Архитектура движка

  • Публичный API движка управления процессами: Ориентированный на сервис API, позволяющий Java приложениям взаимодействовать с BPM движком. Различные зоны ответственности движка (а именно, репозиторий процессов, взаимодействие процессов в рантайме, управление задачами и т.д.) выделены в отдельные сервисы. Публичный API предлагает паттерн доступа в стиле выполняемых команд: потоки, входящие в движок управления процессами, перенаправляются в Command Interceptor (перехватчик команд), который используется для установки контекста потока, например, "транзакции".

  • Ядро движка BPMN 2.0: Это ядро движка управления процессами. Оно включает легкий движок для структур типа граф (PVM - Process Virtual Machine, виртуальная машина процессов), а также парсер BPMN 2.0, преобразующий XML файлы BPMN 2.0 в Java объекты. В ядро также входят реализации BPMN поведений (здесь предоставляются реализации BPMN 2.0 конструктов, таких как шлюзы (Gateways) и сервисные задачи (Service Tasks)).

  • Job Executor: Job Executor отвечает за обработку асинхронной работе в фоновом режиме, например, работу таймеров и асинхронное выполнение задач в процессе.

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

Обязательные библиотеки от третьих сторон

См. раздел о библиотеках третьих сторон.

Архитектура OpenBPM Engine

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

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

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

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

Разделенный движок управления процессами, управляемый через контейнер

Разделенный движок управления процессами

В этом случае движок стартут внутри рантайм-контейнера (сервлет контейнер, сервер приложений, и т.д.). Движок управления процессами предоставляется как сервис контейнеров и может быть разделен между всеми приложениями, запущенными внутри контейнера. Эта концепция сравнима с JMS Message Queue, которая предоставляется в рантайме и может использоваться всеми приложениями. Существует маппинг один к одному между деплойментами процессса и приложениями: двидок следит за определениями процесса, запущенными приложением, и делегирует выполнение тому же приложению.

Автономный (удаленный) сервер движка управления процессами

Автономный движок управления процессами

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

Модель кластеризации

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

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

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

Состояние сессии в кластеризованном окружении

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

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

  1. Можно сконфигурировать и разрешить "привязку сессии" (sticky sessions) в качестве решения для балансировки нагрузки. Это гарантирует, что все запросы от заданного пользователя направляются на один и тот же экземпляр в течение конфигурируемого периода времени.

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

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

Если используется устойчивое хеширование, базирующееся на cookies, убедитесь в том, что имя вашего cookie не JSESSIONID, это имя использует OpenBPM Engine.

Job Executor в кластеризованном окружении

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

ВРЕМЕННЫЕ ЗОНЫ: Существуют некоторые ограничения на использование временных зон в кластере.

Мультиарендные модели

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

  • Разделение данных на уровне таблицы, используя разные схемы базы данных или разные базы данных

  • Разделение данных на уровне записи, используя маркер арендатора

Пользователям необходимо выбрать модель, которая соответствует их нуждам в плане разделения данных. API от OpenBPM Engine предоставляют доступ процессам и подробности о соответствующих данных каждому арендатору. Чтобы узнать больше подробностей по данному вопросу, см. раздел мультиарендность.

Архитектура веб приложений

Веб приложения на OpenBPM Engine базируются на RESTful архитектуре.

Используемые фреймворки:

Дополнительные кастомизированные фреймворки:

  • camunda-bpmn.js: Camunda BPMN 2.0 JavaScript библиотеки

  • ngDefine: интеграция AngularJS в приложения на RequireJS

  • angular-data-depend: тулкит для реализации сложных AngularJS приложений с большим количеством данных

Лицензия и атрибуция

Эта документация была создана на базе материала "Camunda 7 Docs" от Camunda, находится под лицензией Creative Commons Attribution-ShareAlike 3.0 Unported License .

Оригинал документации: https://docs.camunda.org