How should i design a server application in java

Question

I'm developing a java application which reads a continuously written a file of recordsets (800.000.000 records per month), bulk reading data from files and calls a web service to read also data. These data should be stored in a database (a huge database). The next feature I'm going to add is a web service, which can be called from other applications to add or receive (predefined queries [maybe the running time of the method/query is about 1 or 2 minutes]) records. Additionally to web service I want other application written in c#, c++, etc. to be able to connect (I thought about protocol buffers or apache thrift). And at least it should offer a way to administrate the application (i though about a web site)

In my opinion it should be a server application. But should I develop a server on my own (opening sockets, etc.), a Java EE or are there any other "server frameworks" (may be a combination of jetty, sockets, etc.)?

Answer 1

just divide and conquer: One solution can be using tomcat:

function 1) create a thread which reads the file. then you can define a context listener within the web.xml

function 2) Look at java.util.Timer or, for more robust functionality, look at a third party product like Quartz.

function 3a) There are a lot of WS frameworks availabe. Use google to find tutorials

function 3b) Google for Asynchronous Web Service or Asynchronous Support in Servlet

function 4) AFAIK Thrift has a build-in TServlet. I think Tomcat and Google Protokoll Buffers is also possible

function 5) Offering web sites is one of tomcats main functions

Answer 2

If it's going to be something that users can deploy -- a product that clients will buy, or an open-source tool for people to download -- then I would suggest that the best approach is to develop it in a container-agnostic manner, as far as possible.

By which I mean, focus on what the application does, and abstract things like launching and connecting to services out. If you do that right, you can then write container-specific elements, to allow your users to deploy the application in, for example, their choice of app server, or as a standalone application.

On the other hand, if it's for an in-house project, where you fully control all aspects of how the application will be used, you can avoid some or all of the above; though you probably would be better to use that kind of abstraction in any case.

Certainly Eric Leschinski is right in that you don't want to develop something like Tomcat or IIS.