| CONTENTS | PREV | NEXT | INDEX | J2EE BluePrints |
It's always a good practice to design an application so that it can be extended. If you follow the Web application design path described in this chapter, this migration can be a gradual process. However, if you are working with a preexisting application that does not resemble any of the application types listed in Figure 4.3, migration will be more difficult.
When migrating an application it is best to first determine the type of application you want to implement. Figure 4.3 shows a generalized migration path that may be followed for migrating applications of different levels of complexity. The simpler an application is, the easier it will be to migrate. The sections corresponding to the columns in Figure 4.3 review what can be done to make the components of a Web application more modular.
When migrating applications that use basic JSP pages and servlets to a more complex design, the general theme should be to migrate components into reusable modules. As much as possible, the application and presentation logic should be separated using custom tags and JavaBeans components.
The most difficult migration will be from a modular, component-based application to an EJB-centric application with enterprise beans. The following sections review some strategies for this migration.
When migrating a Web-centric application to use enterprise beans apply the following steps:
4.7.1.1 Centralize Application Control Using an MVC Architecture
If your Web components do not already use an MVC architecture, you will need to modify the design. For more details on implementing an MVC architecture with Web components and enterprise beans, refer to Section 4.6.3.
4.7.1.2 Create Enterprise Beans
You will need to create enterprise beans corresponding to the JavaBeans components used within your application. For an EJB-centric application, you will also need to design a controller enterprise bean. The responsibilities of the controller enterprise bean are described in "Controller Components". You may also want to introduce other enterprise beans to handle other tasks, such as sending and receiving messages.
4.7.1.3 Move Application Logic to Enterprise Beans
All application logic provided by JavaBeans components in the Web application will need to be migrated to enterprise beans. This includes code to communicate with external resources.
Application logic for processing events generated by the Web components will need to be moved into the EJB controller. The EJB controller will also need logic for returning model update events to the Web controller.
4.7.1.4 Modify JavaBeans Components
JavaBeans components originally designed to hold the model data will need to be modified to obtain data from the enterprise beans when they receive model update events from the EJB controller. In addition, application logic in JavaBeans components will need to be moved to the enterprise beans representing the model.
After this modification, the JavaBeans components will become part of the view to represent the contract between JSP pages and the model. The only other logic that should remain in the Web container components is that tied to handling HTTP requests and managing the flow of the application.
4.7.1.5 Minimize Display Logic in JSP Pages
JSP pages should be used to render HTML instructions. To make the JSP pages more manageable, display logic code should be moved out of the JSP pages into custom tags and JavaBeans components whenever possible. For more details, refer back to Section 4.4 of this chapter.