What is N-Tier Architecture?

Introduction

This is the first in a series of articles exploring the world of n-tier architecture in terms of the Microsoft .NET platform and associated framework. 

The first of these is meant as an introduction to n-tier architecture and as such tries to explain the reasoning behind developing applications in this way, and how it can be achieved without going into complex implementation details. That will come later. I suppose that by even mentioning n-tier in my opening sentence I've jumped the gun somewhat so let me backtrack slightly and explain. 

The first question to ask is if this is just a new fad or fashion. After all, we've been through several iterations of various architectures all of which have failed at some level. Well, maybe! Modern architectural development techniques evolve and are based on our latest failures. This is a good thing. It shows that we are learning from our mistakes. Sure we have had a few setbacks (like the thin client episode), but in general everything exists for a reason and has developed from decades of hit-and-miss projects. 

So how often have you implemented a new system and had a nagging doubt in your mind whether it would stand the test of time? - the main question being: "What if my system is spectacularly successful? Will it become a victim of its own success, or will I be lucky?" 

For the last few years, system architects have been touting splitting a system into tiers. Unfortunately, many companies have yet to embrace it, fearing that they will overcomplicate their systems, increase maintenance costs (after all, if a system is in several places, it must be more expensive to run) and push up salaries because they have to hire more qualified staff. 

Let me get something straight. In the first place you should never initiate a new systems development project without a good business case. This usually boils down to the fact that the system you implement will help your company make even more money. If you can't justify it in those terms, dump the project. Therefore, I can guarantee that n-tier systems will save you money in the short- to medium-term in hardware, software development and software maintenance costs. 

In the next few articles I will show you how. 

N-Tier Explained

For those who haven't read (or quite understood) the hundreds of other articles on multi-tier development, here is a quick reminder. It is perhaps useful to go through the various stages that we, as software developers, have been through in order to give us some perspective on what is actually possible today. 

Single Tier

When automation first hit business, it was in the form of a huge "Mainframe" computer. Here, a central computer served the whole business community and was accessed via dumb terminals. All processing took place on a single computer - and therefore in one place. All resources associated with the computer (tape and disk drives, printers etc.) were attached to this same computer. This is single tier (or 1-tier) computing. It is simple, efficient, uncomplicated, but terribly expensive to run. 

Figure 1 - Single Tier Architecture

Figure 1 shows a physical layout of a single tier environment. All users run their programs from a single machine. The ease with which deployment and even development occurs makes this model very attractive. The cost of the central machine makes this architecture prohibitive for most companies, especially as system costs and return on investment (ROI) are looked at carefully nowadays. 

Dual Tier Environments

In the 1980s, a revolution happened in the world of business computing: the Personal Computer (nearly unimaginable until then) hit the streets. The PC quickly became the standard equipment on desks around the world. The demand for personal software was also in demand and, with the advent of Windows 3.0, this demand became a roar. 

In order to provide personal software which ran on personal computers, a model needed to be found where the enterprise could still share data. This became known as the client/server model. The client (on the personal computer) would connect to a central computer (server) and request data. With limited network bandwidth, this would offload the need for expensive infrastructure since only data would be transmitted, not the huge graphics necessary to make a windows application display. In Figure 2, we see the very model implemented in most organizations today. This model is also quite easy to implement. All you need is an RDBMS, such as MS-SQL Server 2000, running on Windows 2000 Server and a PC running TCP/IP. You application connects to the database server and requests data. The server just returns the data requested. 

Figure 2 - Client Server Physical Model

There are, however, several problems with this model: 

1. The connections are expensive - they take a long time to establish and require a lot of RAM on the server. Because the fact of connecting is slow, most applications connect when launching the client application and disconnect when the application is shut down. Of course, if the application crashes, then the connection is left open on the server and resources are lost.
2. One can only connect a limited number of users to a server before SQL server spends more time managing connections than processing requests. Even if you are willing to increase server resources exponentially, as your user base grows (get your corporate wallet out) there still comes a time when your server will choke. This can be solved in part by splitting the database in two or three and replicating the data. This is definitely NOT recommended as replication conflicts can occur. The more users you connect, the more errors you're likely to get.
3. This method is so cost-ineffective. Many users only use their connection 2-3% of the time. The rest of the time it is just sitting there hogging memory resources. This particular problem is usually resolved artificially, by using a TP monitor such as Tuxedo which pools and manages the connections in order to provide client/server for the masses. TP monitors are quite expensive and sometimes require their own hardware platform to run efficiently.

Figure 3 puts the above into context and shows the logical system components - most of which are on the client. 

Figure 3 - Logical View of a 2-Tier Architecture

The Alternatives

With the advent of the Internet, many people jumped to the conclusion that the days of the mainframe were back. Client/Server had obviously failed, personal computers had failed and, above all, Windows was on its way out. A host of "thin client" applications were developed usually by overzealous IT managers hoping to wrest computing control back from the users. TCO - Total Cost of Ownership was the watchword of the day and everyone was consumed by downsizing the client. Thus 3-tier applications were born. These applications run the traditional client/server model but from a web server. 

Figure 4 - 3-Tier Thin Client Architecture

