Modeling Other Servlet Aspects

Other aspects of servlets that warrant modeling are servlet forward, servlet include, ServletContext, and Servlet Session Management. The following sections discuss these aspects in more detail.

Servlet Forward

Servlet forward is a special kind of relationship, and modeling it explicitly can help clarify the overall application logic. For example, it can shed light on the flow of the processing logic. In complicated forward chains, the relationship may be indicative of some algorithm being implemented. Two specific approaches help to identify the overall application logic in this regard.

First, on the class diagram, label the relationships between the servlets that invoke forward on other Web components with the <<forward>> relationship. An example is shown in Figure 10-7.

Figure 10-7. Modeling servlet forwarding on a class diagram


For more complicated servlet chaining, an activity diagram can be used to show the overall interaction. If desired, request and response objects with attributes appropriately updated at specific points can be shown to demonstrate the overall algorithm. See Figure 10-8.

Figure 10-8. Modeling servlet forwarding with activity diagram


In this case, we have labeled the transition with the <<forward>> stereotype to emphasize that it represents a forward relationship between the elements involved. The comments shown for each occurrence of the response object identify what happens as the request and response objects pass through the chain.

Servlet Include

Include is another significant and special relationship as it affects the results produced by a servlet. In fact, include may be used as a means to structure and organize the overall output in a modular fashion. Servlet include relationships are modeled in the same fashion as the forward relationship, that is, as a unidirectional association stereotyped <<include>>. The direction of the association is from the including servlet to the resource being included. An example is shown in Figure 10-9. In the example, a servlet responsible for creating a mortgage amortization table includes header and footer servlets whose sole purpose is to generate the page header and footer, respectively.

Figure 10-9. Servlet include relationship


ServletContext

Each servlet runs in some environment. The ServletContext provides information about the environment the servlet is running in. A servlet can belong to only one ServletContext as determined by the administrator. Typically, one ServletContext is associated with each Web application deployed in a container. In the case of distributed containers, one ServletContext is associated with one Web application per virtual machine.

The ServletContext interface can be used by servlets to store and retrieve information and share information among servlets. A servlet obtains the ServletContext it is running in by using the getServletContext method.

Some of the basic services provided by the ServletContext interface are

  • setAttribute: Stores information in the context

  • getAttribute: Retrieves information stored in the ServletContext

  • getAttributeNames: Obtains the names of attributes in the context

  • removeAttribute: Removes an attribute in the context

An approach similar to the one discussed for servlet forwarding and shown in Figure 10-8 can be employed to model servlet interactions with the ServletContext.

Servlet Session Management

Given the stateless nature of the HTTP protocol, managing repeat interaction and dialog with the same client (such as that required for an ongoing shopping session) poses some serious challenges. There are various means of overcoming these challenges:

  • Hidden fields: Hidden fields are embedded within the page displayed to the client. These fields are sent back to the client each time a new request is made, thereby permitting client identification each time a client makes a request.

  • Dynamic URL rewriting: Extra information is added to each URL the client clicks on. This extra information is used to uniquely identify each client for the duration of the client session, for example, adding a “?sessionid=97859” to the end of each URL the client clicks to identify that the request is associated with session id 97859.

  • Cookies: Stored information can later be passed back to the client repeatedly. The Web server provides the cookie to the browser. Cookies are one of the more popular means of setting up a servlet session.

  • Server-side session object: Cookies and URL encoding suffer from limitations on how much information can be sent back with each request. In server-side session management, the session information is maintained on the server in a session object and can be accessed as required. Server-side session objects are expensive to use, so it is best to use them sparingly.

The Java Servlet Application Programming Interface (API) provides abstractions that directly support some of the session management techniques discussed in the preceding list.

The core abstraction provided by the servlet API is the HTTP session, which facilitates handling of multiple requests from the same user.

Figure 10-10 gives an example of servlet session management.

Figure 10-10. Servlet session usage
import.javax.servlet.http.*;
...
// locate a session object
HttpSession theSession = request.getSession (true);
...
// add data to the session object
theSession.putValue("Session.id", "98579");
...
// get the data for the session object
sessionid =  theSession.getValue("Session.ID");

Activity diagrams can be used to model the servlet and session interaction. This is similar to the approach discussed for servlet forwarding and shown in Figure 10-8.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.113.55