IMHO there's multiple issues here:
1 . To me the MVC pattern, like the Quantum Theory has multiple interpretations
AFAICS: there's two major ways to do MVC:
one where the controller actively tells the view to update once he (the controller) has updated the model
one where the view "sees" the model updates and updates itself in turn without any exterior help
In a simple Servlet and JSP setup you're pretty much in the first interpretation of the MVC pattern, where the servlet does whatever (more on this in a minute) and then creates the model, followed by telling the JSP view to update itself so that the new model shows up in the view.
At any rate, no matter which one you chose the 2nd major issue is:
2 . Establishing how these components will match up to the Model, View and Controller entities:
one way to go about it is to have the Servlet as Controller. This means you'll (usually) have multliple servlets, each controlling one or more views. The views in turn are JSP pages. Now, the controller servlet should only deal with creating the model (not deal with presentation stuff) and the JSP view should only care about using the model for presentation (not adding to the model-construction work the servlet controller has already done). This tipically means having a Servlet with one or more DAO (or other business service components) instances, which will be used to fetch the model data, and once that's done, he'll place it where the JSP view can reach it (usually in request or session scope) and reload the view. The JSP in it's turn only knows that when it's loaded it's supposed to find the model data at some place, and present it in a certain way.
a somewhat better way to do this is to have non-servlet components (classes) for the controller. These controllers are notified by one or more "facade" servlets depending on the HTTP Request content (URL, parameters, etc, there's usually some kind of mapping between various combinations of HTTP Request elements and corresponding controller intances). In this way the controller really deals only with creating the model and notifying the view, it doesn't deal with the low level HTTP stuff.
Finally, as a side note, you should know that a Servlet, in order to be instantiated, must be deployed in a Java EE Web Server (like Tomcat), there's no "main" method (not one that you have to write anyway) where you manually instantiate them.
3 . About the Facade Servlet and separate (non-servlet) controllers
The idea here is to separate the low level transport/communications stuff from your MVC implementation. The MVC doesn't really specify anything about such things, and indeed there's no obvious place for them in a MVC implementation. On the other hand your Servlet does do HTTP, that's how it works. So taking all these into account it's good to NOT make the Servlet into a MVC controller, but rather have it only deal with incoming HTTP requests and then dumbly just pass them on to the appropriate controller, effectively acting as a Facade for all those controllers back there.
In practice what you can do is decide upon a system which will map an HTTP Request to a controller:
you decide what part of the HTTP request is taken into account to identify a controller. Typically it will be the request URL such that when an incoming request for "/mySite/listProducts" comes in, the Facade servlet will extract the relevant information from the request and pass it to the corresponding controller, then wait for said controller to prepare the model and display the view
you decide how to actually implement this mapping. You can just make a flat file stating things such as the URL pattern and the corresponding Controller class or instance, something like this:
In the above example, I've chosen a wider URL pattern for the second controller, because the specific URL demanding for Product Details might contain at the end of the path some kind of identifier for the specific product it wants details on, something like /mySite/productDetails/pinkFedoraHat and I want any and all such requests to go to the ProductDetails controller
Then when the app starts, the Facade Servlet is configured with this file, and then instanciates and delegates to the needed controller.
- a second mapping you might need to do is between controller and view. You may want one controller to redirect to multiple views, depending on how it was addressed. You can do this similarly by making an URL pattern to JSP map. However this is really optional.
Also, as this is a pretty obvious pattern, there are already implementations of it in various Java frameworks: Strust2, Spring MVC, (these 2 are for the first type of MVC, the controllers-nudges-view-to-update type),