JDBC Architectural Models

A two-tier database model is a graphical way of representing the relationship between an application and a database.
A traditional two-tier database model applies to a scenario where an application communicates directly with a database.
The application is one tier, and the DBMS is the second.
The main function of JDBC in a two-tier database model is to connect the application directly to the database.

Client/server configuration

This two-tier model is commonly called a client/server configuration.
The JDBC driver delivers the user commands to the data source, and returns the results from the datasource to the user, as you see in the graphic below.

two-tier design database model static graphic

The n-tier model

In the Java-related two-tier model, the piece added to the client is a JDBC driver.
This provides the request/response communication between the two tiers.

Two-tier model

The benefit of the two-tier model is its simplicity.
In situations where more flexibility is required developers turn to an n-tier model.
In its simplest form, an n-tier design has three tiers. Those three elements are:

Client

Server

Database.

The server is positioned in the middle of the model. Client applications communicate with the server via some type of middleware such as Java RMI or CORBA.
The server communicates with the database using a database protocol such as JDBC the same way the client communicated with the database in the two-tier model.
This approach is flexible enough to allow for multiple servers and databases, hence the "n" reference as a way to represent an arbitrary number of those entities.
The following MouseOver illustrates the functions of an n-tier model.

n-tier architectural model
The main function of JDBC in an n-tier database model is to allow the developer to split request/response processing into two portions of code.
Part of the code processes on the client side, which is mostly data presentations. The other part processes on the server side, which consists of mostly business rules and database access modules.

Elements of n-tier architecture

The elements of the n-tier architecture include presentation services (or the presentation layer), process services (or the middle layer),
and business services (or the business layer). These services perform different functions, as explained in the following table.

Service

Function

Presentation services

The presentation services provide the user interface to the system. This can be achieved through traditional graphical interfaces (such as a Windows PC) and terminals, or through other technologies such as Web browsers, interactive TV, kiosks, ATMs, and interactive voice response (IVR).

Process services

The process services act as a buffer between the presentation and the data. In an n-tier architecture, all
user access to the data occurs through presentation services, which communicate with the process services. Typical process services, then,
include customer searches, product updates, archiving of data, and complex business rule checks. This tier would also include services that
were not necessarily tied to the presentation layer, such as scheduled batch processes or automatic event handling.

Business services

The data services provide the data on which the process services work. The database server typically
fills this role, but it may also consist of file systems, sensors, telemetry, etc.

The function of middleware

The middleware ties all the tiers together. Any client/server architecture, whether two-tiered or n-tiered, requires middleware to provide the communications link among the layers.
Middleware is normally provided as generic toolsets that can be configured to support your particular set of services.
Examples of these are

Physically, these three tiers can be implemented in a wide variety of ways, which is where multi-tier comes in.
As illustrated in the following graphic, any of the services can be set up as multiple layers, with one service calling other services to perform specialist tasks.
The following table describes the characteristics of an n-tier approach.

Characteristic

Description

Characteristic One

All business logic resides in the middle-tier server application. This includes all database schema, connection, SQL statement creation, and SQL error handling. The server may also perform data conversion services to the client.
For instance, the client may need database information in the form of a tree, a Java object, a list of Java objects, or a hashmap of Java objects.
By placing this logic in the server it is written once and reused by many (potentially different) client applications

Characteristic Two

An n-tier architecture facilitates the thinnest possible client application (often a UI).
Clients, freed from knowing about the database organization, table names, column names, and SQL syntax, become solely a presentation and input layer. The database may be modified without requiring modification and redeployment of the clients.

Characteristic Three

Solutions with an n-tier architecture have separate software entities with well-defined interfaces that allow
parallel development of individual tiers by application specialists.

Characteristic Four

An n-tier architecture allows client notification of database changes. Since the middle tier knows when
database changes occur and which entities were modified, it can call back the client so the client can intelligently decide when to refresh
its displayed data. Less desirable alternatives are for the UI to either blindly refresh its data periodically or refresh its data only
when the user requests it. These options waste network bandwidth and have a higher probability of showing stale data.

Business benefits are provided by an n-tier architecture,
even when compared to a two-tier client/server.
In the next lesson, you will begin to apply guidelines for defining the use of JDBC in a business solution.