views:

388

answers:

1

Hi!

I have a design question :)

I want to have multiple servlets but I dont want to configure a new servlet with a new name each time and extend the HttpServlet. I was thinking of having a generic servlet which dispatches different parameters to different specific classes that are actually handling the request.

Ex: theese two calls will be handled by the same generic servlet but dispatched to different services (classes).

/serviceservlet?action=action1&param1=test1&param2=test2 /serviceservlet?action=action2&param21=test

This can be done in many different ways and I dont know for which design to go by. The one I have right now is using guice for bootstrapping and looks like this:

@Singleton public class ServiceServlet extends HttpServlet {

private static final String PARAM_ACTION = "action";
private final Service1 service1; // Service1 is an interface
private final Service2 service2; // Service2 is another interface

@Inject
public ServiceServlet(final Service1 service1) {
    this.service1 = service1;
}

@Inject
public ServiceServlet(final Service2 service2) {
    this.service2 = service2;
}

@Override
public void doPost(final HttpServletRequest request, final HttpServletResponse response) {
    String action = ServletUtils.getStringParameter(request, PARAM_ACTION);

    if ("action1".equals(action)) {
    ... check that the parameters are correct before executing the below to have typesafety
        service1.process(request.getParameter("param1"), request.getParameter("param2"));
    } else if ("action2".equals(action)) {
        ... check that the parameters are correct before executing the below to have typesafety
        service2.process(request.getParameter("param21"));
    }
}

}

In principle I would like to handle the services in a more generic way and I want it to be as easy as possible to add new services later, but I dont want to loose typesafety. What do you think is the best strategy?

/Br joynes

A: 

Nowadays web programmers don't write this kind of code themselves. These use web frameworks like Struts or JSF or Spring (if you're a Java programmer) which provide elegant implementations of dispatching requests, of mapping from requests to classes that implement the requests. And much, much more.

However, if you really want to "roll your own" , then I would suggest, first off, that you don't use an if statment inside your servlet. You should use a map (i.e., HashMap) that maps request URIs to service classes. On servlet init, the map should be populated with instances of the service classes. Inside your servlet add a method, getServiceClass() that return gets the URI and ACTIONS from the HttpServiceRequest and looks up your service class. Better yet, you should map the service classes, not to request parameters, but to URIs: myapp/serviceX maps to ServiceX.class. Define a service interface, Service, with an execute method and call the execute method from the Servlet.

To sum up:
1) Load a map of request URIs to service classes when the servlet inits.
2) Define a service interface between the servlet and the service class.
3) From the servlet, grab the URI (relevant portion of the URI) from the request and lookup the corresponding Service and call its execute method (or whatever name you choose to give).

JimB
Yeah sounds sensible.. what about using Stripes?
I have tried using Stripes and it doesnt fit very naturally with guice injection. I guess its the same kind of problems with the other frameworks :( and I guess I will be rolling on my own until better times.
Guice is a dependency injection framework? I'm using Struts with Spring (dependency injection) and they integrate. Struts has a plug-in architecture that allows you to integrate all kinds of other technologies.
JimB