A Model 1 architecture consists of a Web browser directly accessing Web-tier JSP pages. The JSP pages access Web-tier JavaBeans that represent the application model, and the next view to display (JSP page, servlet, HTML page, and so on) is determined either by hyperlinks selected in the source document or by request parameters. A Model 1 application control is decentralized, because the current page being displayed determines the next page to display. In addition, each JSP page or servlet processes its own inputs (parameters from GET or POST). In some Model 1 architectures, choosing the next page to display occurs in scriptlet code, but this usage is considered poor form. (See the design guideline Section 126.96.36.199 on page 89.)
A Model 2 architecture introduces a controller servlet between the browser and the JSP pages or servlet content being delivered. The controller centralizes the logic for dispatching requests to the next view based on the request URL, input parameters, and application state. The controller also handles view selection, which decouples JSP pages and servlets from one another. Model 2 applications are easier to maintain and extend, because views do not refer to each other directly. The Model 2 controller servlet provides a single point of control for security and logging, and often encapsulates incoming data into a form usable by the back-end MVC model. For these reasons, the Model 2 architecture is recommended for most interactive applications.
Session bean --> Communicates with entity beans and prepares DTOs (Value objects) Servlet--> Communiates with Session bean via Business Delegate and obtains DTOs JSP --> Displays DTOs
This makes sense because if we have to have two versions of same application, 1. one with standards jsp/servlets (J2SE) 2. other based on J2EE using EJBs etc then we can use the same JSPs/Servlets and change Business Delegates to query J2SE based implemenation without changing single line of code in Servlets and JSPs!!!