By Mildred Moy British Columbia Systems Corp. The trend of business process reengineering has generated the need to improve communications, reduce overhead, enhance work-process efficiencies and facilitate information sharing across departmental and organizational boundaries. As a result, information technology is faced with a new set of application requirements and pressures toward distributed computing*.
New Business Requirements Recent government initiatives to expedite the purchase ordering process, improve inventory control and deliver better services to the public have created demands for applications that would link up the government agencies to their vendors, partners and customers. These types of business systems have to be scalable* to accommodate a large and growing number of users (in the range of hundreds or thousands). In addition, not only is multi-platform support essential, these applications also have to be adaptable to emerging client operating systems (e.g., Taligent). Finally, considerations have to be made for dial-up (or remote) users.
Current Approach to Application Design Today's most popular approach to application design cannot meet the aforementioned business needs. Most of the commonly used client/server* development tools allow only client-side processing. In most organizations, client/server applications are developed using one of these tools in addition to a SQL* database server that supports stored procedures. (A stored procedure is written in a vendor-specific SQL dialect. It resides in a database for processing data requests sent from clients.) Applications created using this approach generally have a two-tier architecture. The first tier is a single process running on the user machine. It consists of the presentation and application* layers bundled together to form one executable*, generated by the client/server development software. The second tier is the database server with stored procedures residing in it. (see: Fig. 1) This type of application architecture performs well in single-vendor/single-database environments with fewer than 100 users. Each user connection takes up some resources on the database server. As the number of users increases, the single database server will sooner or later run out of resources. More database servers will be required to accommodate the growing install base. One way to solve the problem is with a two-tier model and database replication. By replicating data on one server to another server, the number of users supported can be doubled. Data replication, however, is only suited for certain types of applications - those with a low chance of simultaneous record updates. In other words, when it is unlikely that two or more users will be updating the same record at the same time, data replication could be an appropriate approach to solving the scalability problem. However, for those applications with a high volume of transactions and with potentially hundreds or thousands of users, one may wish to find an alternative solution.
A Three-Tier, Thin-Client Architecture In a three-tier architecture*, the first tier is the client process which consists of the presentation logic. Unlike a two-tier model, it may or may not contain the application logic. The second tier is an object server that holds part or all of the application logic. It also serves as a router* that transmits user requests to the database (and other object servers for distributed processing). Finally, the database forms the third tier. (see: Fig. 2) For a large-scale application, a three-tier design is more desirable. As mentioned above, every single user in a two-tier model has to maintain a connection with the database. Resources (on the database server) will soon be exhausted as the number of users continues to grow. In a three-tier model, on the other hand, only one connection has to be maintained between the object server and the database. All data requests (from the clients) will be routed through the object server (which acts as a request broker). In this scenario, the system can be scaled to accommodate more users simply by adding more object servers. The "thin" client approach is a special case of the three-tier architecture. When the client (the first tier) does not contain any application code*, we call it "thin". A thin client contains modules to create user interfaces (U.I.) for the particular operating system it is running under. For example, a Macintosh client has Mac-specific U.I. modules, and a Windows client has Windows-specific U.I. modules. User interfaces generated by these modules can perform field type-checking and compute calculated fields (that have values dependent on the values of other fields, e.g., Field A = Field B + Field C). A thin client also means a "generic" client as it only contains code that can be used by any application. All application logic resides on the object server which, in response to user requests, gives instructions to the client (by sending messages) on how the screen should look, how the fields should be defined and what values should populate the fields. As a result, unlike a "fat" client (which bundles application and presentation logic into a single executable), a thin client can run different applications without a single change on the user workstation. All that have to be modified are the instructions sent down to the client from the server. The thin-client architecture can better manage remote users and help save significant application administration costs. In an environment where there are lots of remote users, distributing new applications or version upgrades can be quite time-consuming and costly. Under the two-tier model, the new code has to be downloaded or installed onto every single client machine. With the thin-client approach, fortunately, no change is necessary on the user workstations. Moreover, the thin-client design helps to insulate your application development investment from future operating system changes (on the client side). This benefit is attributed to two factors. First, the application modules are processed on the object server. Second, the instructions sent to the client are platform-independent As a result, a user who wishes to switch from a Macintosh to a Windows machine, for example, can do so without any change to the application (which resides on the object server). Under a three-tier, thin-client architecture - in order to ensure reasonable performance, system modularity and ease of maintenance - an application should be made up of many small transactions. CPU*-intensive transactions should be routed to more powerful object-server machines. An object server has the capability to send requests to databases as well as other object servers. As a consequence, with careful initial design, future growth in transaction volume can be handled incrementally by adding additional object servers. In order to build a system with a three-tier, thin-client architecture, information technology. managers have to look for client/server development tool sets that have two components: * A thin client for each user platform of interest * An object server which acts as a request broker - for routing requests to the appropriate server(s) and sending back instructions to the client. These tools are already available in the industry today.
