Introduction

You probably heard a lot of 2-tier and 3-tier JDBCs. So what is all this
2-tier versus 3-tier fuss about? It is about how you split client/server
applications into functional units that you can then assign to either the
client or to one or more servers. The most typical functional units are
the user interface, business logic, and shared data. There sre many possibly
variations of multi-tier architectures. It all depends on how you split the
application and on the middleware you use to communicate between tiers.
In 2-tier client/server systems, the application process is either buried inside
the user interface on the client or within the database on the server (or both).
In 3-tier client/server systems, the application process lives in the middle-tier;
it is separated from data and the user interface. Processes become first-class
citizens; they can be managed and deployed separately from the GUI and database.
In theory, 3-tier client/server systems are more scalable, robust, and flexible.
In addition, they can integrate data from nultiple sources. Examples of 3-tier
client/server systems are TP Monitors, distributed objects, and the Web.
Examples of 2-tier client/server systems are file servers and database servers with
stored client/server procedures.
2-Tier JDBC

The above figure shows a 2-tier JDBC client/server split. In this "fat client" approach,
the client maintains JDBC drivers for every database engine it needs. In the pure
2-tier approach, the application process runs on the client. In a less pure 2-tier
approach, you can offload some of the application process to stored procedures on the
database engine. You should note that stored procedures are extremely non-standard.
They lock you into a proprietary vendor implementation. For example, you
write Oracle stored procedures in PL/SQL; you write Microsoft stored procedures
in Transact-SQL. You should not use stored procedures if you want your JDBC
applications to be portable across multivendor DBMSs.
2-Tier Plus JDBC
The 2-tier plus approach introduces a middle-tier "JDBC driver server"
that sits between the client and the DBMS engines. Clients invoke normal JDBC
calls that are then transmitted -- via ORB or RPC -- to the JDBC driver manager
on the server. The driver manager hands the call to appropriate JDBC driver. In
2-tier plus, all the JDBC drivers reside on the server side. Examples of 2-tier plus
products include Symantec's dbANYWHERE and Visigenic's VisiChannel". Symantec
uses a socket-based RPC to communicate calls between the client and the driver
server; Vivigenic uses CORBA. In both cases, the underlying ORB is totally transparent
to your clients; you simply invoke JDBC calls.
2-tier Plus has less software to install and maintain on the client.
you don't need to be constantly deploying the JDBC latest drivers to each
client. In addition, you don't have to deal with conflicting JDBC drivers on
the client and their CLASSPATH requirements. In general, 2-tier Plus removes
some of the administrative burdens associated with managing the 2-tier client.
In 2-tier Plus, all the drivers are on the servr. This makes it easier to upgrade,
maintain, and control the JDBC environmenta and more secured environment. Comparing
to 2-tier, 2-tier Plus is a better performing client/server architecture.
The 2-tieer Plus is still a fat-client approach.
3-Tier JDBC

The above figure shows a 3-tier JDBC architecture. In the next step
up in the evolutionary scale, a significant part of the application is offload from
the client to the server-side objects. Any function that deals with JDBC data should be
on the server side. The idea is to make the application that handles the data reside
on the server with the JDBC drivers and possibly the DBMS engine.
You can always offload sone of the processing by running the DBMS engines on their own server
machines. It's all one big trade-off.