The client only displays the user interface and data, but has no part in producing the results. Figure 4 shows the physical representation of such architecture, whilst Figure 5 gives a logical view. 

This architecture presents one advantage over the former: a well implemented web server can manage and pool database connections as well as running the applications. The disadvantage is that the web server is quickly overwhelmed by requests and must either be clustered or upgraded. 

Figure 5 - Logical 3-Tier View

Did you also notice that the software model has not significantly changed over the 2-tier model? We have merely moved the 2-tier client processing onto the web server. Also the thin client user interfaces, by their very nature, are not as rich as their Windows counterparts. Therefore, applications developed using this model tend to be inferior to their Windows counterparts. 

The clue in really making an application scalable, as you may have guessed, is to split up the processing (in the red boxes) between different physical entities. The more we can split it up, the more scalable our application will be. 

"Isn't this expensive?" I hear you cry? I need a different server for each layer. The more layers, the more machines we will need to run. Well, this is true if you have thousands of users accessing your system continuously, but if you don't, you can run several layers on the same machine. Also, purchasing many lower-spec servers is more cost-effective than one high-spec server. 

Let's explore the various layers we can create, starting from the logical model in Figure 5 

Overview of an N-Tier System

The Data Layer

The data layer can usually be split into two separate layers. The first will consist of the set of stored procedures implemented directly within the database. These stored procedures will run on the server and provide basic data only. Not only are they pre-compiled and pre-optimized, but they can also be tested separately and, in the case of SQL Server 2000, run within the Query Analyzer to make sure that there are no unnecessary table scans. Keep them as simple as possible and don't use cursors or transactions. Cursors are slow because processing rows one by one instead of as a set is inefficient. Transactions will be handled by the layer above, as ADO.NET gives us much more control over these things. 

Figure 6 - N-Tier Logical Model

The next layer consists of a set of classes which call and handle the stored procedures. You will need one class per group of stored procedures which will handle all Select, Insert, Update, and Delete operations on the database. Each class should follow OO design rules and be the result of a single abstraction - in other words handle a single table or set of related tables. These classes will handle all requests to or from the actual database and provide a shield to your application data. All requests must pass through this layer and all concurrency issues can and must be handled here. In this way you can make sure that data integrity is maintained and that no other source can modify your data in any way. 

If your database changes for any reason, you can easily modify your data layer to handle them without affecting any other layers. This considerably simplifies maintenance. 

Business Rule Layer

This layer is implemented in order to encapsulate your business rules. If you have followed best practices, you will have created a set of documents which describe your business. In the best of cases, you will have a set of use-cases describing your business in precise detail. From this you will have been able to create a class association diagram which will help you create your business layer. 

Here we find classes which implement your business functionality. They neither access data (except through the data layer) nor do they bother with the display or presentation of this data to the user. All we are interested in at this point are the complexities of the business itself. By isolating this functionality, we are able to concentrate on the guts of our system without the worry of design, workflow, or database access and related concurrency problems. If the business changes, only the business layer is affected, again considerably simplifying future maintenance and/or enhancements. 

In more complex cases it is entirely possible to have several business layers, each refining the layer beneath, but that depends on the requirements of your system. 

Workflow Layer

This is one of the optional layers and deals with data flow to and from your system. It may or may not interact directly with the user interface, but always deals with external data sources. 

For instance, if you send or receive messages from a messaging queue, use a web service for extra information, send or receive information to another system, the code to handle this would be in this layer. You may wish to wrap your whole application in XML so that the choice of presentation layer can be expanded. This would also be handled in the Workflow Layer. 

Presentation Layer

This layer handles everything to do with the presentation of your system. This does not just include your windows or web forms (or your user interface), but also all the classes which will help you present your data. 

Ideally, your event method implementations within your form classes will only contain calls to your presentation layer classes. The web or windows forms, used for visual representation only interface seamlessly with the presentation layer classes which handle all translation between the business layer/workflow layer and the forms themselves. This means that any changes on a visual front can be implemented easily and cheaply. 

Bottom Line

Can you see the pattern? Each section (or layer) of your application is a standalone entity which can communicate with layers above and below it. Each layer is designed independently and protected from the others by creating extensible interfaces. All changes can therefore be encapsulated within the layer and, if not major, will not necessarily affect layers above and below it. 

So how have we managed for so long with the 2-tier client/server model? Well, we haven't really managed at all. We've shoe-horned applications into architectures instead of architecting solutions in order to provide perfect fit. Why? Because solutions involving any degree of distribution were difficult to implement cost-effectively - that is until now. 

Although the exact implementation can vary in terms of the .NET Framework in that you have the choice of using Web Services, Enterprise Serviced Components, and HTTP or TCP/IP Remoting, the fact remains that we now have all the tools necessary to implement the above. If you are using or thinking of using the .NET platform and framework, you would be well advised to architect in several tiers. 

In the next article I will show you how to do just that.

About the author

Karim Hyatt is an application development architect and consultant, based in Luxembourg with over 20 years experience in the business. 

He started developing Windows applications with a special release of Windows 2.0 and quickly moved on to version 3 SDK. Having been through several iterations of learning new APIs and Frameworks such as MFC and ATL, .he decided to get on board with .NET in the early days of the beta 1 release.