Making High-Level Application Architecture Decisions

Choosing the Java platform and JDO as the internal service implementation and persistence model is difficult to legitimize without completely exposing the requirements and architecture process. The primary reason for the selection is the open and accessible standards through the Java Community Process (JCP), coupled with the experience of the person implementing the solution.

Determining the Application Structure

The high-level application structure you use is an important place to start the application case study. The requirements of the application help to determine the structure of the application. Fortunately, where requirements leave off, architectural patterns begin. Three architectural patterns are of interest as you get started. The Layers pattern [Buschmann] gives you guidance on how to deal with a separation of concerns that will aid you in development of your application. The N-Tier Architecture pattern is a derivative of the Layers pattern with more specificity applied. Finally, the Java architecture blueprint gives a concrete example of an n- tier architecture.

After reviewing each of these important architectural patterns, you will finally produce the overall architecture of the P.T. Monday Coffee Company application. The basic architecture presented is a derivative of the patterns presented in the next three sections.

Introducing the Layers Architectural Pattern

The Layers architectural pattern is basic in nature but important in practice. The essence of the pattern is that you should design applications in layers, with each layer representing a group of related concerns. Each layer contains related classes and components and has a structured interface and communication mechanism to access capabilities within the layer.

Layers typically stack on top of one another, building capabilities of the overall application, as shown in Figure 2-3. It is common that each layer accesses only the layer underneath, though layers often have to access multiple layers in practice.

Figure 2-3: Layers architectural pattern

The most difficult part of working with layers is determining what layers to separate and how to embody the separation between the layers. The layer separation should make sense from a technical grouping standpoint as well as an organizational structure standpoint. Keep in mind that the technical content will outlast your personnel structure, so be careful to consider technical merit as the primary organizational principle. Typical layers are the presentation layer, the business content layer, the persistence layer, and the client layer. For example, the concerns of presentation to a browser are radically different from the concerns of persistence to a database.

You can create separation between layers in different ways. It is entirely possible to implement architecture with layers yet have the entire application run within a single physical process. In this scenario, you only leverage the layered approach at development time, not at deployment time. You can also separate layers by process on a single computer or by process on separate computers. This technique introduces performance penalties in terms of intercomponent communication, but you may be able to compensate for the performance loss by the flexibility in which you can deploy each layer. Further, each layer can focus on optimization within their own components as long as they adhere to the layer interface.

Just stating that your architecture adheres to the Layers pattern is not enough for developers and designers. You must go further to explain the content of the layers in the architecture as well as a sampling of components in the layers. The next two patterns dig deeper into specific examples.

Introducing the N-Tier Architecture Pattern

The N-Tier Architecture pattern is a generalization of a three-tier architectural pattern. The three-tier architecture consisted of a workstation presentation, the business logic, and a database and the logic to support it. In today's component architectures, including Web Services, a three-tier architecture simply does not properly portray the flexibility with which you can use a component architecture.

A description of the tiers as well as a description of how the tiers communicate typically accompanies identification of the n-tier architecture. Figure 2-4 shows an example that contains a client tier, a presentation tier, a business logic tier, and a persistence tier. Communication between the client tier and the presentation tier occurs over Hypertext Transfer Protocol (HTTP), communication between the presentation tier and business logic tier occurs with Remote Method Invocation (RMI), and communication between the business logic tier and persistence tier occurs with JDBC.

Figure 2-4: N-Tier Architecture pattern

Looking back at the case study requirements (including B1, B2, F3, and F8), you can see that there are multiple access points to your system. Users can access your system through a visual interface, and programs can access your system through a programmatic API. You do not necessarily know how your customers will use your business logic; they may have their own logic tier or a process tier with yet another presentation tier on top of that. Screen scrapers can add additional presentation tiers on top of your own, and you can even help them by introducing an API to your presentation tier to send and retrieve forms.

By locking yourself into a three-tier architecture, you may inhibit your flexibility to create a malleable system that fulfills as many requirements and scenarios as possible. The n-tier architecture will suit your requirements and give developers and designers a better place to start than simply identifying the Layers pattern.

The J2EE architectural blueprints expound further on n-tier architectures. The more detail and examples that you, as architects , can give to designers and developers, the better off you will be by the time implementation of the architecture gets started.

Introducing the J2EE Application Architecture

Examples of J2EE application architecture are excellent examples of an n-tier architecture in practice. The J2EE documentation calls an n-tier architecture a multitier architecture. The primary architectural blueprint appears as a three- tier architecture, but the flexibility of the architecture turns it into an n-tier architecture.

