The trend is for servlets to receive get & post requests and control the heavy lifting of handling whatever needs to be done, such as looking up data to display or doing updates. Control is a key
word because they don't DO the work. They delegate to vanilla Java classes. If you're into Model-View-Controler stuff, the servlet asks the Model to do the real work. It is not unheard of to build an entire site with exactly one servlet that delegates everything to regular Java.
At the end of the work, stuff the results into a JavaBean and ask a JSP to render a page showing the results. The JSP can "usebean" to get the results.
A popular approach is to have NO JAVA in the JSP page, only tags from taglibs. The first argument I heard for this was to let people with HTML skills and no Java skills build the UI. That didn't do much for me, because we don't have HTML specialists. The better argument is that it helps you keep logic out of the view layer. If you put any Java in the JSP you may be on the slippery slope to inappropriate business logic and a NO JAVA rule helps avoid that.
The
Struts framework is one possible (and very nice) implementation of all this. Reading a good Struts overview would give you more ideas on the roles of servlets and JSPs.