Database Reference
In-Depth Information
The application architecture must support application versions and the ability for multiple ver-
sions of the same application to operate simultaneously. Security is also a critical requirement for
the deployment of an application (see Chapter 14, Section 14.6 “Privacy and Security”).
10.1.2 N-Tier Application Architecture
In the 1980s, the prior monolithic architecture began to be replaced by the client/server archi-
tecture that split applications into two pieces in an attempt to leverage new inexpensive desktop
machines. Distributing the processing loads across many inexpensive clients allowed client/server
applications to scale much more linearly than single host/single process applications could, and
the use of off-the-shelf software like Relational Database Management Systems (RDBMSs) greatly
reduced application development time. While the client could handle the user interface and data
display tasks of the application and the server could handle all the data management tasks, there
was no clear solution for storing the logic corresponding to the business processes being auto-
mated. Consequently, the business logic tends to split between the client and the server: typically,
the rules for displaying data became embedded inside the user interface, and the rules for inte-
grating several different data sources became stored procedures inside the database. Whereas this
division of logic made it difficult to reuse the user interface code with a different data source, it also
made it equally difficult to use the logic stored in the database with a different front-end UI (like
ATM, mobile) without being required to redevelop the logic implemented in the earlier interface.
Thus, a customer service system developed for a particular client system (like a 3270 terminal, a
PC, or a workstation) would have great difficulty in providing telephony and Internet interfaces
within the same business functionality.
The client/server architecture failed to recognize the importance of managing the business
rules applicable to an enterprise independent of both the user interface and the storage and man-
agement of enterprise data. The three-layered application architecture of the 1990s resolved this
problem by subdividing the application into three distinct layers:
◾
Presentation
: Which formats and displays the data independent of the way it is interpreted
or processed and stored by the other two layers
◾
Business logic
: Which implements the business logic to process data independent of how it is
stored or displayed by the other two layers
◾
Data management
: Which stores and manages data independent of how it is processed and
displayed by the other layers
With the advent of the Internet, in the past few years, the three layers were split even further to
accommodate the heterogeneity and differing priorities of different parts of the enterprise in terms
of the functionality and performance of user interfaces, processing systems, or databases.
The power of the N-tier architecture derives from the fact that instead of treating
components as integral parts of applications, components are treated as stand-alone
entities that can provide services for applications. Applications exist only as cooper-
ating constellation of components, and each component in turn can simultaneously
be part of many different applications.
