Java daemon design practices

Question

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.

Providers 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.

Services 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.

Question: 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.

Edit:

• 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.

Thanks

Answer 1

Web servers (and not only the HTTP kind) use the Request/Response pattern. A socket listener waits for incoming connections, uses a request factory to create a Request object and then passes this to a handler which returns a response object (or the factory also creates a response object and the handler just modifies it).

In the HTTP world, the handler is identified by the URL and the URL paramaters or the POST data becomes Request data. The response (usually some HTML page) is encoded from the response object and sent back to the browser.

Answer 2

Depending on how large you need to scale, you might want to consider a messaging service like JMS. Your producers and consumers (i.e. providers and responders) could publish to and listen to the appropriate JMS topics.

Answer 3

Based on my understanding of the requirements you described, I do have a couple of suggestions.

Disclaimer: I don't really know about your scaling requirements or your resource constraints, and if you're running a daemon these may be important. As always, take the forthcoming suggestions with a grain of salt.

My initial reaction is that there's probably no single design pattern that will solve your entire problem, but there are some design patterns that might help you with subsections of it.

1) It sounds like your Main class is going to be polling the providers. You may want to do something more message driven. Have a look at the Observer pattern and the related publish/subscribe pattern if/when you need to scale up.

2) You may want to think about pre-allocated thread pools for your providers. It may not be strictly necessary, but it might make sense for your particular situation.

3) Based on your description, you may be heading into architecture astronaut territory (i.e. generalizing everything before you need to). Unless you're going to be distributing an API or have a lot of people working on/re-using this code, I'd caution against this type of behavior: it's a big time sink and it's frustrating to aim so high and then only implement a tiny fraction of the initial ambition.

Some of this advice may not apply directly to your problem, but I hope it helps.

Answer 4

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

• In order be distributed, you'd use some kind of messaging system like JMS.
• In order to listen for events from other protocols, you'd use a Channel Adapter.
• Your "services" can either be strung together using Pipes and Filters and Message Routers or you could use a Process Manager (often some BPM or Workflow engine).

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.

Answer 5

A non-Java specific (by which I mean a generic approach, not one that doesn't apply when using Java) is to use a simple Request/Response approach as noted by Aaron Digulla. This is a very common scenario but easy to over-engineer (as really, it's quite straightforward and simple to write - especially when using appropriate supporting libraries).

If your app for web service to add/remove entires from a database is more than a 200-300 lines of code then it's probably over-engineered (even with reasonable error handling and dynamic configuration).

If your database supports locking and enforcing uniqueness (and transactions, if you require that sort of functionality), I'd advise you don't overcomplicate things by writing a locking demon - just let the database take care of it and handle the exceptions.

If you really do need to do locking (e.g. because you are writing to some external service like a bit of hardware) then you can use a typical UNIX approach to locking resources and write a single-instanced daemon that runs on a local socket which all your web services can talk to - depending on if it indicates a resources is busy they could either reject requests or queue them (e.g. in memory in a queueing system, a table in an SQL DB, etc.) with a a daemon which process queued requests (which also talks to the locking service).

To keep things really simple you can always just always push requests to the queueing system from the web service, I would recommend that unless you need to distinguish between "this action is now being performed" and "this action is queued" in your responses to the client submitting the request.

For the interface itself, personally I favour something that is and widely endorsed as an open standard, easy to implement and highly interpretable, like Document/Literal SOAP service, in preference to something like RPC/encoded (deprecated & evil) or JMS (which is proprietary, though in practice supported widely to varying degrees).

If you are writing an exclusively internal service and you an exclusively a Java shop then JMS is highly suitable but if it's not an internal application it's best to play nicely and not assume everyone else will want to have to use a JMS client just to talk to your service (I evangelise Doc/Lit SOAP because it can be parsed by anything than can handle even basic XML and is WS-I endorsed).