БЛПС

Лабораторная работа #1

Вариант №10114: Rutube - http://rutube.ru Описать бизнес-процесс в соответствии с нотацией BPMN 2.0, после чего реализовать его в виде приложения на базе Spring Boot.

Порядок выполнения работы:

• Выбрать один из бизнес-процессов, реализуемых сайтом из варианта задания.
• Утвердить выбранный бизнес-процесс у преподавателя.
• Специфицировать модель реализуемого бизнес-процесса в соответствии с требованиями BPMN 2.0.
• Разработать приложение на базе Spring Boot, реализующее описанный на предыдущем шаге бизнес-процесс. Приложение должно использовать СУБД PostgreSQL для хранения данных, для всех публичных интерфейсов должны быть разработаны REST API.
• Разработать набор curl-скриптов, либо набор запросов для REST клиента Insomnia для тестирования публичных интерфейсов разработанного программного модуля. Запросы Insomnia оформить в виде файла экспорта.
• Развернуть разработанное приложение на сервере helios.

Вопросы к защите лабораторной работы:

• Понятие бизнес-логики в программных системах. Уровень бизнес-логики в многоуровневой архитектуре программных систем.
• Основные концепции, используемые при разработке бизнес-логики. CDI, IoC, управление транзакциями, безопасность, распределённая обработка данных.
• Моделирование бизнес-процессов. BPM и BPMN.
• Спецификация BPMN 2.0. Принципы составления и основные элементы моделей бизнес-процессов.
• Объекты потока управления, роли и артефакты в BPMN.
• Использование Spring Framework для реализации бизнес-логики. Реализация CDI и IoC. Связь уровня бизнес-логики с другими уровнями архитектуры программных систем в Spring.
• Spring Boot. Способы конфигурации бинов. Двухфазовый, трёхфазовый конструктор.
• Профили запуска приложения в Spring Boot.

---

Лабораторная работа #2

Внимание! У разных вариантов разный текст задания!

Доработать приложение из лабораторной работы #1, реализовав в нём управление транзакциями и разграничение доступа к операциям бизнес-логики в соответствии с заданной политикой доступа.

Управление транзакциями необходимо реализовать следующим образом:

• Переработать согласованные с преподавателем прецеденты (или по согласованию с ним разработать новые), объединив взаимозависимые операции в рамках транзакций.
• Управление транзакциями необходимо реализовать с помощью Spring JTA.
• В реализованных (или модифицированных) прецедентах необходимо использовать декларативное управление транзакциями.
• В качестве менеджера транзакций необходимо использовать Java EE JTA, предварительно преобразовав приложение в war, развёртываемый на сервере приложений WildFly.

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

• Разработать, специфицировать и согласовать с преподавателем набор привилегий, в соответствии с которыми будет разграничиваться доступ к операциям.
• Специфицировать и согласовать с преподавателем набор ролей, осуществляющих доступ к операциям бизнес-логики приложения.
• Реализовать разработанную модель разграничений доступа к операциям бизнес-логики на базе Spring Security + JAAS. Информацию об учётных записах пользователей необходимо сохранять в реляционую базу данных, для аутентификации использовать HTTP basic.

Правила выполнения работы:

• Все изменения, внесённые в реализуемый бизнес-процесс, должны быть учтены в описывающей его модели, REST API и наборе скриптов для тестирования публичных интерфейсов модуля.
• Доработанное приложение необходимо развернуть на сервере helios.

Вопросы к защите лабораторной работы:

• Понятие транзакции. Особенности реализации транзакций на уровне бизнес-логики, отличия от транзакций на уровне БД.
• Распределённые транзакции, спецификация XA. Реализация в приложениях на базе Java EE и Spring.
• Реализация управления транзакциями в Spring. Аннотация @Transactional. Декларативное и программное управления транзакциями.
• Java Transaction API. Основные принципы и программные интерфейсы. Работа с JTA в приложениях на базе Spring / Spring Boot.
• Менеджеры транзакций: Atomikos, Bitronix. Использование менеджера транзакций Java EE в приложениях на базе Spring / Spring Boot.
• Разграничение доступа и политики безопасности в корпоративных приложениях. Пользователи, роли и привилегии. Реализация политик безопасности на уровне бизнес-логики.
• Технология Spring Security. Основные понятия, аннотации, конфигурационные файлы и API. Использование на уровне бизнес-логики.
• Технология JAAS. Основные понятия, конфигурационные файлы и API. Использование на уровне бизнес-логики, в т.ч. совместно с Spring Security.
• Способы хранения информации об учётных записях пользователей в приложениях на Java.
• Подходы к реализации аутентификации пользователей в приложениях на Java.

---

Лабораторная работа #3

Внимание! У разных вариантов разный текст задания!

Доработать приложение из лабораторной работы #2, реализовав в нём асинхронное выполнение задач с распределением бизнес-логики между несколькими вычислительными узлами и выполнением периодических операций с использованием планировщика задач.

Требования к реализации асинхронной обработки:

