Как создать интерфейс командной строки, который может взаимодействовать с постоянно работающим сервисом, похожим на оболочку MySQL?
У меня есть небольшое приложение, которое должно работать в фоновом режиме. Программа может настроить службы мониторинга каталогов, HTTPS-прослушиватели и другие службы, которые должны оставаться работающими как часть основного потока службы.
Однако пользователям также необходимо взаимодействовать с программой и выполнять задачи вручную, настраивать различные параметры и т. Д. Я создал интерфейс командной строки с использованием jline и argsparse4j, который позволяет пользователям делать это.
Я могу запустить основной поток CLI, который может делать все, что я хочу, но как только я закрываю поток, все эти службы отключаются основным потоком.
Я противодействовал этому с помощью компоновщика процессов и наличия сценариев оболочки, которые запускают отдельные экземпляры jvm для запуска определенных процессов, но это просто кажется неправильным.
Мне нужно объединить здесь лучшее из обоих миров, имея постоянный сервис, в который пользователь может входить и выходить, но все локально. Первое, что приходит на ум, - это то, как ведет себя mysql. MySQL всегда работает как сервис, но пользователь может ввести mysql, с некоторыми параметрами входа в систему и "войти" в MySQL для выполнения команд. Именно так я бы хотел, чтобы моя программа работала.
Моей первой идеей было просто обернуть всю функциональность в своего рода API-интерфейс и, возможно, использовать протокол очереди сообщений, такой как AMQP, а затем отделить интерфейс командной строки для отправки сообщений в службу. Это также имеет большой смысл, потому что мы также включаем HTTPS REST API на том же клиенте, чтобы удаленные пользователи могли использовать его функциональные возможности. Таким образом, у нас было бы два протокола сообщений для обработки в API.
Однако мне интересно, есть ли лучшие или более простые альтернативы, чем написание полноценного API на основе сообщений, который является клиент-сервером?
1 ответ
В конечном счете, мы решили пойти по пути использования внутреннего REST API, который был реализован с помощью Spark Framework для Java. Это может быть не самым надежным, и отзывы пользователей были проблемой. Мы разделили наш интерфейс командной строки для отправки вызовов REST и отображения результатов для пользователя.