Day 21. Developing a Complete Enterprise Application

Thẻ

Day 21

Today, you’ll develop a complete enterprise application. You’ll apply different concepts you learned in the previous days to build an application that consists of Web components (JSPs and servlets), EJB components (session, entity, and message-driven enterprise beans), and the EIS tier (database tables).

The sample university registration system is an end-to-end application that handles the online course registration and enrollment process in a transactional e-commerce environment.

Today you’ll see how to perform analysis, design, implementation, and deployment of the sample application. You’ll undertake each of the following:

• Understand the application requirements

• Perform use case analysis

• Decide on a system architecture that meets the application requirements

• Identify the components in the multitier architecture and the interactions among these components

• Implement the components, and package and deploy the application

Understanding the Application

The university registration system is a typical e-commerce application. The application has a Web site that enables students to browse the course catalog and register for courses online. Figure 21.1 shows an overview of the system.

Figure 21.1. University registration system.

The application provides the following functionality:

• Student registration— This functionality enables new students to create and maintain their account information. The account information includes the student’s first name, last name, address, e-mail, login name, and password.

• Student authentication— This module handles the student login process, such as verifying the login name and password. This ensures that only registered students browse the course catalog and purchase courses for enrollment.

• Course catalog browsing— The Web site displays the current course offerings in the university and their details. The course details include the course title and fee.

• Enrollment cart— The enrollment cart module enables students to place their course selection in a shopping cart while browsing the course catalog, and later to view the cart contents before placing an order.

• Order processing— The order module enables students to place their orders, and performs the necessary verification before approving them.

• Administrator interface— This functionality allows the administrator to view and approve orders for enrollment.

• Notification— This functionality causes the system to send e-mail to students when they have enrolled for a course.

Analyzing the Application

Use case analysis is the standard technique for analyzing the requirements of an application. A use case diagram shows the interaction between the system and actors. An actor is a role that human and/or nonhuman users of the system play when interacting with use cases. Figure 21.2 shows a high-level use case diagram of the university registration system.

Figure 21.2. Use case diagram.

The use case diagram in this case consists of actors, such as student, administrator, and order verification system. The following describes the use cases:

• New students register with the system.

• Existing students log on to the system and can browse the course catalog.

• A student can select courses and add them to the enrollment cart.

• A student places an order for the enrollment cart contents.

• The system verifies the order in the background.

• An administrator can view the verified orders that need approval for enrollment.

• An administrator approves the order and enrolls the student in the courses.

• The system notifies the student of enrollment via e-mail.

Architecting the System Architecting consists of deciding what tiers are needed for the application, what services are required at each tier, and how the application logic will be spread across different tiers. As you learned on Day 15, “Understanding J2EE Architecture,” the J2EE architecture is designed for multitier applications. In a multitier architecture, the business logic can be split into more than one layer. In the sample application, logic is partitioned into the business logic tier and the presentation logic tier. The user interface is partitioned into the client tier and the presentation tier. The application-persistent data is stored in the EIS tier. Figure 21.3 shows the architecture of the system. Figure 21.3. Architecture diagram. The sample architecture consists of the following tiers: Client tier— Students and administrators use the client tier to interact with the system. The client tier is provided by a Web browser, such as Internet Explorer or Netscape Navigator. The client tier communicates with the Web tier by using the HTTP protocol. Web tier— This tier accepts user requests and generates responses using the presentation logic. The sample application uses both servlets and JSPs in a Web container. The Web tier communicates with the business logic tier using RMI/IIOP protocol. Business logic tier— This tier handles the core business logic of the application. The business components are implemented as EJB components with support from an EJB container. EIS tier— The EIS tier consists of the database in which the sample application’s permanent data is stored. The business-logic tier communicates with the EIS tier using JDBC. Note J2EE offers flexibility in partitioning the application logic across tiers. For example, you have a choice between Web-centric and EJB-centric design. In the Web-centric design, the Web tier components are responsible for most of the application’s functionality. The Web tier components communicate directly with the EIS tier using container services such as the JDBC API. In the EJB-centric design, the enterprise beans encapsulate the core application logic. Web tier components communicate with EJB tier components instead of accessing the EIS tier directly. The decision between the Web-centric and EJB-centric approaches depends on factors such as application functionality and scalability requirements. The Web-centric approach offers a quick start for small applications, but can rapidly become complex and difficult to maintain for large applications. The EJB-centric approach offers advantages such as automatic handling of transactions, distributed processing, security, and so on, and can stay manageable as applications grow more complex. The sample application uses the EJB-centric approach. 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. Figure 21.4. Application design. 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. Note The sample application uses the MVC (Model-View-Controller) design pattern discussed on Day 7, “Designing Web Applications.” The model layer contains the enterprise bean components that handle the core business logic. The view layer contains the JSP pages, whose job is to format and present responses to the client. The controller layer provides the URSControllerServlet servlet, which is responsible for receiving the client request, managing screen flow, and selecting an appropriate response. 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. Figure 21.6. Database schema of the sample application. 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. Figure 21.7. Student Logs On to the System sequence diagram. 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. Figure 21.8. Student Places Order sequence diagram. 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. Figure 21.9. Administrator Approves Order and Enrolls Student sequence diagram. Packaging and Deploying the Application This section describes the steps to package and deploy the application for both WebLogic Server and JBoss application servers. These steps assume that you configured OrderVerifierTopic as discussed on Day 14, “Developing Message-Driven Beans,” and ursMailSession as discussed on Day 20, “Implementing JavaMail in EJB Applications.” You can run the following commands for WebLogic: C:\>cd styejb\examples C:\styejb\examples>setEnvWebLogic.bat C:\styejb\examples>cd day21 C:\styejb\examples\day21>buildWebLogic.bat You can run the following commands for JBoss: C:\>cd styejb\examples C:\styejb\examples>setEnvJboss.bat C:\styejb\examples>cd day21 C:\styejb\examples\day21>buildJBoss.bat

