views:

991

answers:

5

I have written a standalone Java application that I've packaged into a jar file that takes in some command line arguments, does some hardcore computations, and then writes out the result to a file along with some output to the default output stream pointing to where the file with the results are.

I now want to create a website around this technology. The idea is that the user can fill in an html form, post it to a webpage, which would then call the Java application, parse the results from the Java app, and display it to the user.

Currently, I am using a little bit of PHP to collect the data from the post request, and then just using an exec call:

java -jar -Xmx128m myapplication.jar command-line-arguments

Is this bad?

I do have several thousand visits to my website each day and each execution of the Java application can take upwards of 30 seconds to a minute, so I don't want to be overly inefficient. It seems like there would be a better solution than having to call Java directly for every request.

I keep hearing things like java servlets, beans, tomcat, glassfish, etc., but I don't understand what they are and how they would benefit me. What do these get me? Faster results because the Java JVM doesn't have to be created each time I run the application? Less memory usage? I obviously want it to run as fast as possible with as little memory footprint as possible.

So, what is the best approach that I can take here? I don't want to do any serious rewriting of my application as there is a lot of code (so rewriting it to C or C++ is out of the question).


Thanks.

A: 

You probably don't want to invoke the java app directly from the website. Like you said, if the java process takes 30 seconds to run, your web server is going to get way bogged down, especially if your site is getting pounded.

You may want to look into web-services (and possibly a message queue) for dispatching back-end processing requests. The PHP page could call the web-service on the server, which could then put a processing request on a queue, or just kick off the java app in an asynchronous fashion. You don't want the HTTP request to wait for the java app to finish, because, while it's processing, the user will just have a hung browser, and the HTTP request might timeout.

Once the java app finishes, it could update a database table, which the user could then access from the website.

Andy White
+1  A: 

[Do these get me] "Faster results because the Java JVM doesn't have to be created each time I run the application?"

Yes.

And -- bonus -- you can replace PHP so your entire site is in a single language: Java.

Further, you can consider revising your use cases so it isn't a painful 30-60 seconds in one shot, but perhaps a series of quicker steps executed interactively with the user.

S.Lott
+5  A: 

Ok, servlets are smalish applications that are designed to run inside of a container. They provide an extension point for you to insert your java code into either a simple servlet container like tomcat, or a more fully featured application server like glassfish. You want to do this because the application server does the heavy lifting of dealing with the http interaction and provides other features like security, logging, session management, error handling, and more (see the servlet specification).

When you make your application live within an application conatiner (web server with all those other extra features), you can also manage the lifecycle of your application better. You'll be able to start and stop the application without shutting down the web server, redeploy, start more instances, etc. Plus, when you come up with that great second application, its easy to drop it in right next to the first one. Or, you can cluster several machines together for easy redundancy and load balancing, features of the application server.

This is just a start, there are many more features, technologies, and frameworks out there to help you make container based applications. Servlet tutorial.

John Ellinwood
A: 

Run your code inside a servlet container.

Assuming that you need to keep your website in PHP and as you already have java installed on your machine, simply install a free servlet container (such as Apache Tomcat, or Jetty). Configure to run the servlet container on an unused port. (8080) is their default.

These servlet containers are really java based webservers, just like Apache, however specialized in serving java code.

The most obvious advantage of using a java webserver rather than a new java.exe invocation for each request, is that your java virtual machine (jvm) will always be "hot", up and running. Each new start of the java.exe (jvm) will give you those extra seconds of waste.

The second advantage of using a servlet container, is that the container will enable your code to run in a new thread, inside the jvm, for each new request. You will have no problem providing your service to your thousands of users a day. Most likely, your machine will crash if you were to start hundreds of java instances rather than one.

Place your code inside a servlet. It really is easy even for a newcomer. You will talk to the servlet via HTTP (doGet or doPost methods of the servlet). Pass the php request form to this servlet and have the servlet give you back whatever: a page, a json object, xml or plain text.

Florin
A: 

The easiest thing to start with would be to embed a webserver in you application. Have a look at Jetty.

pgras