Making High-Level Application Architecture Decisions

Application architecture has somewhat fuzzy lines drawn with respect to where application architecture leaves off and where application design starts. In this chapter, you will create a simple system structure and make specific technology decisions based on the gathered requirements. By the end of this chapter, you should have a general understanding of your overall architecture direction but have questions about the details of the architecture.

Making Technology Choices

Architecture goes through micro-iterations during which you choose and recommend technologies for system implementation. In the process of choosing those technologies and components , you make slight revisions to interfaces for the various subsystems of your application. Instead of portraying micro-iterations in text, which is a difficult thing to do, I simply list the technology choices before showing the structure of the application. Remember that even though these technology decisions are set early in the text, technology choices should minimally impact your overall application architecture.

Table 2-5 contains a list of decisions and the simplified reasons for those decisions. In many cases, the decisions are based on deeper requirements or experience that is not portrayed entirely in the requirements listed.

Table 2-5: Technology Choices

TECHNOLOGY	DESCRIPTION
Java Platform	The Java Platform is ideal for deploying Web Services because of its maturity and first-class integration into most Web Service platforms.
Java Data Objects (JDO)	The persistence mechanism to use from the Java platform is a difficult choice. There will always be programmers who can handle databases through the JDBC Data Access API, but you are looking for a more natural programming environment. The JDO specification and implementations give you a natural and relatively simple mechanism to leverage the object- oriented environment of Java in concert with persistence without adding complex database code to your classes.
Apache Tomcat	The Apache Tomcat application server is free, mature, and common in the business world. That combination creates a competitive environment for hosting your Web Service technologies.
Apache Axis	Although not as mature as Apache Tomcat, Apache Axis is shaping up to be both competitive and robust in terms of supporting different programming environments. Apache Axis will be your choice for the Web Service environment. It also plugs nicely into Apache Tomcat.
MySQL	Choosing a database is a tricky proposition. You need it to be robust and manageable while maintaining a low total cost of ownership. MySQL is an open -source and free database. Because most of your access to the database will be through JDO, you will be able to avoid most direct database interactions, and the lack of development tools for MySQL does not hurt you badly . Another equally valid choice is PostgreSQL.
MM.MySQL	This is a JDBC driver for MySQL. JDO uses a JDBC driver for accessing the database.

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.

Exploring the Business Logic Tier

The business logic tier handles the processing of all business logic and behavior that is not concerned with client interaction. You should consider the two types of interaction ”programmatic and visual ”while developing your interfaces. In fact, the visual presentation programmers should inspect and codevelop the business logic interfaces whenever possible. Considering the Web Service interface to the business logic forces your presentation components to compromise on the content of the interfaces.

In your application, you should be concerned with two types of business logic:

• Objects that represent a physical business domain.

• Objects that represent processes that your business logic must carry out. In many ways, business processes compose interactions between other business processes and activities as well as the objects that represent the physical business domain.

Depending on the type of technical infrastructure you use, there are additional forms of logic, such as declarative business rules, that help facilitate replacing behavior in one of the two primary categories of logic. This book does not focus on the more advanced systems and mechanisms for altering behaviors.

J2SE is the language of choice for implementing business logic in your application. Evolving Web Service standards could replace Java as the language of choice for complex business processes. Although it is important to keep track of these standards, they do not change the overall concepts behind what a business process is. Further, because this book focuses on Java, it leaves the topic of advanced business process metadata for your own extracurricular activities.

Four chapters discuss business object and business process structuring for Web Services. Although these patterns are fairly well known and taken for granted in pure object-oriented systems, it is important to understand how they interact with the Web Service paradigm.

The J2EE architecture blueprint represents its logic tier with Enterprise JavaBeans (EJBs). By nature, EJBs run within their own container (a manageable context that applies to all of the classes running within it). By choosing to stay with J2SE technologies, you do not have the benefit of a first-class container mechanism, nor is it necessary for the concepts introduced in this book. I strongly suggest you take some time to understand the idea of a container [Volter] and the advantages that a container yields. The Physical Tiers pattern (see Chapter 13, "Exploring the Physical Tiers Pattern") yields more information on using a container mechanism, such as EJB or your own self- constructed container.