This chapter discusses the relationship between the architectural tiers and their roles in an application. Special attention is given to the web tier, which allows an application to communicate and interoperate with clients over the Web. In particular, this chapter focuses on the physical and logical aspects of designing and using a web tier for your applications.
The Struts framework is based on the Java Servlet technology and, to a lesser extent, JavaServer Pages, and therefore is dependent on a web container. For Struts developers, understanding how the web container processes client requests is fundamental to a deeper understanding of the framework itself. This chapter illustrates the various components that are part of the web container and discusses each component’s responsibilities.
This section presents a high-level architectural view of a Struts application. Although this section shows an architecture for an enterprise application, not all applications written using Struts will be of this size and makeup. However, this type of application does allow us to present many facets of how Struts applications may be configured.
Many applications—especially J2EE applications—can be
described in terms of their tiers. The
application’s functionality is separated across
these tiers, or
functional layers, to provide separation of
responsibility, reusability, improved scalability, and many other
benefits. The separation of tiers may be a physical separation where
each is located on a separate hardware resource, or it may be purely
logical. In the latter case, one or more tiers are collocated (i.e.,
arranged or grouped together) on the same hardware resource, and the
separation exists in terms of software. Figure 2-1
illustrates the tiers that may be used by a typical Struts
application.
Not every Struts application will contain all of the tiers illustrated in Figure 2-1. For many smaller applications, the middle tier may consist primarily of a web container that interacts directly with a database in the enterprise information system (EIS) tier.
The client tier provides a way for users to interact with the application. This interaction may be through a web browser, or it may be programmatic, through a web services interface. Regardless of the type of client, the interaction includes submitting a request and receiving some type of response from the middle tier.
In the case of the Struts framework, the most common type of client is a web browser. However, it is also possible to have clients such as wireless devices and Java applets.
Figure 2-1 shows the middle tier as an aggregate of the web tier plus some type of application server component (in this case, an EJB container). These two tiers often are combined, and many application servers include web tier functionality.
The web tier allows the client tier to communicate and interact with application logic that resides in other tiers. In more traditional web applications, it’s not uncommon for some or all of the application logic to reside in this tier. In larger, enterprise-scale applications, the web tier acts as a translator and maps HTTP requests into service invocations on the middle tier.
The web tier also is responsible for managing screen flow based on application and user state. The web tier communicates with either a database or, in the case of an enterprise application, an application server. The web tier is the glue that binds client applications to the core backend business systems.
The components that reside in the web tier allow developers to extend the basic functionality of a web service. In the case of Struts, it does this through framework components that run in a servlet container.
The middle tier is often referred to as the " application tier” or “server.” This is due in part to the fact that there is often an application server within this tier. Not all Struts applications have an application tier. This is especially true for small web applications—many small projects forgo using a large application server and communicate directly with a database or some other data store. When an application server is present, the web tier communicates with it using some variation of Remote Method Invocation (RMI). If an EJB server is present in the application tier, the communication protocol is RMI over IIOP (Internet Inter-ORB Protocol).
When included, the application tier might provide a more scalable, fault-tolerant, and highly available architecture. One of the main purposes of using an application tier is to separate the responsibilities of presentation from those of the model and the business rules for the application. Today, many web applications use EJB servers for their application tiers. They may not use all available aspects of the J2EE architecture, such as EJBs, but there are other benefits that can be leveraged from a J2EE server.
The EIS tier contains data and services that are used throughout the enterprise. It provides access to enterprise resources such as databases, mainframes, customer relationship management (CRM) applications, and resource-planning systems.
The middle tier communicates with components in the EIS tier using resource-specific protocols. For example, to communicate with a relational database, the middle tier normally will use a JDBC driver. For enterprise resource planning (ERP) systems, a proprietary adapter is used, although some ERP systems and other enterprise resources are starting to support a more web service-like access approach.
As illustrated in Figure 2-2, the Struts framework resides in the web tier. Struts applications are hosted by a web container and can make use of services provided by the container, such as handling requests via the HTTP and HTTPS protocols. This frees developers to focus on building applications that solve business problems.
