EJB-Centric Applications

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 compo- nents is maintained by enterprise beans. This design provides flexibility, manage- ability, 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.

Figure 4.9 Model-View-Controller Architecture

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 modifica- tions 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 spe- cific 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 on page 99).

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. Miscella- neous 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 dis- played 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

APPLICATION DESIGNS 105

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 stati- cally-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 control- ler components span both the Web tier and the EJB tier. The design of the compo- nents to create a controller that spans both the Web and EJB tiers is described in the following section.

Controller Components

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 com- ponents 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

APPLICATION MIGRATION 107

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 compo- nent allows the application developer to centralize all HTTP-specific process- ing 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 appli- cation allowed to manipulate the model data. Any less restrictive means of data modification would be contrary to the MVC architecture and make it dif- ficult to debug the application.

For more details about controller design, see the discussion of the sample application’s controller in Section 10.6 on page 280.