A scalability question

Question

Hi guys, I'm a bit concerned with the scalability of a proposed design for our servlet-based multi-service handler system.
Here's a brief description:
1. A single controller servlet get's an Xml message.
2. The message contains info, incuding the sub-application it belongs to. The controller uses a Dispatcher object to locate a handler object for that sub-application, and passes along the message to it.
3. The app-handler gets info from the message describing a specific action that need be executed, and the required parameters. It maintains a pool of action handlers, so it locates the proper one and passes along the data.
4. The action handler executes and returns a response message.
5. The response is propagated back to the original servlet and is sent back to the caller.
Although that "architecture" enables us to dynamically add sub-applicatins & actions to the system, I'm afraid that it might not scale well. Everything is executed within the original servlet's thread, and the application handler is usually a single instance saved in the Application attributes.
Possible solutions:
1. A first proposed amend is to use JNDI to get a reference to the sub-application handlers through a Factory object that maintains a pool of application handler instances. I'm assuming that the Factory will be run in a separate VM on the same machine, or even another one. (Perhaps it could even be a SessionBean on an App. Server ? ). Still however, the response need be passed back to the original servlet instance that serviced the call.
I'd like to be able to pass the output stream to the handler and just forget about it from the servlet, just like I'd do if i were using a plain socket server, but I doubt I could give it an OutputStream parameter through the two separate VM's ( or could I ? )
2. Perhaps maintain a pool of sub-application handlers within the servlet, in a member variable that get's initialised in the servlet's init() method, and get the reference through JNDI, but wouldn't that place a heavy bourdon on my little Tomcat servler ? And again, the original servlet that serviced the call would have to give the response back to the caller ...
Before we start trying out the possible alternatives, I thought I'd ask around for some opinions. It's no use spending the time to proof-test a solution that costs valuable time before asking a second opinion.
Anyhow, thanks for the help people, any ideas would be much appreciated.
Cheers,
Angel
O:]

Answer 1

I'm not sure what you are trying to do... Seems to me points 1-5 would be covered by:
class SuperDuperDispatcherServlet
    extends HttpServlet
    doGet()
        String app_name = ...get string from XML message...;
        SubApplication app = SubApplicationManager.get(app_name);
        app.doit(request, response);
class SubApplicationManager
    private static HashMap by_name = new HashMap();
    void register(String name, SubApplication app)
        by_name.put(name, app);
    SubApplication get(String name)
        return (SubApplication) by_name.get(name);
interface SubApplication
    void doit(HttpServletRequest request, HttpServletResponse response);
}I.e.: stick applications in a HashMap, indexed by the application's name. The "generic sub-application dispatcher engine (TM) (pat.pend.)" has a fancy name but it doesn't mean you need to over-engineer it...
There is no "pool" of SubApplication objects. The best way to deal with that is not to have instance variables in SubApplication objects (just like servlets.) That way you need only one object to represent each sub-application.
Is there something I missed or you didn't mention that prevents such a simple approach...?
Although that "architecture" enables us to dynamically add
sub-applicatins & actions to the system, I'm afraid that it might not
scale well. Everything is executed within the original servlet's
thread, and the application handler is usually a single instance saved
in the Application attributes.Every instruction is executed in some thread. Might as well use the thread you have. A function call is a couple of machine instructions; you can only go downhill from there. Handing work to another thread or process, and then waiting for it to finish, is just silly.
How many requests per second do you expect? Is there heavy computation involved? I.e. do you need to transfer parts of sub-application executions to other computers? There is non-trivial overhead in that; only do it if you can't avoid it. Consider clustering instead.