Переработать веб-сервисы из лабораторной работы #2 таким образом, чтобы они реализовывали основные концепции микросервисной архитектуры. Для этого внести в оба сервиса -- "вызываемый" (из лабораторной работы #1) и "вызывающий" (добавленный в лабораторной работе #2) перечисленные ниже изменения.

• Разделить приложение на два модуля -- веб-приложение с веб-сервисом и EJB-jar с бизнес-компонентами.
• Переместить всю логику из класса сервиса в Stateless EJB. В классе сервиса оставить только обращение к методам бизнес-интерфейса. EJB-компонент должен быть доступен удалённо (иметь Remote-интерфейс).
• Сформировать на уровне сервера приложений пул компонентов EJB настраиваемой мощности, динамически расширяемый при увеличении нагрузки.
• Установить ПО Consul и настроить Service Discovery с его помощью. Сервис должен регистрироваться в Service Discovery в момент запуска.

• Сконфигурировать окружение для работы сервиса на платформе Spring Boot.
• Запустить второй экземпляр сервиса на другом порту. Реализовать балансировку нагрузки между экземплярами с помощью Haproxy.

• Первый ("вызываемый") сервис переписать в соответствии с требованиями протокола SOAP.
• Развернуть переработанный сервис на сервере приложений по собственному выбору.
• Оставшийся сервис не модифицировать, не менять его API, протокол и используемый сервер приложений.
• Установить и сконфигурировать на сервере Helios программное обеспечение Mule ESB.
• Настроить интеграцию двух сервисов с использованием установленного программного обеспечения.
• Реализовать дополнительную REST-"прослойку", обеспечивающую возможность доступа к переработанному сервису клиентского приложения без необходимости его модификации. Никакой дополнительной логики, помимо вызовов SOAP-сервиса, разработанная REST-прослойка содержать не должна.