Tier Architecture is how different processing work is physically and logically distributed across a computer system and network. This is where developers cross with networks.
Processing work may be categorized into three logical services:
- Presentation Services. The user interface including, the visual appearance of output and how user input is handled. When developing the GUI (Graphic User Interface), take the following into account:
- The user is number one.
- Consider the frequency that certain forms are used and how they are used.
- Review prototypes of the GUI with the users.
- Stick with standard conventions, such as having an Open command under the File pull down menu.
- Business Services. Business rules and logic. EG: If I start an order, then I will be asked for shipping info. When developing business services, take the following into account:
- Try to keep these rules separate from other parts of the program since these rules are apt to change.
- Try to have each rule implemented in the program once (in a separate module) so that if it does change, you only have one place to change it.
- You may want to enclose these components in transactions with something like MTS (Microsoft Transaction Server).
- You may want to make these components execute in an asynchronous (in any order and at any time) fashion with queuing.
- Data Services. Data relationships, efficiency of storage, and data integrity.
A one-tier implementation is self-contained. It combines presentation, business, and data services. EG:
- A stand alone PC running Microsoft Access.
- A mainframe with attached one or more dummy terminals. A dummy terminal is just a physical point of contact with the mainframe.
Fat Client. The client has its presentation and business services. The server has the data services. Most business applications during the client-server age were of this type. This implementation may generate more network traffic. EG:
An application written in Visual Basic might have do all its work at the client, while getting data from the database server.
Thin Client. The client has the presentation services. The server has the business and data services. This implementation started gaining popularity toward the end of the client-server age. This implementation may generate less network traffic but may have to be developed in language proprietary for the server. EG:
The server does all sorts of work and returns the results to the client. An application activates stored procedures and triggers written in Transact-SQL on a Microsoft SQL server.
Two-tier implementations may be somewhere in between fat and thin clients.
A logical three-tier implementation may use only two machines, like a two-tier implementation. The difference is that on the server the business services would run in a separate process from the data services. As such a system grows, it could move the business services to a separate server to make it a true three-tier implementation.An n-tier implementation has a client with presentation services, and a number of other servers asynchronously handling business and data services. This is scalable and good for accessing multiple database. An n-tier implementation may also perform services that are part business and part data. EG: transaction servers like MTS (Microsoft Transaction Server) keep track of complex, multi-part tasks.
A Web-tier implementation has a client that accesses a web server that at least handles presentation services. The web server may have its own business and data services or it may utilize one or more servers that handle business and data services. A Web browser is like a dummy terminal in that most of the work is done elsewhere. EGs:
- A browser accesses a page that includes an application written in script. This is similar to a Fat Client. The next samples are like Thin Clients.
- A browser accesses a page that activates a CGI (Computer Gateway Interface).
- A browser accesses pages that utilize IDC (Intenet Database Connector).
- A browser accesses ASPs (Active Server Pages) on an IIS (Internet Information Server).
The main factor is whether centralized or distributed work will work better.
- Make it is easier to work on common code.
- Share common resources.
- Fat clients, especially stored procedures, can be have high speed and reduce network traffic
- Make it easier to work on little modular chunks of code.
- Perform simultaneous and aggregated processing.
- Respond more quickly local needs.
- Have better scalability.
- Distribute workload amongst several servers.