8.1 Segmenting Application Processing
Not that long ago, the common environment for performing computer- related tasks was to log on to an operating system from a terminal directly connected to that system. From your connection, you could interact with applications and, possibly, a database or two. Everything lived on the server:
As computing has evolved, additional ways of interacting with a computer and an RDBMS have also evolved. There are now three common approaches:
A direct connection to a computer on which we perform all our work
A client/server (two- tier ) architecture
A thin client (three-tier) architecture
We'll describe each of these architectures briefly in the following sections.
8.1.1 Direct Connection to a Database Server
Originally, the Oracle software, database(s), applications code, and everything else necessary to perform the required work was housed locally on one machine. You worked from a terminal directly connected to the computer to perform whatever tasks were required. Using this method of connection meant that you had to be in the same building as the computer or at a distance limited by how far away from the computer the hardwiring would reach and still be usable. Figure 8.1 illustrates a direct connection to the database.
Figure 8.1. Direct connection to a database server
There were several common problems with this approach.
You had to be in close proximity to the computer with which you were interacting
If you were too far away from the central computer, line noise could cause interference with data transmission
You could not send or receive information to or from another site easily
If you needed to send critical information to your boss halfway across the country, you would create a 9-track tape containing the information you wanted to send, package the tape, and ship it via a ground or air carrier. Your boss might not receive the tape until several days or a week later. Obviously, this method of information transmission was not very efficient or quick.
8.1.2 Client/Server (Two-Tier) Architecture
The next architectural advance was called client/server and placed the Oracle software and database(s) on one platform and the applications code on a client or personal computer (PC). In this scenario, Oracle's SQL*Net product was used to carry queries to the server and carry data back to the PC. The PC required substantial resources to support this environment, and the task of ensuring that all PC clients were current and secure has proved to be an administrative and security nightmare. This architecture is typically referred to as two-tier and can be seen in Figure 8.2.
Figure 8.2. The client/server architecture
Client/server has the advantage of distributed processing. Part of the processing of the work is done on the database server, and part is done on the workstation. The latter mostly includes the display management, user interface, and application processing that is independent of the database. Not only is the total computing burden spread more evenly between the client machine and the host or server machine, but you can perform tasks independently from the server. You can perform these tasks in a room or building much farther away from the physical location of the server.
The client/server configuration requires a fairly robust workstation, typically having a 2-gigabyte hard disk (or larger) and 24 megabytes or more (frequently 64M or more) of RAM. Not too many years ago, the cost of such a computer would have been over $5,000. Even though workstation costs have declined, the cost of maintenance, primarily the software upgrades and configuration, has been estimated in excess of $10,000 per workstation per year as a recurring cost.
Because of some of the drawbacks of the two-tier architecture, a configuration was sought that would provide the distributed processing capability of the client/server implementation, but reduce the maintenance costs. If it also reduced the cost of the workstation, so much the better. One approach was to put the application executables on a network file server and let the workstation load the executables from there. This met with some success in reducing the maintenance effort, but still required a robust or fat client for a workstation. The term fat client comes from the need to store all the application code on each client in order for the client to perform the required work.
8.1.3 Thin Client (Three-Tier) Architecture
The next and newest level of architecture uses a low-capacity workstation, sometimes without a hard disk, as the first tier. This workstation does not actually run the application but performs the display management and more after code is downloaded to the client. A second "application server" holds and executes the applications using a language such as Java to communicate with the workstation. The applications executing on this server communicate with the database server, the third tier, using the protocols of the database (in the context of this book, Oracle and SQL*Net).
A slightly different version of the second and third tier relationship is one in which the second tier performs some of the application processing and the rest is performed on the third tier. This is how the Oracle Application Server functions when dynamic HTML is used for the application.
In all cases, since there are now three computers continuously involved in the processing stream, this architecture is referred to as a three-tier architecture, shown in Figure 8.3. Because the workstation now has virtually nothing installed, and does not have to have a large disk or huge amounts of memory, it is frequently referred to as a thin client .
Figure 8.3. The thin client architecture
The three-tier architecture is useful in many ways. It enables:
Low resources on the client side with potentially minimal security requirements
Medium amounts of resources on the application server with higher security requirements
High resources requirements for one or more back end servers with varying amounts of security required (based on the application which a particular database supports)