How to attach a servlet web interface to a local client application?

Question

I'm envisioning my (now local) program running on a server in the future with a web interface, using Tomcat and servlets. I'm just confused about how I can integrate my existing application with HTTPRequests coming to a servlet.

• Should my application be running already, and the servlet can transfer control?
• Or is my program going to become the servlet itself?
• Or does my application contain a servlet, and Tomcat just knows that there is a servlet in my app?

I just need some advice about how everything could fit together, and how a servlet calls application logic.

I'm imagining something like:

1. HTTPRequest comes to Tomcat, which routes it to the Servlet by called Servlet.service(...) (Servlet is created if doesn't already exist)
2. Servlet.service() checks if the application is running, if not, creates a new process for the application
3. Servlet can send the HTTPRequest header/body to the new process, either thru command line or through stdin
4. Servlet can either wait for the new process to finish, or just send back a HTTPResponse and let the Process run (the application needs to be threaded, so send response right away and let it run).
5. If another request comes to the servlet, step 2.

Does that sound reasonable?

I suppose instead of making a separate process, I could just thread my application within the Servlet and let it run that way too.

Answer 1

A servlet is Java's way of implementing a Common Gateway Interface program for a web server. So this program you're writing (you may wanna provide more information) should the type of program where you provide some input, process the input, and then provide a response.

I would suggest that you break down the application you're currently writing into controller and model classes. Anything that deals with input and output is your controller. Anything that deals with the business logic is the model. (Anything that prints anything out is the view. And yep, I'm talking about MVC, the Model-View-Controller pattern.)

So your controller in your application (before you move everything to a servlet) might take a bunch of arguments from the command line, check them for correctness, the right kinds of combinations, etc.

Your model code should have a nice, simple interface that doesn't rely on the controller. (It shouldn't know whether it's being called from your application or from a servlet layer.) It should provide a method that does the business logic by taking parameters that makes sense to your business logic. So if you're writing a servlet that computes the sum of two numbers, the model layer should have a method that takes two numeric parameters and returns the sum. That way you can drop the model into either the application or the servlet, and it'll work just fine. Only your controller needs to change.

I won't go into how to write a servlet vs. an application -- that's an involved topic and there's tons of examples out there. But the way a servlet calls application logic is simple: you instantiate your model class, and then invoke a method on that instance. Just like any other java application.

Answer 2

Considering your application is a linear, not threaded program that does something when instantiate objects of your classes and the objects have some external interface (public methods). Then the servlet container will starting and you have to write a new servlet class that will create instances of your objects and call your methods from standard servlet methods (service(), doGet(), etc). Remember to put your classes on the classpath for the servlet container or webapp.

Answer 3

Not exactly knowing what your application is, my suggestion is to isolate as much of the logic as you can in your current application. This would be your "business" logic here. Keep that as a separate project that is packaged into a jar.

Create a new project to serve as your web layer (packaged as WAR most likely). This would include your servlets and jsp pages for interacting with your business logic. So for example you have a form for creating some type of business object. The form would be a jsp page that is "served" up by a servlet. When you submit the form, the servlet would handle the form submission and call code in your business project (jar).

The web stuff just serves as a separate layer and keeping all that business logic separate form the visual web side also would allow you to build a service layer on top of it that could also eventually sit between your web project and the actual business logic, although depending on your purpose that could get a little overdone.