Introducing Enterprise Java Application Architecture and Design
|This article is based on a chapter from Pro Java. EE Spring Patterns: Best Practices and Design Strategies Implementing Java EE Patterns with the Spring Framework by Dhrubojyoti Kayal. It is being reproduced here by permission from Apress.|
For a long time, Java Enterprise Edition (Java EE) has been the platform of choice across industries (banking, insurance, retail, hospitality, travel, and telecom, to name a few) for developing and deploying enterprise business applications. This is because Java EE provides a standard-based platform to build robust and highly scalable distributed applications that support everything from core banking operations to airline booking engines. However, developing successful Java EE applications can be a difficult task. The rich set of choices provided by the Java EE platform is daunting at first. The plethora of frameworks, utility libraries, integrated development environments (IDEs), and tool options make it all the more challenging. Hence, selecting appropriate technology is critical when developing Java EEbased software. These choices, backed by sound architectural and design principles, go a long way in building applications that are easy to maintain, reuse, and extend.
This article takes a tour of the fundamental aspects of Java EE application architecture and design. They form the foundation on which the entire application is developed.
With application architecture in place, I will focus on Java EE application design based on object-oriented principles. I will also explain the use of design patterns to simplify application design and the adoption of best practices. I'll also touch on the Java EE design pattern catalog as documented by Sun's Java BluePrints and subsequently elaborated on in the book Core J2EE Design Pattern by Deepak Alur et al (Prentice Hall, 2003). I'll end the article with an introduction to Unified Modeling Language (UML) and its role in visually documenting Java EE design and architecture.
Evolution of Distributed Computing
In distributed computing, an application is divided into smaller parts that run simultaneously on different computers. This is also referred to as network computing because the smaller parts communicate over the network generally using protocols built on top of TCP/IP or UDP. The smaller application parts are called tiers. Each tier provides an independent set of services that can be consumed by the connecting or client tier. The tiers can be further divided into layers, which provide granular-level functions. Most applications have three distinct layers:
- The presentation layer is responsible for the user interfaces.
- The business layer executes the business rules. In the process, it also interacts with the data access layer.
- The data access layer is responsible retrieving and manipulating data stored in enterprise information systems (EISs).
The modern state of network computing can be better understood by analyzing the gradual transition of distributed application architecture. In the next few sections, I will examine the transition of distributed architecture with suitable examples.
The single-tier architecture dates back to the days of monolithic mainframes connected by dumb terminals. The entire application comprising layers such as user interfaces, business rules, and data was collocated on the same physical host. The users interacted with these systems using terminals or consoles, which had very limited text-based processing capabilities (see Figure 1).
Figure 1. Single-tier architecture
In the early 1980s, personal computers (PCs) became very popular. They were less expensive and had more processing power than the dumb terminal counterparts. This paved the way for true distributed, or client-server, computing. The client or the PCs now ran the user interface programs. It also supported graphical user interfaces (GUIs), allowing the users to enter data and interact with the mainframe server. The mainframe server now hosted only the business rules and data. Once the data entry was complete, the GUI application could optionally perform validations and then send the data to the server for execution of the business logic. Oracle Formsbased applications are a good example of two-tier architecture. The forms provide the GUI loaded on the PCs, and the business logic (coded as stored procedures) and data remain on the Oracle database server.
Page 1 of 7