Chapter 17. Web Application Models 301 The middle tier provides client services through the web container and the EJB container. A client that communicates with the server through HTTP uses components in the web container, such as servlets and JSP pages, as entry points to the application. Many applications can be implemented solely as web container components. In other applications, the web components just act as an interface to the application logic implemented by EJB components. A standalone application, written in Java or any other programming language, can also communicate directly with the EJB components. General guidelines for when to use the different approaches are discussed later in this chapter. Components in this tier can access databases and communicate with other server applications using all the other J2EE APIs. The Enterprise Information System (EIS) tier holds the application's business data. Typically, it consists of one or more relational database management servers, but other types of databases such as IMS databases; legacy applications such as Enterprise Resource Planning (ERP); and mainframe transaction processing systems such as CICS, are also included in this tier. The middle tier uses J2EE APIs such as JDBC, JTA/JTS, and the J2EE Connector Architecture (JCX) to interact with the EIS tier. 17.2 The MVC Design Model In addition to the separation of responsibilities into different tiers, J2EE also encourages the use of the Model-View-Controller (MVC) design model, briefly introduced in Chapter 3, when designing applications. The MVC model was first described by Xerox in a number of papers published in the late 1980s in conjunction with the Smalltalk language. This model has since been used for GUI applications developed in all popular programming languages. Let's review: the basic idea is to separate the application data and business logic, the presentation of the data, and the interaction with the data into distinct entities labeled the Model, the View, and the Controller, respectively. The Model represents pure business data and the rules for how to use this data; it knows nothing about how the data is displayed or the user interface for modifying the data. The View, on the other hand, knows all about the user interface details. It also knows about the public Model interface for reading its data, so that it can render it correctly, and it knows about the Controller interface, so it can ask the Controller to modify the Model. Using an employee registry application as an example, an Employee class may represent a Model. It holds information about an employee: name, employment date, vacation days, salary, etc. It also hold rules for how this information can be changed; for instance, the number of vacation days may be limited based on the employment time. The user interface that shows the information is a View. It gets hold of an Employee object by asking the Controller for it, and then renders the information by asking the Employee object for its property values. The View also renders controls that allow the user to modify the information. The Views sends the modification request to the Controller, which updates the Employee object and then tells the View that the Model has been modified. The View, finally, updates the user interface to display the updated values. Using the MVC design model makes for a flexible application architecture, in which multiple presentations (Views) can be provided and easily modified, and changes in the business rules Chapter 17. Web Application Models 302 or physical representation of the data (the Model) can be made without touching any of the user interface code. Even though the model was originally developed for standalone GUI applications, it translates fairly well into the multitier application domain of J2EE. The user interacts with the Controller to ask for things to be done, and the Controller relays these requests to the Model in a client-type independent way. Say, for instance, that you have two types of clients: an HTTP client such as a browser, and a GUI client application using IIOP to talk to the server. In this scenario you can have one Controller for each protocol that receives the requests and extracts the request information in a protocol-dependent manner. Both Controllers then call the Model the same way; the Model doesn't need to know what kind of client it was called by. The result of the request is then presented to the two types of clients using different Views. The HTTP client typically gets an HTTP response message, possibly created by a JSP page, while the GUI application may include a View component that communicates directly with the Model to get its new state and render it on the screen. The J2EE platform includes many APIs and component types, as I have just shown. However, there's no reason to use them all for a specific application. You can pick and choose the technology that makes most sense for your application scope and functionality, the longevity of the application, the skills in your development team, and so on. The assignment of MVC roles to the different types of J2EE components depends on the scenario, the types of clients supported, and whether or not EJB is used. The following sections describe possible role assignments for the three most common scenarios in which JSP pages play an important role. 17.2.1 Using Only JSP As you saw in Part II, there are all sorts of applications that can be developed using just JSP pages with JSTL, a few JavaBeans components and custom actions. If you're primarily a page author working alone, with limited or no Java knowledge, you can still develop fairly sophisticated applications using JSTL and the custom actions in this book. And if that's not enough, many generic tag libraries are available from both commercial companies and open source projects, making it possible to do even more with just the JSP part of the J2EE platform. A pure JSP approach can be a good approach even for a team if most of the team members are skilled in page design and layout, and only a few are Java programmers. The programmers can then develop application-specific beans and custom actions to complement the generic components and minimize the amount of SQL and Java code in the JSP pages. A pure JSP approach is also a suitable model for testing new ideas and prototyping. Using generic components and a few application-specific beans and actions is often the fastest way to reach a visible result. Once the ideas have been proven, and the team has a better understanding of the problems, a decision can be made about the ultimate application architecture for the real thing. The danger here is that the last step evaluating the prototype and deciding how it should be redesigned never happens; I have seen prototypes being relabeled as production systems overnight too many times and also experienced the inevitable maintenance nightmares that follow. . which JSP pages play an important role. 17.2.1 Using Only JSP As you saw in Part II, there are all sorts of applications that can be developed using just JSP pages with JSTL, a few JavaBeans. the EJB container. A client that communicates with the server through HTTP uses components in the web container, such as servlets and JSP pages, as entry points to the application. Many applications. a few are Java programmers. The programmers can then develop application-specific beans and custom actions to complement the generic components and minimize the amount of SQL and Java code