| CONTENTS | PREV | NEXT | INDEX | J2EE BluePrints |
There are many ways to design a Web application. The complexity of an application depends on various needs and requirements such as limitations on application development, capabilities of the development team, longevity of an application, and dynamism of the content in an application. Even if the original application is not intended for widespread use, it is always benefical to design an application in such a way that it can be migrated to a scalable, multitier design as a project's scope changes.
Four general types of Web applications can be implemented with the J2EE platform: basic HTML, HTML with basic JSP pages, JSP pages with JavaBeans components, and highly-structured applications that use modular components and enterprise beans. The first three types of applications are considered to be Web-centric, whereas the last type is EJB-centric. The spectrum of application designs is presented in Figure 4.3.
Web applications with basic JSP pages and servlets are similar in complexity to conventional HTML and CGI-based applications widely deployed on the Web, except that the dynamic portions of the pages and user interaction are handled by JSP or servlets in place of CGI scripts.
HTML applications with basic JSP pages are entry-level Web applications with much of their logic in servlets or JSP pages. These applications can be developed quickly, but are more difficult to extend and maintain.
In these simple applications, some pages display static HTML content. Where necessary to display dynamic content, (for example, content generated using data from a database), a JSP page or servlet should contain code to connect to the database and retrieve the data.
In these simplest applications, the layout will not change frequently. The content used for the page layout of the application will be tied to the application. This means that changes to dynamic pages can only be made by an engineer or page designer familiar with the Java programming language.
Including much of the logic in JSP pages or servlets is good for prototyping an application or for controlled environments, such as intranet sites, where the application is not expected to be used by a large number of users.
As the complexity of the application increases, a model that allows for more modularization of components would be useful. The next section describes how to handle more complex user interaction or dynamic data processing.
When developing Web applications with dynamic content and a large degree of user interaction, you should use JSP pages with JavaBeans components, custom tags, and included JSP pages. These three types of components can be used to generate content, process requests, and handle the display of personalized content.
Figure 4.5 shows a path that a user might take through a hypothetical, interactive Web application and shows how reusable components can be used at each step in the process.
Figure 4.5 Process Flow of JSP Pages with Modular Components
Although this example appears simple, a number of components are needed to take the user through the process. Creating more modular components will allow for more code reuse and make the application more maintainable.
Let's look at each of the steps in more detail.
4.6.2.1 Modular Components in a JSP Page
JSP pages can be created using a variety of components. Used consistently, these components provide a common look and feel throughout an application. This technique is similar to templates, yet each page can be unique if needed. Figure 4.6 shows how to design a JSP page that contains products obtained from a catalog implemented as a JavaBeans component.
In this example the file banner.jsp contains a reusable component. Putting the logic to display the banner for the site in one JSP page means that the banner code does not need to appear on each page. Instead, the JSP page containing the banner code is added to each page using a runtime include.
In the center of the page, the body is generated using data from the Catalog component (and possibly some custom tags for HTML rendering of the data). A Catalog connects with an external data source using a connection obtained from the JDBC connection pool JavaBeans component. A Catalog is also responsible for updating the data or holding data that has been previously entered in the application.
4.6.2.2 Processing Requests with Modular Components
Processing user requests is another important aspect of Web application behavior that can be effectively implemented using modular components. Applications that use modular components for request processing will be easier to develop and maintain. Figure 4.7 depicts how data from a form can be processed in a Web application.
In this example, a user submits data from a browser. The data is posted to the process request bean, which extracts the user data and converts it into account data maintained by a the account bean JavaBeans component. The account data is stored in a database using a JDBC connection obtained from the JDBC connection pool bean, also a JavaBeans component. If the data was entered correctly, the process request bean forwards the user to the appropriate page confirming the creation of the account.
To avoid confusion, JavaBeans components that interact with users and external data (in this example, the bean that processes requests) should be separate from the components that represent that data (the account JavaBeans component). This separation of content and data enables the components to be reused and the application as a whole to be migrated to a more complex design as its scope changes.
4.6.2.3 Displaying Personalized Content
A JSP page that displays the personalized content is similar to the example shown in Figure 4.6 except that the displayed data is obtained from the account bean.
The data used to generate the content of this page includes data entered by the user. The page can also include other information personalized to the user's needs. After setting up an account, the users can be taken directly to a personalized page each time they log into the application. Data reflecting a user's previous visits can be saved as part of the user account and used to drive the content of the application seen by that user.
This type of application can be used in many types of situations. However, as an application using this design becomes larger, the level of complexity increases. More of the developer's time may be for work on the system-level issues such as managing the connection pool and application state and transaction management. Migrating to an EJB-centric design will allow the developer to stay focused on the application design.
A well-designed application using JSP pages with JavaBeans components and custom tags will have a clean separation of business from display logic. The content will be easier to modify and the components, if designed well, will be reusable. The major weakness of this design is the need for developers to provide connections to legacy applications and transaction support. As an application becomes more complex and the need for more transactional support and external resource integration becomes an issue, a more structured approach is required.
An EJB-centric application extends the modular, component-based application described in the previous section, with two main differences. First, this design uses a front component for a controller. Second, data represented by the JavaBeans components is maintained by enterprise beans. This design provides flexibility, manageability, and separation of developer responsibilities.
Flexibility is provided by using a MVC architecture in conjunction with a front component. The MVC architecture allows for a clean separation of business logic, data, and presentation logic. This design also enables content providers and application developers to focus on what they do best. The sample application uses an MVC architecture to separate business from presentation logic.
Figure 4.9 shows how an MVC architecture can be implemented using JSP pages, servlets, and JavaBeans components.
As illustrated in the figure, the logic driving the application is separate from the presentation logic and from data presented to the user. This design is similar to the design in the previous section, except that a central controller receives all requests and updates the JavaBeans components that contain view data.
Now let us explore each part of the MVC architecture and consider how a Web application can benefit from it.
4.6.3.1 Model
The model represents the data on which an application is based. In an EJB-centric application, enterprise beans hold the data needed by the application. All modifications to the data occur thorough events sent to the EJB controller.
4.6.3.2 View
A view presents the data represented by the model in a way that's targeted at a specific type of client. Most enterprise applications will support a number of different views. The same model could have a Visual Basic client view, a Swing view, or a Web view. The view for a Web application consists of JSP files, which have sole responsibility for displaying the model data. The JSP files can contain JavaBeans components, custom tags, or included JSP page components (as described in Section 4.6.2.1).
JSP pages should only contain code related to the display of model data. Repetitive HTML rendering, such as banners and navigation bars, should be handled by custom tags or JavaBeans components whenever possible. Miscellaneous tasks such as locale-specific currency formatting should be handled by custom tags or by helper classes.
The view can employ a templating mechanism, as described in "Presentation Component Templates" on page 82, to provide a consistent look and feel for an application.
In the sample application, the model data maintained by enterprise beans is mirrored by JavaBeans components that reside in the Web tier. The components in the Web tier allow the data maintained by the enterprise beans to be easily displayed by a JSP page. The JavaBeans view objects are responsible for updating themselves with the data maintained by the enterprise beans that they mirror. These JavaBeans components register with the Web controller to listen for model update events received from the EJB controller. When an update event is received, JavaBeans components contact the enterprise beans they mirror and refresh the data they contain. These JavaBeans components contain read-only data, since data modification is the responsibility of the controller.
4.6.3.3 Controller
To ensure that a Web application runs smoothly with the Model-View-Controller architecture, a central point of control is necessary. This is provided by using a front component and some helper classes. This controller maintains the data in the model and ensures that the data presented by the view is consistent with the corresponding model.
The controller provides a level of control that isn't possible by using statically-linked Web pages. With static pages, there is no guarantee that all users of a Web site will use the preferred point of entry. Without a single entry point, it is difficult to ensure that a Web application will be properly initialized to handle a user's request. A controller can also provide a way to prevent deep linking to information within a site.
In designing a controller-centric application, a Web application developer can use a front component to receive all requests. A front component works with some JavaBeans components and enterprise beans that act as the controller. The controller components span both the Web tier and the EJB tier. The design of the components to create a controller that spans both the Web and EJB tiers is described in the following section.
The controller is made up of many components responsible for taking data posted in an HTTP request and converting it into an event to update the model data. The components that make up the controller include: front component, request processor, Web controller, and EJB controller.
Figure 4.10 is a diagram of a controller that converts an HTTP request into an event that updates the application model data. This figure shows the flow of an HTTP request from an HTTP client to the controller mechanism. As mentioned before, all requests from HTTP clients go to a front component. The requests are then sent to the request processor, which converts them to events and then sends the events to the Web controller. The Web controller acts as a proxy and sends the event to the EJB controller, which processes the event and updates the model data maintained by the enterprise beans accordingly.
All business logic is handled by the EJB controller and enterprise beans. The EJB controller returns a set of changed models to the Web controller. The Web controller then sends the model update events to the respective views. The views then contact the enterprise beans that they mirror and update their data from the enterprise beans. The JavaBeans components do not change any data; they only read the model data contained by the enterprise beans when they receive the model update notification.
Figure 4.10 Controller Conversion of HTTP Request to Model Change Event
Now that we have described the process of how model data is updated by the controller mechanism we review each component of the controller.
Front component
The front component is a component to which all requests for application URLs are delivered. The front component ensures that the Web components needed by the application are initialized at the correct time and that all HTTP requests are sent to the request processor.
Request processor
The request processor is the link between the Web application and an HTTP-based client. The request processor is responsible for converting HTTP requests to events which will be used throughout the application. This component allows the application developer to centralize all HTTP-specific processing in one location. This component also allows the EJB portion of the application to be independent of any single client type.
Web controller
The Web controller is responsible for forwarding the event(s) generated by the request processor component to the EJB controller. The Web controller ensures that the resulting updated models returned from the EJB controller are propagated to the appropriate Web-tier view JavaBeans components.
EJB controller
The EJB controller accepts events from the Web controller and makes the calls on the enterprise beans affected by the event. The EJB controller is also responsible for maintaining the state of the user session with the application. After each event is processed, the EJB controller is responsible for returning a set of updated models to the Web controller.
In general it is best to design the EJB controller so that it is not tied to a single type of client. This makes the application usable by both application and Web-centric clients. The EJB controller is the only part of the Web application allowed to manipulate the model data. Any less restrictive means of data modification would be contrary to the MVC architecture and make it difficult to debug the application.
For more details about controller design, see the discussion of the sample application's controller in Section 10.6.