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.