William William - 1 year ago 105
Java Question

Java daemon design practices

I'm writing a daemon in Java that takes in requests from multiple providers in which the provider would return a service object for the daemon to run as a thread.

Application architecture:

  • Main class

  • Providers

  • Services

  • Libraries / Models

  • List item

Main class
Basically loads the configuration file, initializes libraries required, etc. Once the daemon is initialized, it loops through all the providers and initializes them. After that, the daemon goes into an endless loop constantly going through each provider evenly distributed and tries to fetch a new service.

A provider is basically an adapter to a 3rd party service. This could be e-mail, fax, a job queue, database, etc. When a provider is initialized it connects to the 3rd party service. Whenever the application fetches a new service object from the provider, it checks the 3rd party service, if it finds a new request, it parses it and then returns a new service object to the application.

A service is basically a specialized job. When a provider gets a new request, it returns a specific service type related to the request. When the application runs a new service thread, it will handle the request and then close.

Here is an example, although it probably won't ever be used like this. A new provider is created that listens on an HTTP port. A new HTTP request comes in asking to process a string (reverse it) and store it in the database reversed. A new request comes in, the provider returns the service to the application, the application launches a new service in which is reverses the string and updates the database. When it's updated, the application sees that the job is done and is able to fetch a new one from another provider.

Are there any design patterns like MVC that would handle an architecture like this? I realize that MVC is a very bad term to use, as it contains multiple patterns. I guess what I'm asking is, the approach I'm going for okay? Would it be a good idea to take the concepts behind MVC and move it to this application? Providers being controllers, services being actions tied to models? Although there is never any views in this type of application.


  • The daemon handles requests asynchronously to the requester. The requester never receives a direct response.

  • The application is distributed, so you can run this daemon on as many servers as you want. Whenever a provider retrieves a new request it locks the request so the other daemons do not duplicate the request. Jeff Storey mentioned JMS which could be useful for this. I've also thought about integrating Memcache to handle locking on top of how the providers handle it.


Answer Source

What you're describing sounds a lot like the the kind of thing that enterprise integration patterns solve.

Lightweight Java libraries that support these patterns are things like Apache Camel or Spring Integration or you could use a full Enterprise Service Bus like ServiceMix or Mule.

Here's a rough translation of your terms:

Main Class - In a full ESB this would be the ESB itself, i.e. the application server. You could write this yourself or you could use an existing ESB or general purpose application server like OSGI.

Providers - Channel Adapters.

Services - These will be various components. Some may be EIP components like Message Transformers as well as Service Activators or other Channel Adapters.

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download