I have a daemon process, written in Java, which I would like to be configurable at runtime via an HTTP-based API.
For a number of reasons, I'd rather keep the admin API separate from the daemon process itself:
- resilience: if the admin API fails, the daemon must continue running.
- separation of concerns: the admin API and daemon are two separate (but interrelated) components of the overall application.
- loose coupling: it's easier to upgrade one or the other component if they're not tightly coupled.
At present, the approaches I have considered include:
- Incorporate both daemon and admin API in a JAX-WS application. This would work, but fails on all of the above points.
- Have the daemon process expose the admin API via an embedded web service (e.g. Jetty). This would be better than the previous approach (the daemon is no longer dependent on a web container), but otherwise shares many of the same issues.
- Have two separate applications (daemon and API), sharing a common configuration database. This would achieve loose coupling, but lead to awkward interaction between the components (e.g. each component needing to poll the database for changes made by the other).
- Have two separate applications, communicating via a low-level socket- or pipe-based interface. This is the best in terms of achieving loose coupling efficiently, but (presumably) at an increased cost in terms of code complexity.
If we accept that it's preferable to keep the two components loosely coupled, what is the best (i.e. most flexible and idiomatic) approach to achieving this in Java? Is there an alternative I haven't considered?