Let us start with Session Tracking:-
Session tracking is the process of maintaining information about Web site visitors as they move from page to page. It requires some work on the part of the Web developer since there's no built-in mechanism for it. The connection from a browser to a Web server occurs over the stateless Hypertext Transfer Protocol (HTTP).
There are a number of ways to handle session tracking, but our focus is on the easy-to-use yet powerful HttpSession interface provided by the Java Servlet specification. Before we get into the HttpSession interface, let's look at some other ways of maintaining state.
Session-Tracking Techniques
At one time Web developers used Web site visitors' IP addresses to track the sessions. This approach was inflexible and had many flaws. The main problem was that proxy servers eliminated the use of individual IP addresses. Users no longer had unique addresses, so this technique couldn't work properly. Another way of handling session tracking is the use of the HTML hidden field:
<INPUT TYPE="hidden" NAME="user"VALUE="BAJAJ">
This technique required server-side scripting that would dynamically generate the HTML code that contained the "user" field. Server-side code was also required to read the field and match it to information about this user on the server.
Another session-tracking technique is URL rewriting. In this approach, identification field(s) are appended to the end of each URL for a Web site. The following HTML code demonstrates this method:
<a href ="/orderform.htm?user=bajaj">Order Now!</A>
This approach is similar to hidden fields. The difference is that hidden fields can only be used in a form.
A common way of session tracking is the use of cookies. A cookie is information that's stored as a name/value pair and transmitted from the server to the browser. Cookies containing unique user information can be used to tie specific visitors to information about them on the server.
The following code shows how to create a new cookie:
Cookie user = new Cookie("user","bajaj");
user.setMaxAge(3600);
response.addCookie(user);
This code creates a cookie with a name of "user" and a value of "bajaj". The cookie's expiration date is set with the setMaxAge() method to 3,600 seconds from the time the browser receives the cookie. The following code demonstrates how you would retrieve the value for a specific cookie:
String user = "";
Cookie[] cookies = request.getCookies();
if (cookies != null) {
for (int i = 0; i < cookies.length; i++) {
if (cookies[i].getName().equals("user")) user =
cookies[i].getValue();
}
}
In this code, an array of cookies is retrieved from the HttpServletRequest object using the getCookies() method. The array is walked through until a cookie with the name of "user" is returned by the getName() method. Once the cookie is found, the getValue() method is called to retrieve the value of the cookie.
The use of cookies provides a flexible and easy option for handling session tracking; however, it does present some problems. The information in the cookie is stored on the client's browser in a text file that can be easily read and manipulated, and this information is transmitted unsecured across the Internet. But the main problem is that they can be disabled through a setting in the Web browser. Web sites that rely on cookies for session tracking will be unable to track users who have disabled cookies.
Sessions in Java
The session management techniques we have looked at so far all have a common security issue: they transmit data in plain text. A powerful session-tracking solution is needed that's more secure and flexible. This is where the Java HttpSession API comes in. The HttpSession API provides a simple mechanism for storing information about individual users on the application server. The API provides access to a session object that can be used to store other objects. The ability to tie objects to a particular user is important when working in an object-oriented environment. It allows you to quickly and efficiently save and retrieve JavaBeans that you may be using to identify your site's visitors, to hold product information for display on your online store, or to track products that potential customers have placed in their shopping carts.
A session object is created on the application server, usually in a Java servlet or a JavaServer Page. The object is stored on the application server and a unique identifier called a session ID is assigned to it. The session object and session ID are handled by a session manager on the application server. Figure 1 illustrates this relationship. Each session ID assigned by the application server has zero or more key/value pairs tied to it. The values are objects that you place in the session. Assign each of those objects a name, and each name must have an object with it because a null is not allowed.
For this session-tracking technique to work, the session ID must be sent to the client's computer. A cookie is used to store the session ID on the Web site visitor's computer. This is automatically handled by the application server. Simply create the session object and begin using it. The application server will, by default, create the session ID and store it in a cookie. The browser will send the cookie back to the server every time a page is requested. The application server, via the server's session manager, will match the session ID from the cookie to a session object. The session object is then placed in the HttpServletRequest object and you retrieve it with the getSession() method.
Some Web site visitors have cookies disabled in their browsers. So we get around this problem and continue using sessions, use URL rewriting in your code. URL rewriting appends the session ID to the URL for every page that's requested. The only problem here is that you must rewrite every link in your HTML code as well as those from servlet to servlet, or servlet to JSP.
The procedure for URL rewriting is quite simple and requires only the use of two methods found in the HttpServletResponse interface. These two methods, encodeURL() and encodeRedirectURL(), are used to append the session ID to the URL. This allows the server to track users as they move through your Web pages, but it requires that every URL be rewritten. The string returned by the methods will have the session ID appended to it only if the server determines that it's required. If the user's browser supports cookies, the returned URL will not be altered. Also, the returned URL won't be altered if the application server is configured to not use URL rewriting. The format of the altered URL will vary based on different application server implementations; however, the common format will be the addition of a parameter, such as "sessionID=uniqueIDnumber". The parameter name (in this case "sessionID") is usually controlled through a configuration setting on the server. The value of the parameter ("uniqueIDnumber" in this example) is the unique session ID assigned by the server's session manager and is a long series of letters and numbers. The following line of HTML code from a JSP creates a link to another JSP:
<a href="/products/product.jsp">Product Listing</a>
Clicking on this link would send the user to the product.jsp page. Using URL rewriting, the same code would be written as follows:
<a href="<%= response.encodeURL("/products/product.jsp")
%>">Product Listing</a>
The returned string from the encodeURL() method would contain the session ID. On a Tomcat 3.2 application server, the result of this line of code would be:
<a href="http://www.yourservername.com/products/
product.jsp;$sessionid$xxxx">Product Listing</A>
The xxxx would actually be a unique session ID generated by the server. The other method you can use for rewriting URLs is the encodeRedirectURL(). It's used only in a servlet or JSP that calls the sendRedirect() method of the HttpServlet-Response interface. The following code is a standard redirection statement:
response.sendRedirect("http://www.yourservername.com/
products/sale.jsp");
Using URL rewriting, the code would be:
response.sendRedirect(response.encodeRedirectURL(
"http://www.yourservername.com/products/sale.jsp"));
The application server handles the encodeRedirectURL() method a little differently than the encodeURL() method; however, each method produces the same result.
You should now have a good understanding of how the session ID is tracked and matched to a session object on the server. The first step in using the session object is creating it. The method getSession() is used to create a new session object and to retrieve an already existing one. The getSession() method is passed a Boolean flag of true or false. A false parameter indicates that you want to retrieve a session object that already exists. A true parameter lets the session manager know that a session object needs to be created if one does not already exist. The following line of code demonstrates the use of getSession():
HttpSession session = request.getSession(true);
The getSession() method will return the session object. A new session object is created if one does not already exist. The server uses the session ID to find the session object. If a session ID is not found in a cookie or the URL, a new session object is created. You would probably use only the getSession() method with a true parameter at one point in your Web application. This would be the starting point of your site, possibly after the visitor has successfully logged in. Other servlets in your application should use the getSession(false) method. This will return a current session object or null. It does not generate a new session if one doesn't already exist.
A number of methods are defined in the Java Servlet specification.The methods you'll use most often and the ones we'll focus on are:
setAttribute(String name, Object value): Binds an object to this session using the name specified. Returns nothing (void).
getAttribute(String name): Returns the object bound with the specified name in this session, or null if no object is bound under this name.
removeAttribute(String name): Removes the object bound with the specified name from this session. Returns nothing (void).
invalidate(): Invalidates this session and unbinds any objects bound to it. Returns nothing (void).
isNew(): Returns a Boolean with a value of true if the client does not yet know about the session or if the client chooses not to join the session.
For an example in using sessions, we'll look at session management code that could be used for an online banking application that will allow customers to view their account information. The design of the application will follow the Model-View-Controller (MVC) architecture. The model, or data and business logic, will be represented by JavaBeans; the view will be through JavaServer Pages; and the control of the application will be handled by servlets. The ideas in these examples can easily be implemented in other types of Web applications.
An online banking application should have an HTML login page where the customer can enter a login name and password in a form. The form will submit (or post) the name and password to a login servlet. The first thing the servlet needs to do is verify the username and password. To stick with the topic at hand (sessions), we'll look only at the code needed to handle the session. After the customer has been verified, a Customer JavaBean can be created. The Customer bean will contain the basic information about this visitor and will be stored in the session. We want to create a new session object, but we also want to invalidate a session that may already exist. To do this, we need to retrieve the existing object (or create a new one) and check if it's a new session using the isNew() method. If it's not a new session object, we need to invalidate it using the invalidate() method. In the servlet, we can accomplish this with the following code:
HttpSession session = request.getSession (true);
if (session.isNew() == false) {
session.invalidate();
session = request.getSession(true);
}
The first line of code generates a new session object, or retrieves an existing one. The second line sees if the session is new by checking the value from isNew(). A true tells you the session was just created; a false means this user already had a session and you need to invalidate it. One possible reason the user would have an old session is that he or she has two accounts and logged in on one, then tried to log in on the other.
You can now add the Customer JavaBean to the session for future use. The process of placing an object into the session object is known as binding. The Customer object can be bound to the session using the setAttribute() method as follows:
session.setAttribute("CustomerBean", Customer);
Since we're working on a bank's Web site, security is a priority. To be secure, every JSP and servlet needs to verify that this user is an authorized customer before displaying any information. To accomplish this, each servlet should contain code that looks in the session for a Customer object and sends any customers who do not have this object to a login page. The following code handles this:
Customer customerBean = (Customer)
session.getAttribute('CustomerBean');
if (customerBean == null) {
response.sendRedirect
("https://www.yourservername.com/login.htm");
return;
}
The customer will have a valid Customer JavaBean in the session if he or she logged in properly. A getAttribute() on a name that does not exist in the session will always return null. Visitors with a null value need to log in, so we redirect them to a login page. This code should be placed at the top of the JSPs to prevent unauthorized use of the site. The code should also be placed in the servlets. Remember that the JSP creates the session variable for you, and in a servlet you must create it yourself. Keep in mind that this is just one way of handling security for a Web site. Some Web application servers will handle authentication and authorization for you. This example is just a simple demonstration on session management. Your Web application may require more advanced security measures.
You may have noticed that the object returned by the getAttribute() method is cast into a Customer object. This is necessary for any object bound to the session. The object is stored in the session as an Object type. To use the object in your code, you must convert it (or cast it) back to the type of object it is.
As customers move through your site, they may wish to retrieve various pieces of information about their accounts. For example, they may be able to view their checking account balance by clicking on a menu option. Following the MVC architecture, the link would send them to a servlet that would verify who they are and then create a CheckingAccount JavaBean. This object would then be stored in the session using the setAttribute() method, then the servlet would send the customer to a JSP that uses the CheckingAccount JavaBean to display the information about the customer's account.
There may be times when you want to store something in the session other than a JavaBean, such as a text string or a number. You need to remember that you can only bind objects to the session. Text may be stored as a String object. You can put a number in the session as an Integer object. The following code demonstrates how to save a line of text and a number in the session:
session.setAttribute("text","A line of text.");
session.setAttribute("number", new Integer(10750));
Remember to cast the objects when they are retrieved:
String myText = (String) session.getAttribute("text");
int myNumber = ((Integer) session.getAttribute
('number')).intValue();
Because the session is so easy to use, you may overuse it. Simple messages from a servlet to a JSP can be placed in the session as String objects, but this is not the most efficient way. Soon you'll find that your session is loaded with messages, and most of them are no longer needed. If you find that you're passing simple strings back and forth in the session, perhaps you should consider wrapping up those messages in a special JavaBean. This would keep the session more organized. The session objects for each user of a Web site are stored in memory on the server. Throwing unnecessary information into the session reduces the server's memory resources. Store only essential information in the session and use the removeAttribute() method to clean out objects after you're finished with them.
The use of the session will not only make it easier for you to program a site, but it should also help make the Web visit better for the user. The use of the beans and the session allows you to write JSPs that are customized for each user. For our bank scenario, we could use the information in the Customer bean to create personalized pages for each visitor. We can also use the bean to prepopulate forms for the customer. For example, you could use a JavaBean to store the results from a form that a visitor fills out to request information about services offered. If the user forgot to fill in a required field, you could use the JavaBean to store error messages from a servlet and then display them in the JSP. You could also populate the fields that the visitor just filled in instead of making the visitor fill out the form again.
The session is not intended to be used as a persistent place to store information about a visitor. Each visitor will be assigned a new session every time he or she logs in. A back-end database will be needed if you want to store information about individual users. The session should just be used to track the user during one visit to your site. In cases where you have a large Web site and are running multiple, redundant application servers, you'll need an application server that can handle sessions across servers. This is usually handled by placing session information into a database instead of local memory so each application server can access the information. And many of the commercial application servers will be able to do this for you.
Conclusion
The use of session tracking is an important design issue because of the complexity of today's Web sites. As Java developers, we have access to a powerful and robust session manager through the use of the HttpSession API. The session examples that we went over in this article cover the main capabilities of the session API. Learning all of Java's session management features will make your job as a Web developer easier and help you create a better experience for your Web site visitors.
Session tracking is the process of maintaining information about Web site visitors as they move from page to page. It requires some work on the part of the Web developer since there's no built-in mechanism for it. The connection from a browser to a Web server occurs over the stateless Hypertext Transfer Protocol (HTTP).
There are a number of ways to handle session tracking, but our focus is on the easy-to-use yet powerful HttpSession interface provided by the Java Servlet specification. Before we get into the HttpSession interface, let's look at some other ways of maintaining state.
Session-Tracking Techniques
At one time Web developers used Web site visitors' IP addresses to track the sessions. This approach was inflexible and had many flaws. The main problem was that proxy servers eliminated the use of individual IP addresses. Users no longer had unique addresses, so this technique couldn't work properly. Another way of handling session tracking is the use of the HTML hidden field:
<INPUT TYPE="hidden" NAME="user"VALUE="BAJAJ">
This technique required server-side scripting that would dynamically generate the HTML code that contained the "user" field. Server-side code was also required to read the field and match it to information about this user on the server.
Another session-tracking technique is URL rewriting. In this approach, identification field(s) are appended to the end of each URL for a Web site. The following HTML code demonstrates this method:
<a href ="/orderform.htm?user=bajaj">Order Now!</A>
This approach is similar to hidden fields. The difference is that hidden fields can only be used in a form.
A common way of session tracking is the use of cookies. A cookie is information that's stored as a name/value pair and transmitted from the server to the browser. Cookies containing unique user information can be used to tie specific visitors to information about them on the server.
The following code shows how to create a new cookie:
Cookie user = new Cookie("user","bajaj");
user.setMaxAge(3600);
response.addCookie(user);
This code creates a cookie with a name of "user" and a value of "bajaj". The cookie's expiration date is set with the setMaxAge() method to 3,600 seconds from the time the browser receives the cookie. The following code demonstrates how you would retrieve the value for a specific cookie:
String user = "";
Cookie[] cookies = request.getCookies();
if (cookies != null) {
for (int i = 0; i < cookies.length; i++) {
if (cookies[i].getName().equals("user")) user =
cookies[i].getValue();
}
}
In this code, an array of cookies is retrieved from the HttpServletRequest object using the getCookies() method. The array is walked through until a cookie with the name of "user" is returned by the getName() method. Once the cookie is found, the getValue() method is called to retrieve the value of the cookie.
The use of cookies provides a flexible and easy option for handling session tracking; however, it does present some problems. The information in the cookie is stored on the client's browser in a text file that can be easily read and manipulated, and this information is transmitted unsecured across the Internet. But the main problem is that they can be disabled through a setting in the Web browser. Web sites that rely on cookies for session tracking will be unable to track users who have disabled cookies.
Sessions in Java
The session management techniques we have looked at so far all have a common security issue: they transmit data in plain text. A powerful session-tracking solution is needed that's more secure and flexible. This is where the Java HttpSession API comes in. The HttpSession API provides a simple mechanism for storing information about individual users on the application server. The API provides access to a session object that can be used to store other objects. The ability to tie objects to a particular user is important when working in an object-oriented environment. It allows you to quickly and efficiently save and retrieve JavaBeans that you may be using to identify your site's visitors, to hold product information for display on your online store, or to track products that potential customers have placed in their shopping carts.
A session object is created on the application server, usually in a Java servlet or a JavaServer Page. The object is stored on the application server and a unique identifier called a session ID is assigned to it. The session object and session ID are handled by a session manager on the application server. Figure 1 illustrates this relationship. Each session ID assigned by the application server has zero or more key/value pairs tied to it. The values are objects that you place in the session. Assign each of those objects a name, and each name must have an object with it because a null is not allowed.
For this session-tracking technique to work, the session ID must be sent to the client's computer. A cookie is used to store the session ID on the Web site visitor's computer. This is automatically handled by the application server. Simply create the session object and begin using it. The application server will, by default, create the session ID and store it in a cookie. The browser will send the cookie back to the server every time a page is requested. The application server, via the server's session manager, will match the session ID from the cookie to a session object. The session object is then placed in the HttpServletRequest object and you retrieve it with the getSession() method.
Some Web site visitors have cookies disabled in their browsers. So we get around this problem and continue using sessions, use URL rewriting in your code. URL rewriting appends the session ID to the URL for every page that's requested. The only problem here is that you must rewrite every link in your HTML code as well as those from servlet to servlet, or servlet to JSP.
The procedure for URL rewriting is quite simple and requires only the use of two methods found in the HttpServletResponse interface. These two methods, encodeURL() and encodeRedirectURL(), are used to append the session ID to the URL. This allows the server to track users as they move through your Web pages, but it requires that every URL be rewritten. The string returned by the methods will have the session ID appended to it only if the server determines that it's required. If the user's browser supports cookies, the returned URL will not be altered. Also, the returned URL won't be altered if the application server is configured to not use URL rewriting. The format of the altered URL will vary based on different application server implementations; however, the common format will be the addition of a parameter, such as "sessionID=uniqueIDnumber". The parameter name (in this case "sessionID") is usually controlled through a configuration setting on the server. The value of the parameter ("uniqueIDnumber" in this example) is the unique session ID assigned by the server's session manager and is a long series of letters and numbers. The following line of HTML code from a JSP creates a link to another JSP:
<a href="/products/product.jsp">Product Listing</a>
Clicking on this link would send the user to the product.jsp page. Using URL rewriting, the same code would be written as follows:
<a href="<%= response.encodeURL("/products/product.jsp")
%>">Product Listing</a>
The returned string from the encodeURL() method would contain the session ID. On a Tomcat 3.2 application server, the result of this line of code would be:
<a href="http://www.yourservername.com/products/
product.jsp;$sessionid$xxxx">Product Listing</A>
The xxxx would actually be a unique session ID generated by the server. The other method you can use for rewriting URLs is the encodeRedirectURL(). It's used only in a servlet or JSP that calls the sendRedirect() method of the HttpServlet-Response interface. The following code is a standard redirection statement:
response.sendRedirect("http://www.yourservername.com/
products/sale.jsp");
Using URL rewriting, the code would be:
response.sendRedirect(response.encodeRedirectURL(
"http://www.yourservername.com/products/sale.jsp"));
The application server handles the encodeRedirectURL() method a little differently than the encodeURL() method; however, each method produces the same result.
You should now have a good understanding of how the session ID is tracked and matched to a session object on the server. The first step in using the session object is creating it. The method getSession() is used to create a new session object and to retrieve an already existing one. The getSession() method is passed a Boolean flag of true or false. A false parameter indicates that you want to retrieve a session object that already exists. A true parameter lets the session manager know that a session object needs to be created if one does not already exist. The following line of code demonstrates the use of getSession():
HttpSession session = request.getSession(true);
The getSession() method will return the session object. A new session object is created if one does not already exist. The server uses the session ID to find the session object. If a session ID is not found in a cookie or the URL, a new session object is created. You would probably use only the getSession() method with a true parameter at one point in your Web application. This would be the starting point of your site, possibly after the visitor has successfully logged in. Other servlets in your application should use the getSession(false) method. This will return a current session object or null. It does not generate a new session if one doesn't already exist.
A number of methods are defined in the Java Servlet specification.The methods you'll use most often and the ones we'll focus on are:
setAttribute(String name, Object value): Binds an object to this session using the name specified. Returns nothing (void).
getAttribute(String name): Returns the object bound with the specified name in this session, or null if no object is bound under this name.
removeAttribute(String name): Removes the object bound with the specified name from this session. Returns nothing (void).
invalidate(): Invalidates this session and unbinds any objects bound to it. Returns nothing (void).
isNew(): Returns a Boolean with a value of true if the client does not yet know about the session or if the client chooses not to join the session.
For an example in using sessions, we'll look at session management code that could be used for an online banking application that will allow customers to view their account information. The design of the application will follow the Model-View-Controller (MVC) architecture. The model, or data and business logic, will be represented by JavaBeans; the view will be through JavaServer Pages; and the control of the application will be handled by servlets. The ideas in these examples can easily be implemented in other types of Web applications.
An online banking application should have an HTML login page where the customer can enter a login name and password in a form. The form will submit (or post) the name and password to a login servlet. The first thing the servlet needs to do is verify the username and password. To stick with the topic at hand (sessions), we'll look only at the code needed to handle the session. After the customer has been verified, a Customer JavaBean can be created. The Customer bean will contain the basic information about this visitor and will be stored in the session. We want to create a new session object, but we also want to invalidate a session that may already exist. To do this, we need to retrieve the existing object (or create a new one) and check if it's a new session using the isNew() method. If it's not a new session object, we need to invalidate it using the invalidate() method. In the servlet, we can accomplish this with the following code:
HttpSession session = request.getSession (true);
if (session.isNew() == false) {
session.invalidate();
session = request.getSession(true);
}
The first line of code generates a new session object, or retrieves an existing one. The second line sees if the session is new by checking the value from isNew(). A true tells you the session was just created; a false means this user already had a session and you need to invalidate it. One possible reason the user would have an old session is that he or she has two accounts and logged in on one, then tried to log in on the other.
You can now add the Customer JavaBean to the session for future use. The process of placing an object into the session object is known as binding. The Customer object can be bound to the session using the setAttribute() method as follows:
session.setAttribute("CustomerBean", Customer);
Since we're working on a bank's Web site, security is a priority. To be secure, every JSP and servlet needs to verify that this user is an authorized customer before displaying any information. To accomplish this, each servlet should contain code that looks in the session for a Customer object and sends any customers who do not have this object to a login page. The following code handles this:
Customer customerBean = (Customer)
session.getAttribute('CustomerBean');
if (customerBean == null) {
response.sendRedirect
("https://www.yourservername.com/login.htm");
return;
}
The customer will have a valid Customer JavaBean in the session if he or she logged in properly. A getAttribute() on a name that does not exist in the session will always return null. Visitors with a null value need to log in, so we redirect them to a login page. This code should be placed at the top of the JSPs to prevent unauthorized use of the site. The code should also be placed in the servlets. Remember that the JSP creates the session variable for you, and in a servlet you must create it yourself. Keep in mind that this is just one way of handling security for a Web site. Some Web application servers will handle authentication and authorization for you. This example is just a simple demonstration on session management. Your Web application may require more advanced security measures.
You may have noticed that the object returned by the getAttribute() method is cast into a Customer object. This is necessary for any object bound to the session. The object is stored in the session as an Object type. To use the object in your code, you must convert it (or cast it) back to the type of object it is.
As customers move through your site, they may wish to retrieve various pieces of information about their accounts. For example, they may be able to view their checking account balance by clicking on a menu option. Following the MVC architecture, the link would send them to a servlet that would verify who they are and then create a CheckingAccount JavaBean. This object would then be stored in the session using the setAttribute() method, then the servlet would send the customer to a JSP that uses the CheckingAccount JavaBean to display the information about the customer's account.
There may be times when you want to store something in the session other than a JavaBean, such as a text string or a number. You need to remember that you can only bind objects to the session. Text may be stored as a String object. You can put a number in the session as an Integer object. The following code demonstrates how to save a line of text and a number in the session:
session.setAttribute("text","A line of text.");
session.setAttribute("number", new Integer(10750));
Remember to cast the objects when they are retrieved:
String myText = (String) session.getAttribute("text");
int myNumber = ((Integer) session.getAttribute
('number')).intValue();
Because the session is so easy to use, you may overuse it. Simple messages from a servlet to a JSP can be placed in the session as String objects, but this is not the most efficient way. Soon you'll find that your session is loaded with messages, and most of them are no longer needed. If you find that you're passing simple strings back and forth in the session, perhaps you should consider wrapping up those messages in a special JavaBean. This would keep the session more organized. The session objects for each user of a Web site are stored in memory on the server. Throwing unnecessary information into the session reduces the server's memory resources. Store only essential information in the session and use the removeAttribute() method to clean out objects after you're finished with them.
The use of the session will not only make it easier for you to program a site, but it should also help make the Web visit better for the user. The use of the beans and the session allows you to write JSPs that are customized for each user. For our bank scenario, we could use the information in the Customer bean to create personalized pages for each visitor. We can also use the bean to prepopulate forms for the customer. For example, you could use a JavaBean to store the results from a form that a visitor fills out to request information about services offered. If the user forgot to fill in a required field, you could use the JavaBean to store error messages from a servlet and then display them in the JSP. You could also populate the fields that the visitor just filled in instead of making the visitor fill out the form again.
The session is not intended to be used as a persistent place to store information about a visitor. Each visitor will be assigned a new session every time he or she logs in. A back-end database will be needed if you want to store information about individual users. The session should just be used to track the user during one visit to your site. In cases where you have a large Web site and are running multiple, redundant application servers, you'll need an application server that can handle sessions across servers. This is usually handled by placing session information into a database instead of local memory so each application server can access the information. And many of the commercial application servers will be able to do this for you.
Conclusion
The use of session tracking is an important design issue because of the complexity of today's Web sites. As Java developers, we have access to a powerful and robust session manager through the use of the HttpSession API. The session examples that we went over in this article cover the main capabilities of the session API. Learning all of Java's session management features will make your job as a Web developer easier and help you create a better experience for your Web site visitors.
No comments:
Post a Comment