I have a small application that needs to run continuously in the background. The program is able to setup directory monitoring services, HTTPS listeners, and other services that need to remain running as a part of the main service thread.
However, users also need to interact with the program and execute tasks manually, configure various settings, etc. I've made a command-line interface using jline and argsparse4j that allows users to do this.
I can run the main CLI thread, which can do all of the things I want, but as soon as I close the thread, all of those services shutdown with the main thread.
I've counteracted this using process builder and having shell scripts that launch separate instances of the jvm to run certain processes, but this just feels wrong.
I need to combine the best of both worlds here, by having a persistent service that a user can essentially login to, and log out of, but is all local. The first thing that comes to mind is how mysql behaves. MySQL runs as a service at all times, but the user can type mysql, with some login parameters, and "login" to mysql to execute commands. This is exactly how I would like my program to work.
My first idea was to just wrap all the functionality in an API of sorts, and possibly use a message queue protocol like AMQP, and then decouple the command line interface to send messages to the service. This makes a lot of sense as well, because we're also enabling an HTTPS REST API on the same client, to allow remote users to use its functionality. So we'd just have two message protocols to process within the API.
However, I am wondering if there are any better or simpler alternatives than writing a full-fledged message-based API that is client-server?
Ultimately, we chose to go the route of having a backend REST API that was implemented with the Spark Framework for Java. This may not be the most robust, and user feedback has been an issue. We've split our command-line interface to submit REST calls, and display results to the user.