J2EE Web Application Design

---

Servlets are just one component that can be used in building a web application. We can also use JSP pages, JSP tag libraries, JavaBeans, and even business components such as Enterprise JavaBeans (EJBs) if we need or wish to. Each of these components has its strengths and weaknesses, so each is suited to a different role. Identifying the roles needed within the application and finding the components most suitable for these roles is the first step in understanding the design of our applications.

Two of the most commonly used web application architectures are known as Model 1 and Model 2. In the next few sections we will discuss each of these, in order to understand where our different components will fit into them. Model 1 architecture is the simpler of the two, so let's consider this first.

Introducing Model 1 Architecture

A web application based on the Model 1 architecture is composed of a number of pages with which the user interacts. These pages generally utilize a model, which represents the business logic for the application. For example (and as shown in the diagram below), the pages could be implemented using JSP pages, with the model being one or more JavaBeans. In this situation, these beans would be used to represent information found in the application and might also contain a small amount of business logic:

In fact, the pages in Model 1 architecture are usually implemented using JSP pages (or sometimes servlets), so Model 1 architecture is known as page-centric.

The client directly accesses the pages served up by the web container through the web server, and these pages are used to service the entire request and send the response back. Any links to other parts of the web application are given as direct links to other pages.

Although each individual page could contain complex logic, this type of web application is very easy to assemble and is therefore very useful where there are a small number of pages, or where the structure of the application is very simple. However, problems with maintainability, extensibility, and security can arise if we attempt to use a page-centric architecture with larger or more complex web applications.

Maintainability Problems

If we consider a typical Model 1 web application, the structure of the application will be embodied within the pages. The pages will include diverse functionality, such as:

• Complex business logic

• Links to other parts of the web application

• The names of pages to which forms should be submitted

The fact that the pages often contain business logic often provides the biggest potential problem regarding the maintainability of a Model 1 architecture. It is usual to find blocks of Java code, known as scriptlets, in the page. This not only makes the code within the page more difficult to understand, but if we want to reuse the scriptlet code we would have to copy and paste it. If we wanted to incorporate the functionality into lots of pages this would be a time consuming (and error-prone) process.

Additionally, modifying the structure of our web application in any way would mean that we would need to search through the entire site to remove and/or change the names of the pages; again, a time-consuming and costly process.

Extensibility Problems

The extensibility of our web applications is also limited, as it is hard to modify or extend the functionality provided by the application since the pages contain such diverse functionality and are relatively tightly-coupled together. Changing some functionality could ripple horribly through the system causing more bugs and unexpected results.

Security Problems

Security is also a major problem for Model 1 architectures. For example, a web-based discussion forum might be divided into two distinct sections:

• Public area - for reading discussion threads and locating general information

• Restricted area - for creating threads and posting responses

If we used Model 1 architecture to implement the forum, each page in the restricted area would have to perform its own security checks to ensure that the user is logged in and that the user is permitted to see the contents of the page.

To circumvent this problem, we could place the authorization and authentication code into reusable components such as JavaBeans or custom JSP tags, or at the simplest level another JSP that is included in a page wherever necessary. However, we still need to include the authentication and authorization code in each secure page using some approach. This invites trouble: for example developers may accidentally forget to include this security code in pages they create for the site.

A simpler approach to security would be to provide a central access point for all users of the site; this central point would contain the authentication and authorization code, so we only need to include it once in our application. We will see how we can adopt this approach using Model 2 architecture in the next section.

Introducing Model 2 Architecture

The Model 2 architecture overcomes many of the problems of the Model 1 architecture. Model 2 is based upon the Model-View-Controller (MVC) architecture. In a Model 1 web application, the pages are accessed directly, in a Model 2 architecture all access is routed through a controller component (typically implemented by a servlet). This architecture is shown below:

We can use the same controller for the entire site, or multiple controllers that are each responsible for sections of the site. For both, the principle of the design is the same: requests from clients are routed to a central controller, which decides how the request should be serviced. Later on we'll see how a controller can delegate this task but for now we'll assume that the controller processes the request.

