Chapter 3: Application Architecture, Security, and Caching

This book progressively builds the application using a use case driven approach. Chapters 4 through 8 explicitly discuss the design, J2EE component development, and configuration aspects of the sample GreaterCause application. However, before we start developing the application, we need to look at several other aspects of the design to ensure a reliable, scalable, extensible, and robust operational environment for the application. In addition to discussing the architecture elements, this chapter assists in putting a perspective around the application security. The discussion on security will assist the readers in envisioning ahead of time the specific needs of their application and plan toward a solution that adequately secures the system from malicious use. Since vendor-specific security implementations and the application requirements differ significantly from one application to another, the focus in this chapter is to provide a high-level overview based on prominent technologies and specifications. This should assist the readers in determining their unique design needs and arriving at a solution that takes advantage of best of breed solutions. Please note that the declarative security provided by the J2EE platform, and the J2EE platform security API used for programmatic security, are discussed in Chapter 5. The final section in this chapter focuses on the design aspects in the creation of an application-level cache. Since this chapter is not a prerequisite for the rest of the book, you may decide to come back to it later.

We assume that J2EE is a platform of your choice, and hence we do not get into the details of why it is a good choice. Several books do a good job at explaining this. We highly recommend Designing Enterprise Applications with the J2EE Platform [J2EE] for getting a solid roundup of all pertinent J2EE technologies. We also recommend Core J2EE Patterns [Core], which covers several of the patterns implemented in this book. For the purpose of reading this book, we expect that the readers have only a basic knowledge of JSP, servlet, and EJB technologies. Some excellent tutorials are available at java.sun.com to quickly bring you up to speed with these technologies.

Application Architecture

The subject of architecture is exhaustive as it refers to several design aspects and relevant artifacts used for the construction of an application. Several of the design artifacts developed during the course of this book contribute to the overall architecture but represent architecture at different levels of granularity. For example, the MVC architecture discussed in Chapter 4 addresses tier-level responsibilities, whereas the design patterns used for implementing EJBs (discussed in Chapter 7) address component-level responsibilities. A security architecture that complements the application architecture will also be at different levels of granularity, as explained in the section "Planning Application Security". Some discernable artifacts and processes of an architecture can therefore be summarized as follows:

• Functionality of the system as expressed by use cases and augmented by wire frames.

• Application layers, their interactions, responsibilities, and the elements they contain for satisfying the use cases.

• Components identified for each layer and their interactions, dependencies, and their roles. This will include both infrastructure and application components.

• Composition of these components; expressing their interaction using appropriate design patterns to form fundamental structural elements that provide repeatable, reusable, and extensible solutions.

• Composition of fundamental structural elements into larger units called modules, or subsystems.

• Composition of the software modules and corresponding configuration files into deployable units.

The 4+1 View Model of Architecture

The overall architecture of a system can be modeled with the following interlocking view as proposed by Philippe Kruchten in a paper "The 4+1 View Model of Architecture" [Kruchten].

• The Use Case View of a system constitutes the use cases that describe the behavior of the system from the perspective of external entities interacting with the use case. The use case view is a static view of the system. It captures requirements that are used in the creation of the system's architecture. This view ties all other views together.

• The Logical View (also called the Design View) of a system consists of classes, interfaces, and their collaborations.

• The Implementation View describes the physical organization of the software and includes the components, files, libraries, and so, on required to assemble the system.

• The Deployment View focuses on hardware topology consisting of physical nodes and computing hardware on which the executables are deployed.

• The Process View is concerned with the concurrency and synchronization aspects of the software—for example, the processes, tasks, and threads.

This book focuses explicitly on the Use Case View and the Logical View of the system. The Use Case View of the sample application was created in Chapters 1 and 2. The static aspects of the Logical View are captured using class diagrams of Chapter 5 where we model interactions between the presentation tier components, and in Chapter 6 where we model interactions between the domain entities, and in Chapter 7 where we model the interactions between various EJBs and helper classes for realizing the business tier functionality. The dynamic aspects of the Logical View are represented using sequence, collaboration, state-chart, and activity diagrams. Sequence diagrams are used extensively in Chapters 5, 6, and 7 to show the interactions between application objects. The Logical View helps create the vocabulary of the problem and its solution. This vocabulary is complemented by the vocabulary of the design patterns employed to solve recurring problems within the system. Design patterns help us articulate commonly occurring interactions between objects in the problem domain and are discussed in several chapters.

Creating a J2EE Architecture Blueprint

Architecture is the software's blueprint, which is derived from the use cases created in Chapters 1 and 2. However, we cannot expect to take the use cases and arrive at the final architecture without going through a refinement process. The architecture of a system evolves as decisions are made in terms of feasibility, technical challenges, trade-offs, cohesion between stated requirements, fluctuating needs of the stakeholders, and so on. This is very much an iterative process where use cases will provide a starting point but there will be a need to modify or extend the use cases as the architect creates the Design View of the system.

The J2EE architectural style does not strictly recommend adherence to a layer-like architecture in which layers have a hierarchical structure and each layer can only communicate with the layer above or below. Instead, it encourages a tiered approach in which different tiers can communicate based on the way the requirements are implemented. Several scenarios depict this approach, as shown in Figure 3-1.

