ServletContext, Session and Request attributes
A ServletContext attribute is an object bound into a context through ServletContext.setAttribute() method and which is available to all Servlets (thus JSP) in that context, or to other contexts via the getServletContext() method. By definition a context attribute exists locally in the VM where they were defined. So, they’re unavailable on distributed applications.
Session attributes are bound to a session, as a mean to provide state to a set of related HTTP requests. Session attributes are available ONLY to those Servlets which join the session. They’re also unavailable to different JVMs in distributed scenarios. Objects can be notified when they’re bound/unbound to the session implementing the HttpSessionBindingListener interface.
Request attributes are bound to a specific request object, and they last as far as the request is resolved or while it keep dispatched from servlet to servlet. They’re used more as communication channel between Servlets via the RequestDispatcher Interface (since you can’t add Parameters…) and by the container. Request attributes are very useful in web apps when you must provide setup information between information providers and the information presentation layer (a JSP) that is bound to a specific request and need not be available any longer, which usually happens with sessions without a rigorous control strategy.
Thus we can say that context attributes are meant for infra-structure such as shared connection pools, session attributes to contextual information such as user identification, and request attributes are meant to specific request info such as query results.
Role of Servlet
If we look at the Model-View-Controller (MVC) architecture, the targets of all the requests are Servlets that act as the Controller for the application. They analyze the request and collect the data required to generate a response into JavaBeans objects, which act as the Model for the application. Finally, the Controller Servlet dispatches the request to JSP pages. These pages use the data stored in the JavaBeans to generate a response. Thus, the JSP pages form the View of the application.
Therefore the “Controller Servlet” is used to manage the flow of the web application between the JSPs, with JSP being used primarily to display the results. The controller servlet uses JavaBeans to do things like getting a database connection (often from a pool of connections) and performing typical operations on the database (insert, update, etc.) using information stored in the request object passed on by the Controller Servlet. The result set is returned to a JSP for display. The Controller Servlet might also perform authentication of the user and prevent a command from being done twice (when a page is reloaded, for example).
In summary, a JSP initially passes a request object to the Controller Servlet, which figures out which JavaBeans to use and which JSP to pass the results onto next, based on parameters stored in the request object. See the figure below for MVC architecture:
Figure: The MVC Architecture
Servlet Environment
Servlet Container runs our Java web application using the JVM in a safe “sandboxed” environment. Servlet Container invokes our application’s Servlet classes to handle requests and prepare responses in this environment. To allow Servlet Container to distribute requests for applications across multiple web servers, and to prevent one application from interfering with another, the application runs in a restricted “sandbox” environment. In this environment, the application can execute code, store and query data in the Servlet Container data store, use the Servlet Container mail, URL fetch and users services, and examine the user’s web request and prepare the response.