In Chapter 8, we discussed the use of boundary objects to capture and isolate interaction between a use case and external entities such as with other sub systems and with users. JSPs provide an effective yet simple vehicle for the interaction of the latter type, that is, with users of the system. For instance, consider the HomeDirect use cases identified in Chapter 16. Each use case that interacts with the customer actor means that some sort of user interface is required. There is also some form of interface required for the Login/Logout use cases, which are included by the other use cases.
To understand how JSPs are used in enterprise apps, let's start with the Login use case. A login Web page, representing the login boundary object, would be appropriate for presentation to the user when the user attempts to use the banking system initially and initiates the Login use case. Additionally, there is a need for the user to enter a username and password via the Web page for validation by the system.
A controller is also required for the Login use case, as identified via the login control object during the analysis. Because we want to have the ability to change the presentation easily, we have chosen
to follow the Model 2 architecture for our application and will use the JSPs primarily for presentation rather than as replacements for servlets.
In light of this decision, we will create a servlet to handle the processing of the login form. Although use case control objects often merge at design time, this use case acts as a "gatekeeper" of sorts in the sense that none of the other use cases can be executed until this one is successful. Given this prerequisite, it is appropriate to keep the login validation isolated from the rest of the application. Figure 11-7 shows the overall structure of the Login use case.
Figure 11-7. Login use case design
Let's take a quick walkthrough to clarify what is occurring in Figure 11-7. The Login.jsp is the entry point into the use case. It builds the login client, which includes a LoginForm to allow the user to enter information. When the form is filled in and submitted by the user, the LoginServlet processes it by interacting with the appropriate entity objects to verify the information entered (we discuss the entity objects mapping to the solution domain in Chapter 13). If the login fails, the login servlet
displays an error message, and then restarts at Login.jsp. If the login is successful, it is forwarded to another entity (not shown).
Note the use of Banner.jsp and Footer.jsp. Although we could have included the information directly into individual JSPs, we have chosen this approach as it permits better reuse across the entire application and also serves to keep these details isolated.
A common technique in Model 2 is to use a JavaBean as a means of passing information between a servlet and a JSP. The idea is for the servlet to obtain and set the information in a JavaBean, and then forward the request on to the JSP. The JSP in turn uses the JavaBean to obtain and publish the information to the end user of the information. We use this technique for communication between the centralized controller for the remaining use cases and the various pages for displaying the results to the end user.
Figure 11-8 shows an example of this technique in the context of the List transactions use case.
Figure 11-8. Using JavaBeans to share information
In the figure, Main.jsp provides the anchor page for invoking the various commands available to HomeDirect users. Any commands invoked by the user are submitted to the MainServlet, which then coordinates the activities with the control and entity objects (not shown but discussed in detail in
Chapter 12 and Chapter 13, respectively). When MainServlet has gathered all the information required for the response, it places the information in the JavaBean and forwards the request on to the JSP. The JSP then accesses the bean using the jsp: useBean tag and publishes it to the end user. Figure 11-9 illustrates the dynamics associated with this scenario via a sequence diagram.
Figure 11-9. Sequence diagram detailing the login scenario
The code fragment associated with setting up the TransactInfo bean for use by the ListTransacts.jsp is shown in Figure 11-10.
Figure 11-10 Using a JavaBean to share information with a JSP // Get the user session
HttpSession session = request.getSession(true); ...
// Find collection of transacts ...
// Create bean to pass info to JSP page
TransactInfo transactInfo = new TransactInfo(transacts); session.setAttribute("TransactInfo", transactInfo);
...
RequestDispatcher dispatcher =
getServletContext().getRequestDispatcher("/ListTransacts.jsp" );
dispatcher.forward(request, response);
Summary
JSPs are intended to separate content from presentation. They are conceptually very similar to servlets. JSPs are essentially similar to a server-side scripting technology, the key difference being that JSPs are compiled, whereas scripts are interpreted.
Although a JSP is equivalent to a servlet, a JSP is not intended as a replacement for a servlet. Two development paradigms, generally referred to as Model 1 and Model 2, provide the underpinnings for effective use of servlets and JSPs.
A JSP consists of Java code embedded within a structured document such as HTML or XML. Tags are used to mark up specific pieces of JSP code. Users can also create their own tag libraries in the form of taglib libraries.
In the UML, JSPs and associated technology relationships are modeled by stereotyping existing UML constructs. A JSP is modeled as being composed of two distinct conceptual elements: the client page and the server page. The relationship between the client page and the server page is modeled as a build relationship. Client and server pages can also have relationships with other client and server pages.
Chapter 12. Session Beans
• Introduction to Enterprise JavaBeans
• EJB Views and the UML
• Session Beans
• Types of Session Beans and Conversational State
• Instance Passivation
• Transactions
• Session Bean Technology
• Modeling Interface Behavior
• Session Bean Life Cycle
• Modeling Session Bean Relationships
• Managing Performance
• The Local Client
• Identifying Session Beans in Enterprise Applications
• Summary
Process Check: Once again our focus is on design as we progress through the Rational Unified Process (RUP) analysis and design discipline. We also discuss some aspects of implementation in the context of the EJB technology.
In Chapter 10, we decided to evolve the control object into a pair of servlets and have another control object focus on the internal interaction and business logic. That internal interaction and business logic is the domain of a specific type of Enterprise JavaBeans (EJB) known as a session bean.
In this chapter, we start with a general discussion of EJB, and then look at how session beans are modeled in the Unified Modeling Language (UML). We later dig into the key technological aspects of session beans, and then finish with a discussion of where they fit into our evolving HomeDirect online banking example.