Running the Sample Application

The following steps describe how to start the PointBase database server and WebLogic Server, and run the sample application:

1. Start PointBase server in a new command window as follows:

   C:\>cd styejb\examples
   C:\styejb\examples>setEnvWebLogic.bat
   C:\styejb\examples>startPointBase.bat

2. Start WebLogic Server in a new command window as follows:

   C:\>cd styejb\examples
   C:\styejb\examples>setEnvWebLogic.bat
   C:\styejb\examples>startWebLogic.bat

3. Open the university registration system URL, http://localhost:7001/urs, using a Web browser. This will display the main page as shown in Figure 21.10.

   Figure 21.10. Sample application main page.

   

4. Register a new student by clicking the New students register here link. Enter tom for the login name and tom for the password. Enter a first name, last name, address, and email for the student. Figure 21.11 shows the corresponding screenshot. Click the Register button.

   Figure 21.11. Sample application registration page.

   

5. Figure 21.12 shows the course catalog page. Add a couple of courses to the enrollment cart by clicking the Add to cart link that corresponds to each course. Click the View your enrollment cart link to view the enrollment cart.

   Figure 21.12. Sample application course catalog page.

   

6. Figure 21.13 shows the enrollment cart page. Click the Place Order link to purchase the cart contents.

   Figure 21.13. Sample application enrollment cart page.

   

7. Now we’ll explore the administrator functionality. Open the URL http://localhost:7001/urs. Click the Administrator click here link. Figure 21.14 shows the administrator page displaying the verified order(s). Click the Approve link to approve the order and enroll the student in the courses.

   Figure 21.14. Sample application administrator page.

   

The following steps describe how to start the JBoss server and run the sample application:

1. Start the JBoss server in a new command window as follows:

   C:\>cd styejb\examples
   C:\styejb\examples>setEnvJBoss.bat
   C:\styejb\examples>startJBoss.bat

2. Open the university registration system URL, http://localhost:8080/urs, using a Web browser. This will display the main page as shown in Figure 21.10. The remaining steps are similar to those listed for WebLogic Server’s steps 4 through 7.

Best Practices

Local architecture is implemented with local enterprise beans. Distributed architecture is implemented with remote enterprise beans. Local architecture offers the benefit of higher performance for the same hardware, but it’s harder to scale and cluster. On the other hand, distributed architecture is easier to scale and cluster, but results in reduced performance for the same hardware. One possible solution is to create distributed islands of local components as in the sample application.

Summary

Today, you worked on a complete sample application. We explored the requirements of the sample university application and analyzed them using a use case approach. We decided to use the multitier architecture that J2EE offers. We also decided to use an EJB-centric design in which the enterprise beans encapsulate the core application logic. We identified those components and their interactions. Finally, we packaged, deployed, and ran the sample application.