• Clients can interact directly with a Web tier; the Web tier accesses the database tier (database tier is shown as EIS tier).

• Clients can interact directly with the EJB tier; the EJB tier accesses the database tier.

• Clients can interact directly with the Web tier; the Web tier interacts with the EJB tier, and the EJB tier accesses the database tier.

Figure 3-1: J2EE architecture

From Figure 3-1, it is apparent that the role of the container is central to the J2EE architecture. The container interposes itself between the application components and the J2EE platform services. This gives the container the ability to transparently inject the platform services based on the configuration information declaratively specified in the deployment descriptors. An EJB container, running on the J2EE server, manages the execution of all EJBs for one J2EE application. It handles the life cycle of EJBs and provides all the system-level services for the EJB. It provides transaction management, security, resource management, and naming services for the EJBs. A web container, running on the J2EE server, manages the execution of JSPs and Servlets for one J2EE application. The application client container, running on the client machine, manages the execution of application client components for one J2EE application.

The purpose of this book is to sufficiently demonstrate the architecture of a J2EE-based solution for large-scale development. As such, we have used the multi-tiered approach identified by the third item in the preceding list. We have employed container-managed persistence for data access and manipulation, which is covered in Chapters 6 and 7. For accessing a large volume of read-only data, we have favored using a session bean with Data Access Object Pattern [Core] for accessing data directly from the data store when implementing the Value List Handler Pattern [Core]. Please refer to Chapter 7 for design and implementation details.

Employing Frameworks

The architecture employed in this book is greatly simplified as a result of using the open source Struts framework. Struts employs MVC (Model-View-Controller)–style semantics for breaking up the application responsibilities between three distinct layers as suggested by the name. Struts framework is discussed in detail in Chapter 4, with corresponding implementation for the sample application in Chapter 5. Employing frameworks such as Struts provides an architect with the ability to focus on creating elements that plug into the framework and/or framework-related extensions. We therefore architect based on the extension points and the framework's ability to interact with other elements of the application for realizing the use cases. The usage of framework therefore provides a standard way of implementing a specific system functionality, which in this case is the mapping of user actions in the presentation tier to the services offered by the business tier.

A presentation-layer framework will typically solve a recurring problem, namely, mapping of user actions to an application service. This problem space is solved using best-practice patterns such as Front Controller [Core], View Helper [Core], or a combination pattern such as Service to Worker [Core] or Dispatcher View [Core]. Creating a custom application-specific framework (a one-off solution) is not a trivial undertaking, as is obvious in the discussion of Struts framework in Chapter 4. The class diagrams of Chapter 5 clearly show how simplistic the approach is when designing with a framework like Struts. We simply focus on implementing abstract methods or subclass Struts-provided request handler class. By employing a few design patterns, such as Command [Gof], Business Delegate [Core], Service Locator [Core], and Session Fa ade [Core], we are able to create a design vocabulary that is consistently replicated across most use cases. This greatly promotes understanding between developers who create implementations for realizing different use cases but with the semantics that adhere to the common design vocabulary of the system.

Designing for a responsibility-driven tiered architecture enables construction of software in a manner that addresses the objective of isolating infrastructure-specific functionality from application-specific functionality (that is, custom functionality) for each tier. With the Struts framework, the Model-View-Controller semantics provide for three different layers of responsibilities.

Generally speaking, use of a framework could impose an architectural template for building applications within a specific domain. However, frameworks provide reusable infrastructure service that are used by many use cases in the system. Bypassing the framework approach will entail that each use case with a common set of functionality will have to address its needs by creating a one-off solution. Obviously such approaches are self-defeating in the long run since they create inflexible and hard to maintain code.

J2EE Components in an Architecture

When developing business applications, a large amount of time could be spent building core system services like transaction management, resource management, security, remote connectivity, and object relational mapping services. These services are essential to all enterprise applications and can be abstracted into a reusable and declaratively configurable framework that could provide these essential services to all applications at runtime. Such a framework enables architects and engineers to focus on solving the business problem, thus simplifying the designing and coding effort and offering consistent implementation semantics for all applications using the framework. The J2EE architecture offers a standard set of system services to application components as part of the runtime environment referred to as containers.

J2EE provides component-based approach for the design, development, assembly, and deployment of enterprise applications. There is clear separation of responsibility between the different tiers, as shown in Figure 3-1. The tiered approach decomposes a problem domain into fundamental units of application functionality that are appropriate for each tier. This makes it possible to offer a highly reusable component-based architecture in which a Model-View-Controller (MVC) architecture is a natural fit.

The services offered by the containers are configurable declaratively and interpreted at deployment time, thus insulating code from any modification should there be a need to modify the behavior of these system-level services. For example, transactional semantics are specified declaratively for a set of interrelated components composing a service. The components from one domain can be mixed with components from another domain to offer a new set of services whose transactional semantics could be specified differently (and declaratively) using XML-based deployment descriptors. Similar discussion is true for configuring security roles for describing access privileges for a set of users in the newly composed application. The deployment descriptors are explained in Chapters 5, 6, and 7 for components of the sample GreaterCause application. The J2EE specification ensures that code written in accordance with the specification will be portable across various vendors.