• Перед выполнением работы неободимо согласовать с преподавателем набор прецедентов, в реализации которых целесообразно использование асинхронного распределённого выполнения задач. Если таких прецедентов использования в имеющейся бизнес-процесса нет, нужно согласовать реализацию новых прецедентов, доработав таким образом модель бизнес-процесса из лабораторной работы #1.
• Асинхронное выполнение задач должно использовать модель доставки "подписка".
• В качестве провайдера сервиса асинхронного обмена сообщениями необходимо использовать сервис подписки на базе Apache Kafka + ZooKeeper.
• Для отправки сообщений необходимо использовать Kafka Producer API.
• Для получения сообщений необходимо использовать API KafkaConsumer (org.apache.kafka.clients.consumer.KafkaConsumer).

Требования к реализации распределённой обработки:

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

Требования к реализации запуска периодических задач по расписанию:

• Согласовать с преподавателем прецедент или прецеденты, в рамках которых выглядит целесообразным использовать планировщик задач. Если такие прецеденты отсутствуют -- согласовать с преподавателем новые и добавить их в модель автоматизируемого бизнес-процесса.
• Реализовать утверждённые прецеденты с использованием планировщика задач Spring (@Scheduled).

Правила выполнения работы:

• Все изменения, внесённые в реализуемый бизнес-процесс, должны быть учтены в описывающей его модели, REST API и наборе скриптов для тестирования публичных интерфейсов модуля.
• Доработанное приложение необходимо либо развернуть на сервере helios, либо продемонстрировать его работоспособность на собственной инфраструктуре обучающегося.

Вопросы к защите лабораторной работы:

• Асинхронное выполнение задач. Преимущества и недостатки, подходы к реализации.
• Спецификация Java Message Service.
• Ресурсы и сообщения JMS. Модели взаимодействия "очередь" и "подписка". Распределённая обработка сообщений.
• Протоколы взаимодействия с очередями сообщений: MQTT, AMQP, STOMP, XMPP. Отправка сообщений с использованием HTTP + WebSockets.
• Apache ActiveMQ. Архитектура, способы взаимодействия, поддерживаемые протоколы, особенности реализации JMS. Протокол OpenWire и его реализации для различных платформ.
• RabbitMQ. Архитектура, способы взаимодействия, поддерживаемые протоколы, особенности реализации JMS.
• Apache Kafka. Особенности обработки сообщений, сходства и отличия с очередями сообщений. Архитектура, особенности построения масштабируемых решений, интеграция с Service Discovery.
• Периодические задачи, планировщики выполнения задач.
• Cron. Архитектура, интеграция в ОС, способы конфигурации, синтаксис Cron Expression.
• Quartz. Архитектура, интеграция с приложением, способы конфигурации.
• Выполнение периодических задач в Java / Jakarta EE и Spring. Java / Jakarta EE Timer Services и Spring @Scheduled.

---

Лабораторная работа #4

Внимание! У разных вариантов разный текст задания!

Переработать программу, созданную в результате выполнения лабораторной работы #3, следующим образом:

• Для управления бизнес-процессом использовать BPM-движок Camunda.
• Заменить всю "статическую" бизнес-логику на "динамическую" на базе BPMS. Весь бизнес-процесс, реализованный в ходе выполнения предыдущих лабораторных работ (включая разграничение доступа по ролям, управление транзакциями, асинхронную обработку и периодические задачи), должен быть сохранён!.
• BPM-движок должен быть запущен в режиме standalone-сервиса.
• Для описания бизнес-процесса необходимо использовать онлайн-сервис BPMN.io.
• Пользовательский интерфейс приложения должен быть сгенерирован с помощью генератора форм Camunda.
• Итоговая сборка должно быть развёрнута на сервере helios под управление сервера приложений Apache Tomcat.

Правила выполнения работы:

• Описание бизнес-процесса необходимо реализовать на языке BPMN 2.0.
• Необходимо интегрировать в состав процесса, управляемого BPMS, всё, что в принципе возможно в него интегрировать. Если какой-то из компонентов архитектуры приложения (например, асинхронный обмен сообщениями с помощью JMS) не поддерживается, необходимо использовать для интеграции с этой подсистемой соответствующие API и адаптеры.
• Распределённую обработку задач и распределённые транзакции на BPM-движок переносить не требуется.

Вопросы к защите лабораторной работы:

• BPM-фреймворки. Особенности реализации бизнес-логики, преимущества и недостатки по сравнению с реализацией логики "вручную".
• Платформа Camunda. Архитектура, состав, поддерживаемые языки, особенности разработки программ.
• Механизмы редактирования бизнес-процессов в Camunda. Camunda Modeler. Использование "внешних" редакторов.
• Роли и права доступа в Camunda.
• Использование Camunda в качестве подсистемы "внутри" приложения на базе Java / Jakarta EE и Spring.
• Интеграция Camunda с "внешними" сервисами (в т.ч. на базе Java / Jakarta EE и Spring). Основные API и адаптеры.
• Транзакции в Camunda. Поддержка JTA.
• Реализация GUI в Camunda. Управление формами.