Designing the Application

Next, you must decide what components are needed in each tier and how they interact with each other to achieve the required functionality.

Figure 21.4 shows the high-level design of the application. Please note that this diagram does not show all the components and their interactions. The diagram shows JSPs, servlets, enterprise beans, and database tables. The following sections discuss the various components in detail.

Designing the Business Logic Tier Components

The following discusses the key enterprise beans in the business logic tier:

• The concept of the student is central to the university registration application. Multiple clients must share behavior, such as creating a student account, verifying an existing account, and updating account information. Updates to the state of a student object must be written to the persistent store. The student object must live even when the client's session with the server is over. Therefore, the Student component is modeled as a container-managed persistence entity bean.

• SignOn is the authentication component that verifies the user login name and password. This component uses the User component to retrieve and store the user's login name and password. Such a component doesn't need to maintain client-specific state information across method invocations, so the same bean instance can be reused to service other client requests. This can be modeled as a stateless session bean.

• The Course component models the courses offered by the university. Because courses are persistent objects, Course is modeled as a container-managed persistence entity bean.

• EnrollmentCart models the shopping cart concept in a typical e-commerce Web site. While browsing the course catalog, a student can add courses to and remove courses from the EnrollmentCart. A cart must be allocated by the system for each student concurrently connected to the Web site. All the selected courses of a student will be added to the temporary cart. This cart is not a persistent object because the student can choose to abandon the cart. Therefore, in the application, EnrollmentCart is modeled as a stateful session bean. Alternatively, if you want the enrollment cart to survive a client machine or server crash, you must model it as an entity bean.

• A student places an order when he/she is ready to purchase the enrollment cart contents. The Order component must live even when the student's session with the application is over. Therefore, the Order component is modeled as a container-managed persistence entity bean.

• A student's order consists of one or more line items. Each line item represents a single course item that the student has ordered. This is modeled as the OrderLineItem component. Similar to Order, OrderLineItem must persist even when the student's session with the application is over. Therefore, OrderLineItem is modeled as a container-managed persistence entity bean. Also, the Order entity bean has a one-to-many bidirectional relationship with OrderLineItem. This relationship is modeled as a container-managed relationship.

• The OrderVerifier component is responsible for verifying the order's facts, such as the student's billing information, the classroom's capacity, and so on. We would like to enable the student to continue browsing the Web site and not require her to wait for the background processing to complete. This asynchronous processing can be best modeled using a message-driven bean. In the sample application, after the student submits an order, a Java Message Service (JMS) message is sent to a destination, where it will be processed by an OrderVerifier message-driven bean.

• A student can enroll in multiple courses and each course can have many students enrolled in it. The Enrollment CMP component models the join relationship between the students and the courses. The Student entity bean has a one-to-many relationship with Enrollment and the Course has a one-to-many relationship with Enrollment.

• The Mailer component is the stateless session bean responsible for sending e-mail messages. The AdminFacade component uses Mailer to send an e-mail confirmation to the student when the administrator approves the order for enrollment.

• The StudentFacade component provides a unified interface to student functionality. Instead of communicating directly with enterprise beans such as Student and Order, clients go through the simpler interface of StudentFacade. StudentFacade is modeled as a stateful session bean.

• The AdminFacade component provides a unified interface to the administrator functionality. Web components use a single AdminFacade component to access the administrator functionality. This component is modeled as a stateful session bean.

  Note

  The sample application uses the following approach for the business logic tier design.

  
  

• Provides a simple interface to complex functionality by using session bean façades.

  The session bean façades front the entity beans. For example, the StudentFacade session bean provides a simple interface to student functionality and fronts entity beans such as Order.

• For portability and ease of development, container-managed entity beans are used instead of bean-managed persistence entity beans. Also, all entity beans provide local interfaces for efficient access due to co-location.

• Uses distributed islands of local components. For example, as shown in Figure 21.5, one such island is composed of components such as StudentFacade, SignOn, Course, and Order. All the components within this island communicate with each other by using local interfaces. This offers the benefit of higher performance. An island communicates with a remote island by using remote interfaces, which offers the benefit of scalability.

  Figure 21.5. Distributed islands of local components.

  

Designing the Web Tier Components

The following section discusses the Web tier components in the sample application:

• The primary role of URSControllerServlet servlet is to act as a controller. This component is responsible for receiving parameters from the client and then invoking the calls to the EJB tier, which handles the business logic. Finally, the servlet receives the result and uses it to provide a response to the user. This servlet usually forwards the response to a JSP to perform a presentation task.

• The application contains the JSP pages, such as the registration page, login page, course catalog page, enrollment cart page, and order confirmation page. These components contain the presentation logic for student-related functionality. In addition, the admin page contains the presentation logic for administrator-related functionality.

Designing the EIS Tier Database Schema

Figure 21.6 shows the database tables and the relationships between them. Each table is shown as a solid rectangle with two compartments. The top compartment holds the table name and the bottom compartment holds a list of column names. The primary key column(s) uniquely identifies a row in the table. We use the abbreviation PK for the primary key. The foreign key column of a table identifies a row in a different table. We use the abbreviation FK for the foreign key.

For example, the enrollments table consists of the columns enrollment_id (primary key), student_id (foreign key to student_id in the students table), and course_id (foreign key to course_id in the courses table).

Designing the Scenarios

This section examines the interactions between components for key use case scenarios.

Student Logs On to the System

Figure 21.7 shows the sequence diagram for the use case Student Logs On to the System. The student enters a login name and password, and clicks the submit button in the login page. The browser sends an HTTP GET request to the Web server. The URSControllerServlet servlet receives the client request and invokes the validateUser() method of the StudentFacade enterprise bean. The façade delegates the method call of the SignOn authentication component, which uses the User entity bean to look up and validate the login name and password. Finally, the controller servlet forwards the request to the catalog page, which displays the course catalog.

Student Places Order

As shown in Figure 21.8, when the student clicks the Place Order button in the enrollment cart page, the URSControllerServlet receives the request and invokes the placeOrder() method of StudentFacade. The façade first creates a new order using the Order entity bean. The façade then creates multiple line items using the OrderLineItem entity bean and associates the line items with the order. Finally, the façade sends a JMS message to the Destination using the MessageSender component for order verification purposes.

Administrator Approves Order and Enrolls Student in Courses

Figure 21.9 shows the sequence diagram corresponding to the use case Administrator Approves Order and Enrolls Student in Courses. When the administrator approves an order placed by the student, he or she clicks the Approve Order button on the administrator page. The URSControllerServlet receives the corresponding request and invokes the method approvedOrder of AdminFacade. The façade retrieves the order by using its primary key, order_id, and changes the order status to Approved. The façade then enrolls the student in all the courses that are part of the order by using the enrollment component. Finally, the façade sends an e-mail to the student confirming the approval.