tags:

views:

66

answers:

4

I know 'normal' Java, but am new to the world of servlets, containers etc. Because of that I am not sure which approach is most sensible.

Situation: I have created a Servlet that receives information and stores it in a database. This database gets read by other applications.

Now what I need is an application that receives the exact same information and stores it in the same database. However this new application needs to pull this information from another server (I'll be using httpClient for this) instead of it being pushed to it. Both applications will co-exist.

For this new applications I see the following two options:

  1. Make a stand alone application. For this I can copy paste a lot of the existing back-end code, but I will need to make some modifications (the servlet container offers a context, easy database connection pooling etc.) Further I might need to use some wrapper so this can work like a proper daemon that I can start, but also gracefully stop/restart etc.

  2. Make the new application part of a Servlet. That is: just start a new Thread in the init() of the servlet that will run the new application. This would allow me to reuse all the backend code I already have, without needing to rewrite any of it. I only need to write the code that does the HTTP-GET requests to the other server. With this approach it will also be easier to start and stop the service, because I can use the Servlet container for that.

Some info about the project: the backend code that parses and writes the data to the database has a few threads, but is not very complicated. Writing the code for the original servlet was about one week of work. With the existing code base I feel this new application should probably be 1, 2 days of work max.

The way I see it option 2 is easier. But it feels a bit like I would 'abuse' servlets. So my question is: Aren't servlets for applications that should handle requests, instead of applications that make request? Are there some huge drawbacks I don't see here? Which option would make most sense?

tl;dr: Can I write an application that doesn't serve requests as a Servlet?

+2  A: 

Servlet containers are thread-managed environments. In general, don't start your own threads in a servlet, or bad things can happen... starting and stopping the application context, for example - the appserver doesn't know about the threads you might have started so won't stop them with your app... (More detail in this SO question)

I would try to extract the logic I need from the servlet into classes that don't depend on the Servlet API, and redesign the servlet to make use of these classes. (Refactoring). The servlet API, as you note, is all about receiving requests and sending responses.

I can re-use the logic in my new non-servlet classes anywhere I like, including a non-servlet part of the application that polls out pull that info.

Brabster
Follow up question: I shouldn't start my own threads, or bad things will happen. Could you elaborate on this?Right now the existing servlets uses two background threads to write data to two databases.These threads are connected to the servlet using a BlockingQueue. The reason I have this in different threads is because writing to the database is time intensive (because of a lot of triggers in the database) and data can come in in bursts.So this is not an adviced design? What kind of trouble could this give?
brasilt
Sorry, I was updating as you commented.
Brabster
@Brabster is probably referring to the fact that most web/app servers prefer to manage threads in the servlet container, in theory your own initiated threads aren't safe as the container can muck about with them....
karianna
If you need to run threads of your own, they should be started and stopped in maybe a ServletContextListener, so that you get a callback when the context starts and crucially when it stops, so that you can tidy up whatever you're doing - so there are ways, but you have to be very careful.
Brabster
@brasilt see my answer at http://stackoverflow.com/questions/3873158/thread-running-in-web-page/3873200#3873200 for another explanation
matt b
Thanks for answers and interesting links.I do clean up all threads in the servlet destroy() method, but I am not sure whether that is enough?
brasilt
+6  A: 

Don't copy and paste code.

Write a re-usable class/module which handles storing the information in the database which can be used by both 1) the servlet and 2) standalone code which retrieves information from a HttpClient.

This way the same piece of code handles the same logic - how to store the information in the database - whether the information in question is being pushed to a servlet or being fetched from a remote URL.

matt b
+1  A: 

You could use, but you shouldn't, it is a very poor design.

If you have two different ways to access your application (one through servlets and other as standalone), you should create at leats three classes:

  • One class that does all the work relating database, etc.
  • One servlet that calls the first class
  • One stand alone class (or whatever) that calls the first class

In this way, you don't copy/paste, and you can reuse your code (even you can have a third way to call the class that do the heavy work

greuze
A: 

If you want to reuse code, have this code as part of a "Service" or "Business Logic" layer that will be used both by your servlet and non servlet application.

Package the code as a jar and use it in both applications.

Nivas