When it processes the request, the controller may make some modifications to the underlying model (often JavaBeans). Once the request has been serviced, the controller delegates the task of sending back the response to a view component (often implemented by JSP pages). The view component generally contains a minimal amount of code and is focused on the task of presenting information to the end user. Both the controller and the view components can access and modify model components.

Benefits of Model 2 Architecture

So how does using Model 2 architecture improve the design of our web application over using Model 1?

Enhancing Maintainability

As the controller component in our architecture is responsible for determining which page in our web application we should see next, the structure of the web application is defined in a single place. This increases the maintainability of the application, particularly if we go further, separating out the structural definition from the controller to make the structure externally configurable. Additionally, the processing and business logic associated with servicing requests is easy to find as it is not embedded and scattered throughout the pages of the system (unlike in the Model 1 architecture).

Promoting Extensibility

The logic that processes each type of request in Model 2 is now much more centralized. This centralization, in conjunction with splitting the view components from the logic that services the request, means that the system is now much easier to extend than in Model 1 architecture. By introducing more componentization we make extensions easier to write and the chances of a ripple effect throughout the application much less likely.

For example, to extend the application by adding new pages, all that we need to do is add new view components and make appropriate modifications to the controller component - either directly or through external configuration files.

Ensuring Security

When we discussed the security aspects of Model 1 earlier, we noted that routing all requests through a single point of entry is a simple way to handle web application security. In Model 2, we can use this technique, because all security processing can be moved to the controller(s), reducing the burden on developers and the risk of accidental security breaches.

Using Other J2EE Components in Model 2 Architecture

For many applications we use technologies other than JSP pages, servlets, and JavaBeans. We may want to introduce an EJB layer containing session and entity beans, where we place complex business processing or represent persistent business data:

While the basic architecture remains unchanged, introducing these additional components does however raise some questions:

• How should the functionality of our application be split between the components?

• What effect does introducing these components have on performance and scalability?

We will examine these issues more closely in the next two sections.

Using Entity Beans

Entity beans are used to represent data that is stored in some type of persistent data store such as a relational database. In smaller applications, we'd probably have the web components (our Servlets and JSPs) using JDBC to communicate with the database instead (possibly with JavaBeans representing the data).

Introducing entity beans means that they become the model on which our web application operates. For both Model 1 and Model 2 the components that handle the presentation of data on a web page (in other words the JSPs and servlets in the web container) will access and modify business data residing in the EJB tier.

From an architectural and design perspective, this separation of the components in our web application is certainly beneficial. Splitting these out makes for a more maintainable system since functionality has been logically partitioned across the application. When the entities in the business layer change, we instantly know which part of the application needs to change to reflect this. In addition, we might also end up with some components that we can reuse in future projects.

There are disadvantages to using entity beans though. From an implementation perspective, entity beans are remote components that are able to execute on a separate machine from the code that calls them. Introducing remote components means introducing additional network overhead in terms of the remote method calls that are required to access and modify the data residing within the EJBs. As always, you should weighed up the advantages and disadvantages in the context of the application(s) that will make use of entity beans before you decide to use them.

Using Session Beans

Traditionally, business logic has been embedded into client applications, whether they are desktop-based or web-based. Session beans can instead encapsulate this logic in a robust and reusable manner. However, session beans, like entity beans, are intended to be remote components and so the same network overheads may be incurred when using the functionality contained within session beans.

With these issues in mind, let's look at roles and responsibilities in a Model 2 architecture.

Component Roles in Model 2 Architecture

Let's consider the role of the controller in the Model 2 architecture example. It should:

• Act as a single point of entry for requests

• Process the requests, accessing and modifying the underlying model

• Delegate the task of presenting information to a specific view component

The controller can process requests in a number of ways. It can process requests itself which means that the controller encapsulates business logic. However, this is probably not an effective solution, as the controller would rapidly become bloated.

A more efficient system might be to delegate processing tasks to other components such as JavaBeans or session EJBs, or even standard Java classes. If this strategy is selected, how do we determine where specific functionality is to be situated, including that associated with servicing the request, validating any data and of course, security? When we design our application, we need to answer these questions, deciding on the roles and responsibilities of components. This is often a tricky task, but fortunately many of the common problems encountered during the design process have been tackled before, and the solutions to these problems are well-documented in the form of design patterns.

---