 | MySQL & mSQL |  |
We have so far discussed the most common architecture for web and simple business application processing, client/server. This architecture, however, has a hard time growing as your computing needs grow and change. It also does a poor job of taking advantage of the benefits of object-oriented programming. The first problem has been recently echoed throughout the industry in the discussion of thin clients. The desire for thin clients derives from the troublesome trend of throwing more and more processing onto the client. The poster children of this problem are PowerBuilder and VisualBasic, tools that pool data directly from a database into a GUI and then perform all operations on that data in the GUI.
Such a tight coupling of the user interface to the database engine results in applications that are difficult to modify and impossible to scale with growing user and data volume. If you have any experience with user interface design, you have experienced the fact that user interfaces are subject to changes based on user whims. The easiest way to isolate the impact of these changes would be to leave the job of the GUI to act only as a user interface. Such a user interface is a true thin client.
The impact on scalability comes from the other direction. Namely, when you need to modify an application to scale according to user demand or data volume, the modifications might come in the form of database changes including, but not limited to, distributing the database across multiple servers. By marrying your user interface to the database, you necessitate a change in that GUI in order to support scalability issues -- issues that are purely server-related.
Thin clients are not today's only computing rage. Another trend is code reuse. Common code among applications tends to reside in data processing, commonly called business rules. With all of your business rules sitting in your user interface, you will find it difficult at best to attain any kind of code reuse. The answer to these problems lies in breaking an application into three pieces instead of two. This architecture is called the three-tier architecture.
NOTE
When we speak of a user interface occurring on the client, we mean that as a logical distinction. A form of thin client, sometimes referred to as the "ultra-thin client." is what everyone commonly recognizes as a web page. A web page may be dynamically generated on a web server. In that case, the most client processing is occurring on the web server in the form of dynamic HTML page generation.
Contrast the two-tier architecture from Figure 8-1 with the three-tier architecture shown in Figure 8-1. With this design, we have added an intermediary layer between the user interface and database. This new layer, the application server, encapsulates the application processing logic -- the business logic -- that is common to the problem domain. The client becomes nothing more than a view of the middle-tier business objects and the database becomes nothing more than a storage mechanism for those objects. The most important advantage you gain is thus the separation of the user interface from the database. Suddenly, you do not have to build knowledge of the database into the GUI. Instead, all knowledge of how to deal with the database can sit in the middle tier.
The two main functions of the application server are to isolate database connectivity and provide a centralized repository for business logic. The user interface handles only display and input issues and the database engine handles only database issues. With data processing moved to a centralized location, multiple user interfaces can use the exact same application server program -- no more writing the data processing rules each time you build an application.
|  | |
| 8.3. Object/Relational Modeling |  | 9. CGI Programming |
Copyright © 2001 O'Reilly & Associates. All rights reserved.