Your proposed use of a Servlet for taking the request, EJBs for doing the heavy work, and (back in the Servlet) selecting a JSP to present the view to the user is what I prefer to do. It looks like one design Sun recommends in their J2EE "Blueprints", which you can download from http://java.sun.com/j2ee/blueprints
IBM has a similar design, although they don't talk about EJB. Check it out at
Regarding your questions:
2) Don't know. If by "forwarding the request from the Servlet to the EJB", you mean calling the EJB from the Servlet, that's what I do (although taking pains to minimize the number of calls, as they are expensive. You can have the EJB return a data object with any results you need to finish processing the request, and thereby make only a single EJB call from the Servlet). I don't really like calling the EJB tier from JSPs if I can help it, preferring to retrict JSPs to "presentation" (basic HTML with a few loop controls or calls to formatting code in regular JavaBeans components, not EJBs).
But this is just a preference. Some people still divide their code into Model, View, and Controller... but they use a separate JSP for the View and another for the Controller. The "Controller" JSP would do the work of the Servlet. In that case, I would call the EJB tier from a Controller JSP but not from one I'd set aside for the presentation layer.
However, I like using a Servlet instead just to help me keep the various components and their jobs mentally separate. Less confusing for someone new if they inherit something and want an idea of what a component does ("Oh, a Servlet. Probably is the initial point-of-entry, probably calls EJBs and then picks a JSP to show the results").
3) Still stuck on the "embed the EJB" part. Sorry! What do you mean? You could always get a data object returned from your EJB call, and in the Servlet, pass it to your select JSP for presentation via the request or session objects (see setAttribute in both HttpServletRequest and session in the Servlet 2.2 spec).