This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Our main application has (at this moment) some 200 servlets (though many use the same Java class, differing in initialisation parameters only which in our architecture have a massive impact on how the servlet behaves through dictating the loading of any of several hundred objects to do the real processing).
In addition there are some 500 JSPs, over 300 XML and properties files, and nearly 600 supporting classes. And that's with the application only about 55-60% done, we expect to need another year to complete it...
So yes, you can use more than one servlet. In fact to make your application fairly modular you should use more than one. If you don't you will start suffering from a completely unmaintainable servlet sooner rather than later (some of our classes suffer from this already, despite my efforts to break them up into functional components some are thousands of lines long still, a legacy from a somewhat flawed architecture and understanding of OO in the project/company from before I came on board).
For small to medium scale projects it is better to manage with one or more servlets. Separate the servlet based on the functional modules. Do not do any processing in the servlet. Forward to Javabean. I prefer one servlet managing many java beans and JSPs.
What you may be thinking of is that is not uncommon in a MVC architecture to have only one controller servlet. This servlet receives all requests (or most, as it would not receive requests for images, CSS files, etc). However, in most such scenarios, unless you have a very simple web application, this servlet will pass the request along to other Servlets or classes that are part of the complete controller. For example, in Struts which uses MVC, the flow goes something like this:
A request is made (typically from a previously displayed page, or View).
The ActionServlet, which acts as the Controller, receives the request. It looks up the requested URI in the strus-config.xml file, which contains a mapping to the Action class that will do the business logic associated with that mapping.
The Action class performs the necessary business logic, interacting with any Model necessary components.
When the Action has completed its logic, it returns control to the ActionServlet. When doing so, the Action class sends the ActionServlet a key that tells it the result of the processing.
The ActionServlet looks this key up in the struts-config.xml file, which tells it what view to use. The ActionServlet passes the request to that view.
The associated view (typically a JSP page) processes the request (often using information stored in a DTO or bean) for display and then sends the response off to the client.
Again this is just one implementation of the MVC. There are some other variants, and how they are set up will depend on how complex your application is, or more importantly, how complex it may be some day, After having worked on many projects that will "be small" or are "only temporary" that later become monsters, I am a firm believer in always designing as if you application will grow to be the next amazon.com