The three-tier J2EE base implementation consists of a client tier, a middle tier, and an enterprise information services tier, as shown in Figure 2-5. The middle tier is more complex than a traditional middle tier and facilitates both rendering for clients and business logic accessed by the presentation. In essence, the middle tier contains layers within the tier. The middle tier layers get physically deployed into two containers: an EJB container and a Web container. The containers separate the operating environments and give a single point of control for container configuration that applies to the components residing within each separate container. In J2EE, the tiered representation implies more of a deployment model than a logical development model. You can think of the development model as a four-tier , or more, architecture.

Figure 2-5: J2EE architectural blueprint

Variations of the J2EE architecture include the insertion of additional tiers between the middle tier and the client tier. For example, a Webtop (a thin client that contains a Java operating system) inserts an additional Webtop server tier between the middle tier and the client tier. To facilitate this additional tier, you have to ensure that the middle tier has acceptable interfaces on which clients can rely.

One of the problems with layered architectures comes in the development of a product on top of a layered architecture. Business logic developers adhering to the strict definition of tiers or layers will want to build interfaces agnostic of the tiers above them. Developers of the presentation tier will want tiers below them to fulfill only their requirements and optimize the interface to business logic for the presentation tier's use. The reality is that developers must compromise reality and purity. The primary use of the business logic will be through a presentation tier; making it work in an optimal way for customers is a priority for the business logic tier developers. On the other hand, business logic developers must push back as presentation concepts creep into the business logic tier because there is no guarantee that outsiders will use a presentation tier on top of the logic.

Determining the P.T. Monday Application Structure

The P.T. Monday Coffee Company application structure follows directly from the N-Tier Architecture pattern and the J2EE architecture blueprint. Figure 2-6 shows the high-level structuring of the application and platform. In it, you see a classic n-tier structure that is common in today's Web-based applications and that is derived from the Layers architectural pattern. You also see many attributes of the J2EE architecture, with a formal breakdown of the Web tier and the business logic tier.

Figure 2-6: High-level application structure

The application structure consists of the following:

Client tier: This tier contains the different devices and mechanisms your customers will use to access the application. Your two primary accessors are users accessing the application from a browser and other computers accessing the Web Services that you expose. The primary support protocols are Extensible HTML (XHTML) over HTTP and Simple Object Access Protocol (SOAP) over HTTP. Your implementation must be flexible enough to adapt to other channels of access, perhaps with the addition of a tier to support the other access channel, such as the Webtop in the J2EE example.

Web tier: This tier has two responsibilities: accepting requests from browser-based clients and accepting requests from other business logic tiers accessing logic through a programmatic API. Both types of requests forward business logic to the business logic tier for processing, and the Web tier handles any presentation or request/response transformations.

Business logic tier: This tier contains the logic that the application must use to fulfill user requirements. There are cases when business logic to fulfill a particular process actually exists outside of your application. In this case, the business logic tier contains the logic required to integrate the external logic into your own application.

Persistence tier: The ever-present database makes up the persistence tier. Although no explicit coding is required in the presentation tier because of the technologies in use, it is important to acknowledge its existence up front so that you can consider it during deployment.

Although the client tier and the persistence tier are relatively straightforward and are considered but not built , there are some additional architectural details to consider when looking at the Web and business logic tiers.

Exploring the Web Tier

The Web tier facilitates the connection between client requests and the business logic that fulfills the client requests. There are a variety of ways to structure the Web tier depending on the types of clients it facilitates. The Web Service path facilitates the programmatic access to business logic, and a path with Java Server Pages (JSPs) and servlets facilitates the browser-based entry to the Web tier.

There are two paths through the Web tier, as illustrated in Figure 2-7. Programmatic clients work through the Web Service interface. Tomcat routes requests against a Web Service to the Axis Web Services engine running within the Tomcat process. Tomcat routes requests for views, typically from a browser, to a Front Controller [Alur]. The Front Controller facilitates a Web-based Model- View-Controller paradigm for presentation.

Figure 2-7: Web tier components

This book does not cover the presentation path and the Front Controller pattern; see the "Additional Reading" section for more details on the presentation path. Your concern is the Web Service path through the Web tier. This book looks at how clients interact with business logic, how you leverage the Web Service environment in the Web tier, and how you structure business logic for access through the Web Service environment.

With respect to how the Apache Axis Web Service environment runs, you have some interesting issues. These issues are not fully addressed until Chapter 13, "Exploring the Physical Tiers Pattern." In short, there are different mechanisms for deploying a Web Service using the Apache Axis engine. Using the Java 2 Standard Edition (J2SE) and the simplest mechanism for developing Web Services with Axis, your business logic tier gets instantiated directly inside of the Web tier process. Although not a violation of your tiered approach to architecture, it is worth keeping in mind as you develop services throughout the book and up to Chapter 13. Chapter 11, "Implementing the Observer Pattern," and Chapter 12, "Implementing the Publish/Subscribe Pattern," finally push your architecture over the edge, so you must know the Physical Tiers pattern to create physical separation between the tiers.