2.1 An Architecture Overview

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.

Figure 2-1. Functional application tiers

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.

What Is a Container?

There are many different types of containers—EJB containers, web containers, servlet containers, and so on. In general, containers provide a hosting environment for software components to run in. Containers provide general services that the components within the environment can use, so that the component developers don't have to worry about providing these services. A web container allows servlets, JSP components, and other Java classes to be deployed and executed within the container. Services such as the Java Naming and Directory Interface (JNDI), connection pooling, and transaction services can be configured at the container level—similar to the way in which EJB containers manage security, transactions, and bean pooling—and the component developers don't have to worry about managing these resources.

When using the services provided by a container, component developers may have to give up some control of the environment to the container. Third-party vendors, who must follow certain guidelines that are explicitly laid out in public specifications, build these containers. Although each vendor is allowed to implement certain portions of the container in a proprietary manner, they must follow the specifications to ensure that applications are portable.

2.1.1 The Client 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.

2.1.2 The Web Tier

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.

2.1.3 The Middle Tier

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).

RMI over IIOP

Remote Method Invocation (RMI) allows methods to be invoked on remote objects. Java's implementation of RMI, known as the Java Remote Method Protocol (JRMP), has been around for quite some time and is specifically designed for Java-to-Java remote communications.

One of the issues with JRMP is that a JVM must be running on both the client and the server. With the number of so-called legacy applications that are written in languages such as C++, Java needed a way to communicate with these systems. This is where RMI over IIOP helps out.

The Internet Inter-ORB Protocol (IIOP) was designed to allow distributed components to communicate with one another using TCP/IP. IIOP is language- and platform-independent.

By using RMI on top of IIOP, Java can communicate with applications written in many other languages and on various platforms. RMI/IIOP, as it often is written, is required to be supported by all EJB servers and exists in the EJB and J2EE specifications.

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.

2.1.4 The Enterprise Information System Tier

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.

2.1.5 Where Does Struts Fit In?

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.

Figure 2-2. The Struts framework is used within the web tier