Enterprise Application Architectures

Enterprise Web applications have evolved a distinctive architecture over the years. These architectures have grown from simple Web Server CGI script architectures to full-scale, multi-tier architectures.

The initial architectures had one major problem the mixing of user interface logic and business logic. This resulted in Web applications that were difficult to maintain and not flexible enough to sustain enhancements. Separation of the user interface logic and business logic was the first step in standardizing Web application architectures.

Java technologies have been in step with the evolution of Web application architectures. The introduction of Java servlets made the development of Web applications easier. Developers could easily build Web applications that used Java servlets to generate the HTML code required for the user interface. The downside of this approach was a difficult-to-maintain application because the Java servlet was responsible for handling the business logic of the application as well as generating the user-interface code. Moreover, developing Java servlets was not an easy task.

Recognizing that there was a mixing of business logic and user interface logic in the Java servlet, the JSP specification came into existence. JSPs greatly simplify building Java servlets because the responsibility for generating the Java servlet code lies with the JSP engine. However, JSPs are not used for writing Java servlets. The main area of use for JSPs is in developing and embedding user-interface logic for Web applications.

The use of JSPs has spawned, to a major extent, standardized Web-application architectures. The two main architectures that have now come to be used are discussed in the following sections.

Model I Architecture

The Model I architecture consists of a division of the application into presentation layer and business-logic layer. The presentation-layer component delegates the processing of business logic to an embedded model-layer component.

The Model I architecture has its share of advantages and disadvantages. The clearest advantage is the separation of the Web application into the presentation and model layers. This ensures that the presentation layer is not tainted with any business logic specific functionality and is solely responsible for rendering the user interface. The model layer is entirely responsible for handling the business logic of the application and does not need to have any user interface logic embedded in it, nor does it need to know how to generate the user interface.

Now you will take a closer look at this architecture in the context of Java technology. A Web application based on the Model I architecture can be built using JSPs and a set of Java classes. From Figure 2.3, you can see that the JSPs form the presentation layer and that Java classes or JavaBeans embedded in the JSPs form the model layer. Any request from the browser is delegated by the JSP to the JavaBean. The JavaBean applies the business logic to process the user request and generates the response. Any information sources that are required will be accessed by the JavaBean. The JavaBean's response is returned to the JSP, which formats the response data into the required user interface. Thus, there is potentially a one-to-one correspondence between the JavaBean and the JSP with no flow control (to decide the sequence of screens) existing in the application. The current JSP decides which screen the user should be presented with next, and so on.

Figure 2.3. Model I architecture.

The main drawback of this architecture is that there is no explicit flow control in the application. This results in an application with little scope for reusability of functionality. More importantly, it is difficult to trace the overall flow of the application, especially when maintaining or enhancing the Web application functionality.

Model II Architecture, or the Model View Controller Architecture

The Model II architecture, also known as the Model View Controller (MVC) architecture, is essentially an improvement on the Model I architecture. The main drawback of the Model I architecture, as you learned in the previous section, is the lack of explicit flow control. This is addressed in the MVC architecture. The MVC architecture consists of the following three layers:

• Model The model layer is where the business logic of the application resides. Interactions with information sources, such as databases or enterprise information systems, is taken care of by the model layer. Essentially, the model layer represents the information stored in the database or enterprise information system. Any business logic or rules required to massage and process this data based on client application requests is carried out by the model layer.

• View The view layer of the MVC architecture is the presentation layer. Components of an application that are responsible for rendering the user interface for the application reside in the view layer. Unlike in the Model I architecture, the view layer does not directly interact with the model layer in the MVC architecture. The interaction is routed through the controller. This keeps the separation between the view and model layers. Moreover, the view layer is not required to determine the flow of the application. This is handled by the controller layer. The view layer delegates the user requests to the controller. The response generated from the controller layer is then formatted and rendered appropriately by the view layer.

• Controller The controller layer is the significant addition to the MVC architecture. The controller is, in essence, the missing piece of the Model I architecture. The controller provides the flow control and routing of the workflow in the application. Which screen is to be presented in which sequence is determined by the controller. Moreover, the controller layer acts as a separation layer between the view layer and the model layer. The user request is obtained by the controller layer and forwarded to the model layer for processing. The response generated by the model layer is then picked up by the controller and returned to the view layer.

Figure 2.4 illustrates the Model II, or MVC, architecture.

Figure 2.4. Model II architecture, also known as Model View Controller architecture.

This architecture can be used for building Web applications using Java components and technologies. The view part of the architecture is responsible for the presentation layer; hence, you can use JSPs in the view. The view layer interacts with the controller layer. In an MVC architecture, the Java servlets form the controller part of the architecture. The Java servlets interact with the JSPs to obtain user requests and send responses based on the processing carried out in the model layer. The model layer contains not only the business logic but also the data logic. Hence, the model layer is made up of Java classes, JavaBeans, or EJBs.

To access information resources, such as databases and enterprise information systems, the model layer may use JDBC drivers or the resource adapters of JCA. The response generated by the Java classes or JavaBeans in the model layer is forwarded to the controller. Typically, there is one Java servlet in the application that acts as the flow control for the application and routes the user requests and responses in the application. The controller Java servlet in turn packages the response and passes it to the JSPs that make up the view layer of the MVC application. The JSPs then format and render the response data and display it to the user in the user interface, which is typically an HTML front end.