More bad news for adopters of a two-tier architecture follows. In the fat client scenario, any change to the application logic (and you know that there will be changes) involves compiling and installing the changed code on all the clients an expensive proposition. In the thin client scenario, the enterprise usually relies on vendor-specific databases and the vendor s implementation of triggers and stored procedures. Typically, proprietary implementations of DBMS features are not portable to different platforms and usually will not work with different vendor products. Every strain of technology solves some old problems while introducing new ones. Two-tier architectures are certainly no exception; although applications developed with a two-tier architecture achieve some benefits by isolating tasks into separate tiers, the disadvantages of the architecture remain. A sensible question is: Are there ways of exploiting the advantages of these architectures while taking the sting out of their problems? N-tier Architectures in Brief Perhaps I can shed some light on a possible answer to the $64,000 question posed in the previous section by posing another question: What are the root causes of the deficiencies of the two-tier architectures? One cause is the architecture s failure to give the application logic layer its own tier. By trying to divvy up the functionality of the application logic layer, the resulting architecture ties applications to high-maintenance clients, proprietary and nonportable databases, and clogged networks. Why not give the application logic layer its very own tier? You don t have to be a rocket scientist to guess what the architecture is called when the presentation, application logic, and data layers have their own tier. The n in n-tier means that a particular layer (the application logic layer, really) may have more than one physical tier. Whether you re talking about three-tier (a specific case of the more general n-tier) or n-tier, the basic concepts are the same to encapsulate the application logic from the presentation and data layers. What does this buy you? With the computations, business logic code, and other application logic layer tasks isolated in one or more separate tiers, these tasks do not reside in the client, nor do they reside in the database. Put another way, n-tier architectures typically deploy thin clients and DBMSs devoid of application code. There are several paths to the road of three-tier architecture implementation. A popular implementation places the application logic layer on one or more application servers. These servers provide many essential services to a three- tier application, such as transaction management, resource pooling, and security. Rather than allow a fat client or stored procedure laden database to handle transactions (when to commit one or more transactions or when to rollback, for example), a three-tier architecture implementation delegates this vitally important function to the application server. Because business logic dictates what constitutes a transaction, support services dealing with transaction management belong on the application server because the business logic is implemented there. As previously mentioned, a shortcoming of two-tier architectures is the consumption of resources, such as database connections, even when such resources are not needed. A characteristic of two-tier architectures is that each client needs a connection to the databases. Three- or n-tier architecture implementations allow a client to request data from one or more databases by communicating with code in the application logic layer tier. This code can dynamically connect to a database to fetch and return the requested data to the client. Also, this code can queue the data request until a database connection becomes available, and then fetch and return the requested data to the client. Application servers both hardware and software are more secure than desktop client PCs. The hardware that houses the application server usually resides in a physically protected space. Rarely would you worry about stumbling over a power cord for the hardware that houses an application server! On the software side, most server software is built with security in mind unlike client desktop operating systems, such as Windows or Mac OS. Do three-tier architectures solve the problems of two-tier architectures cited above? For the most part, they do. The problems caused by fat clients simply do not apply to n-tier architectures. Thin clients are relatively inexpensive to install and maintain. Application changes will not have much of an impact on thin clients; the application servers take the brunt of the changes. Pulling application logic out of the DBMS by not using stored procedures places less reliance on proprietary stored procedure implementations. Three-tier implementations have a wider choice of DBMS products for use in the data
Please check java servlet web hosting services, here you will find professional-grade java servlet web hosting with the best prices.