This document provides an architectural overview of the Java Pet Store, the sample application for the J2EE BluePrints program. J2EE is a fully-featured development framework for creating scalable, reliable enterprise applications from reusable components. Learning a new application framework can be a daunting task. The J2EE BluePrints program, and the Java Pet Store sample application, helps you understand and effectively use this powerful technology.
The Java Pet Store is a sample application which illustrates basic usage of J2EE technology, and demonstrates current best practices in system design. The intent of the Java Pet Store is to cover as much of the platform as possible, as clearly as possible, in a relatively small application. Therefore, while the entire application works as intended, some functionality may not be completely filled out. For example, the inventory shipped with the Java Pet Store application is much smaller than what a real inventory would be.
This document begins with a high-level examination of the Java Pet Store application architecture, focusing first on the application design goals. A discussion of the MVC (Model-View-Controller) design pattern, upon which the Java Pet Store is based, is followed by a quick description of the functional modules and with tiers into which the Java Pet Store application is divided. Since this is an architectural overview, it lacks some of the detail needed to completely understand the operation of the code.
Knowledge of the Java language is assumed, as is some understanding of basic issues in enterprise data systems. The target audiences for this document are developers, software architects, and technically-oriented managers who are interested in using the Java Pet Store sample application to understand how to use the J2EE platform.
High-level architecture
All enterprise applications of any size require a consistent architectural vision. Poorly-factored enterprise applications, with no clear requirements, and maintainable only by the developers that created them, eventually collapse under their own weight.
Consider some of the challenges facing the enterprise application architect. Managing the size and complexity of a business application is a challenging task. Commonly, many people with varying skill sets are involved in the development of enterprise application, and even more people use the application to do their jobs. Application requirements are constantly in flux, as they track changes in organizational structure, business environment, and legislation. New technologies, providing new business opportunities and posing new risks, are constantly appearing. Enterprise applications must be able to incorporate new technologies without complete reimplementation. Businesses that plan to grow and compete in a global marketplace require mission-critical systems that are scalable and distributed.
All these issues, and many more, have an impact on the design of a business application. This section provides a high-level description of the Java Pet Store architecture. It discusses application design goals, and the various ways in which the implementation is divided to meet those goals. Following that is a description of how design goals are met using the MVC design pattern, multitiered implementation, modular design, and J2EE design patterns.
Application Design Goals
The Java Pet Store is a typical e-commerce application, presenting users with various views of products and services for sale; taking and acknowledging orders; processing credit cards; and managing user logins, shipping information, and shopping sessions. The Java Pet Store also includes administration functions, including inventory and order management. The application is also designed to support easy creation of interfaces to other systems, to leverage new technologies as they develop, and to provide business-to-business functionality.
To support these functions, Java Pet Store was designed with several high-level goals in mind:
Code and design reuse. Code reuse decreases the cost for new development, provides incremental quality improvements (as software flaws are repaired in long-lived components), and establishes design best practices that everyone in the organization understands.
Rational functional decomposition. Every class in the design plays a clearly-defined role in the application. The resulting design clarity facilitates maintenance, impact analysis, and system extension; and flattens the learning curve for new developers.
Development tasks isolated by skill sets. The design partitions the application into chunks that reflect the skill sets of subteams in a development group. For example, if the design specifies using JSP tag libraries, instead of JSP pages with embedded code, web page designers with no knowledge of programming can operate in parallel with programmers, and programmers can focus on solving coding problems.
Decouple classes with differing rates of change. Parts of the application that change quickly require both greater ease of change and looser coupling to the rest of the system. Subsystems that change more slowly can be more tightly coupled, providing efficiency opportunities.
Extensibility. Application functionality must be able to keep up with organizational growth and technological change.
Modularity. Breaking a design into modules that interact through well-defined interfaces allows developers to work independently, enhances maintainability and testability, and provides opportunities for using purchased components and outsourcing some development.
Security. Since the application is performing financial transactions, and for the privacy and security of customers, data security enforcement is crucial.
Common look-and-feel. Applications are easier to use if the user can always guess where to look for desired information.
Minimize network traffic. The application should avoid transmitting data needlessly or redundantly.
Allow for multiple user interfaces. Data should represented in a way most appropriate for the task at hand. New types of user interfaces should be easy to add.
Persistent data must always be consistent.
The Java Pet Store design fulfills these goals by using the MVC design pattern to separate form, function, and data; by dividing the application into functional modules and multiple tiers; and by applying several design patterns, which are common problem solutions which have been found to work well in the past.
Application Partitioning
The Java Pet Store design partitions the application in three basic ways. Keep in mind that these partitions are conceptual, and do not necessarily map directly onto implementation details such as database schema or class hierarchies. They are a vocabulary for discussing the problem domain and possible implementation strategies, not implementation structures in themselves.
The first partition, the Model-View-Controller (MVC) architecture, separates data presentation, data representation, and application behavior. The second partition divides the application into multiple tiers, separating application clients, Web functionality, Enterprise JavaBeans functionality, and back-end persistence and legacy systems. Traditional modular decomposition of application functions partitions the application in a third way.
Each high-level partition provides a specific design benefit, offsetting the additional complexity the partition requires. The MVC architecture provides flexibility, reusability, testability, extensibility, and clear design roles for application components. The multitiered design allows flexible choice of implementation technologies, as well as scalability and evolvability. Modular design decomposes application functions into intuitive, loosely-coupled subsystems, which are individually analyzable, testable, and comprehensible.
Partitioning an application into so many conceptual pieces greatly complicates the design. Software architecture is in large part the art of meeting design requirements in the presence of many competing forces: openness vs. integration, design consistency vs. specialization, stability vs. malleability, and so on. Dividing an application into multiple abstract conceptual pieces allows the architect to choose an appropriate solution in a particular context. The challenge is to design a system that captures the essential complexity of the problem domain, while minimizing the non-essential complexity of implementation details. Or, to quote Albert Einstein, "Everything should be as simple as possible, and no simpler.".
The following three sections describe how these partitions improve the design of the Java Pet Store sample application.
The Model-View-Controller Architecture
The key design pattern used in the Java Pet Store is the Model-View-Controller (MVC) architecture. MVC separates three distinct forms of functionality within application. The Model represents the structure of the data in the application, as well as application-specific operations on those data. A View (of which there may be many) presents data in some form to a user, in the context of some application function. A Controller translates user actions (mouse motions, keystrokes, words spoken, etc.) and user input into application function calls on the model, and selects the appropriate View based on user preferences and Model state. Essentially, a Model abstracts application state and functionality, a View abstracts application presentation, and a Controller abstracts application behavior. The MVC design pattern thus meets the design goal of rational system decomposition.
It is important to understand that Model, View, and Controller are usually not represented by individual classes; instead, they are conceptual subdivisions of the application. Views in the Java Pet Store consist of JSP pages rendered in a browser, stand-alone applications that provide View functionality, and interfaces to spreadsheet programs. The Model is represented as a group of Model classes (CartModel, InventoryModel, CustomerEJB, and so on), to which ModelManager.java provides a single point of access. The Controller consists of MainServlet.java, which dispatches browser requests to other controller objects such as ShoppingClientController.java, AdminClientController.java, and their related support classes.
There are many benefits to using MVC in a design. Separating Model from View (that is, separating data representation from presentation) makes it easy to add multiple data presentations for the same data, and facilitates adding new types of data presentation as technology develops. Model and View components can vary independently (except in their interface), enhancing maintainability, extensibility, and testability. Separating Controller from View (application behavior from presentation) permits run-time selection of appropriate Views based on workflow, user preferences, or Model state. Separating Controller from Model (application behavior from data representation) allows configurable mapping of user actions on the Controller to application functions on the Model.
For more on the Model-View-Controller design pattern, see the corresponding document in the J2EE Pattern Catalog.
Multitiered Application
The Java Pet Store design is divided into multiple tiers: the Client tier, Web tier, the Enterprise JavaBeans tier, and the Enterprise Information System tier. These tiers are not necessarily arranged hierarchically. Each tier may communicate directly with other tiers, or indirectly by way of intermediate tiers. Partitioning a design into tiers allows designers to choose the appropriate technology for given situation. Multiple technologies can even be used to provide the same service in different situations. For example, HTML pages, JSP pages, and stand-alone applications to all be used to create in the client tier. Each of the four tiers plays a specific role in the design.
The Client Tier
The Client tier is responsible for presenting data to the user, interacting with the user, and communicating with the other tiers of the application. Often, the Client tier is the only part the application the user ever sees. The Java Pet Store Client tier consists mainly of a browser displaying Web pages generated from server-side JSP pages in the Web tier. An administration interface, however, uses a spreadsheet as a client, communicating with the Web tier with XML messages. The combination of the spreadsheet and the code the spreadsheet uses to process the XML messages can also be considered part of the Client tier. The Client tier communicates with other tiers by way of well-defined interfaces. Like the View of the MVC pattern, including a separate Client tier in the design provides flexibility and extensibility. Future new clients can be written using technologies or languages that do not yet even exist, since they must conform only to the interface for communicating with other tiers. Clients in the Client tier usually contain one or more Views of the MVC design. So-called "thin" clients tend to limit themselves to View functionality, while "fat" clients can include Controller and even Model functions.
The Web Tier
The Web tier is responsible for performing all Web-related processing, such as serving HTML, instantiating Web page templates, and formatting JSP pages for display by browsers. The Web tier in the Java Pet Store does all of these, and takes on the Controller functions for the Web application, caching model data (and updating it from the Model when necessary), interpreting user inputs, selecting appropriate Views based on application flow, and managing database connections. Some objects within the Web tier act as proxies to components in the Enterprise JavaBeans tier. Clients that wish to communicate with the Java Pet Store using non-Web technology (such as CORBA) might not use the Web tier at all. The Java Pet Store Web tier is also user-aware, and presents Model data to the user by selecting appropriate Views, and populating them with data corresponding to only that user.
The Enterprise JavaBeans Tier
The Enterprise JavaBeans tier is responsible for any processing involving Enterprise JavaBeans. Enterprise JavaBeans are software business components which extend servers to perform application-specific functionality. The interface between these components and their containers is defined in the Enterprise JavaBeans specification. Typically, server vendors implement the server and the Enterprise JavaBeans containers, as well as tools for deploying Enterprise JavaBeans into those containers. The containers provide services to the Enterprise JavaBeans instances they contain: controlling transactions, managing security, thread or other resource pooling, and handling persistence, among other high-level system tasks. Application developers can then write Enterprise JavaBeans components, focusing on business functionality, and deferring complex implementation issues to their containers. Essentially, the Enterprise JavaBeans tier provides a component model for access to distributed system services and persistent data. Both stand-alone clients and Web applications in the Web tier can use Enterprise JavaBeans components hosted by the Enterprise JavaBeans tier. The Enterprise JavaBeans tier separates application-specific business logic from the details about how system-level services are implemented. This separation decouples the role of application developers (who focus on application functionality) from that of application deployers (who configure the system for efficient access to resources). It also simplifies application component development, because details about system issues such as persistence, reentrancy, transactions, remote access, and so on, are all handled by the container.
The Enterprise Information System (EIS) Tier
The EIS tier is the enterprise information infrastructure. Members of the EIS tier typically include enterprise information planning (ERP) systems, transaction processing monitors, relational database management systems, and legacy enterprise applications. Access to the EIS tier is usually transactional, to ensure that data are consistent across application boundaries. Many businesses have existing applications or information assets that they would like to deploy onto the Web. J2EE technology can access these applications or assets through the EIS tier. The EIS tier also enforces security and offers scalability. A J2EE application can integrate existing databases and applications with new functionality, forming the keystone of an Enterprise Application Integration program. In addition, the EIS tier can access applications of other organizations or businesses, providing seamless business-to-business integration. The EIS tier provides a layer of software that maps existing data and application resources into the design of a J2EE application in an implementation-neutral way.
Modular Design
The Java Pet Store is designed as a set of modules, each of which is relatively tightly-coupled internally, and loosely-coupled between modules. The modules were identified in the pet store design phase, where groups of similar data and functionality were often used together in multiple scenarios. For example, multiple scenarios included the concept of a "product catalog", and so the pet store design contains a product catalog module. Grouping functionality into modules provides tight integration between classes that cooperate a great deal, yet decouples classes who refer to each other only occasionally. This maximizes the efficiency of access between highly-cooperating classes, but decouples functionality across module boundaries, allowing modules to vary relatively independently. Each module has a well-defined interface that defines the module's functional requirements, and provides a place where third-party products may be integrated. The modules in the Java Pet Store are: user account, product catalog, order processing, messaging, inventory, and control. The source code for these modules appear in the subpackages of the sample application's top-level package com.sun.j2ee.blueprints along with the subpackages mail, which provides e-mail capability; and util, which provides miscellaneous functionality. Modular design supports the design goal that software be reusable, since a well-defined interface decouples the package from the application. Each module also plays a clearly-defined role, meeting the design goal of rational decomposition.