Question

I’ve been researching Apache’s commons-daemon and it seems pretty cool: basically its an API as well as a library that helps register your JAR with the underlying OS so that it can be started and stopped like a daemon service. Additionally, it intercepts OS signals that would normally kill your app and instead gives you a chance to shutdown politely.

So it’s got me wondering, if given the choice between deploying your business logic inside EJBs and wrapping them in a container like OGS or JBoss, why not just create a daemon JAR that listens on a port and responds to client requests?

Is it just the benefit of all the features/services that an app container provides out of the box (security, logging, etc.), or are there times when it would be favorable to choose a daemon over an app container/EJB solution?

Basically, what I’m asking if: when is it more appropriate to use an app container/EJB solution, and when is it more appropriate to use commons-daemon to help build a system-level service (in Java)?

Disclaimer: just interested in these two choices, I am aware that other solutions exist (web containers, ESBs, OSGi, etc.). But for the purposes of this question I am only interested in hearing the reasoning between app container or daemon solutions. Thanks in advance!

Answer 1

Why don’t you look at it like System level (daemon) vs Application level (in container)?

This will give more or less clear distinction (especially if worked with Linux some time).

For Daemon:

• has its own life cycle (you can start and stop it separately);
• different privileges (could be run under different user);
• use case is something like CRON, MailServer, synchronization and any system-level service.

For Container:

• managed app (by some privileged user via Container console);
• plenty of out-of-the-box features (which you’d already mentioned);
• use case some general case business application.