Page 1250
Figure 55.4.
Host/terminal
networking.
Do you hate the buzzwords that float through the computer industry? Client/server must be one of the most frequently used (and misused) words in the computer industry. After upper information systems management gets a buzzword in its head about the ultimate solution to all problems in the computer industry, you can bet that every salesperson out there is going to scramble to find a way to say that his product is an implementation of that buzzword . Client/server is no exception to the rule of buzzwords .
Page 1251
The host/terminal architecture dominated the industry for a number of years , and its use continues today; however, it has run into some limitations. Some argue that the big host computer vendors became a little lazy and stopped turning out new equipment at a rapid pace. Others argue that as the processing load continued to grow, it became impossible to build computer processors powerful enough to keep up with the demand. Still others argue that the large computer vendors never produced enough units to keep the cost per unit down.
Whichever reason you prefer (or even if you prefer to think that it is a little bit of all these reasons), the client/server architecture has grown over the last decade to become a very popular alternative to the traditional host/terminal world. Oh, a lot of shops still do not consider anything other than mainframes, COBOL, and terminals; however, because you are reading this book, you probably are not in this group . Therefore, I'll cover client/server in a little more detail.
Forming a definition is a good start to this discussion. Because I am not much of a theorist, I will stick to a simple definition. I define client/server architectures as systems on which the computer processing load for a single application is distributed between multiple computers. In host/terminal computing, the terminal (or PC emulating a terminal) is responsible only for the presentation of the information. You can cite a number of examples that fit my definition that you might not want to call client/server, but it gives you the general idea. Figure 55.5 illustrates this general concept.
Figure 55.5.
Client/server
networking.
With a definition this broad, you could have a number of different distributions of labor that still qualify as client/server. Going back to my buzzword discussion, that is why you see a large number of vendors with widely different products and architectures all claiming to be client/server. I guess that is part of free enterprise. Figure 55.6 shows some sample distributions of labor that advertise themselves as client/server.
Page 1252
Figure 55.6.
Sample distributions of
labor in various
applications.
As you can see, there are a number of ways to split the application. Some of your choices in designing your architecture are limited by the tools you choose (or vice versa). You might want to split up your processing based on the relative capacity (or cost) of your standard server and client platforms. You also might find that your users' demands for graphics and response time influence your decisions. If you have a group of users who demand excellent GUIs and fast performance, for example, you could buy a moderately powerful server and some high-end PCs. Or, if you already have an overloaded but paid-for host computer and reasonably powerful PCs, you could extend the life span of the host by converting some of your applications to perform the database processing. You could perform some of the calculations on the host server and then perform the rest of the calculations on the client. Here are some general characteristics of most client/server environments to consider:
Page 1253
One final concept you might need to consider is the difference between two-tier and three- tier client/server architectures. When client/server was introduced, you had just two machines: the client and the server. The client typically performed the display functions, and the server did most of the calculation work and database management. People liked the display capabilities of the PC but found that neither the PCs nor the server had sufficient processing capacity to perform the complex calculations that might be necessary for detailed financial analysis or similar tasks . These users did not want to move up to the more expensive, larger computers (twice the processing capacity usually has much more than twice the price in the computer industry). Instead, developers came up with the idea of splitting the processing load for a given user and application among three computers. The client machine still performed the user interface work; however, the other work was split between a database server and an application server. The database server focused on running the DBMS, and the application server performed all the computations associated with the application. (See Figure 55.7.) The three-tier architecture is more complex to design and configure, but it can be the answer if you perform a lot of demanding computational work but do not want to invest in a single, large computer.
Figure 55.7.
Two-tier and three-tier
client/server architec-
tures.