A three-tier (or n-tier) application is when the application components are spread out over three or more computers and there is a high degree of separation between the user interface, business logic and data access, and the data components. If there is no degree of separation, you are bound to have a failed application when it is time to perform maintenance. This separation is referred to as a loosely coupled design.

Three-Tier-Architecture

that the center node is called the Application Server and that it hosts, in the logical design, only the business logic components. In any application, the application is the part of the system that controls the application’s logic. The database is just a place to store the data and the user interface is just the means to get that data there, but the business logic contains all of the functionality for dealing with data. As you start writing this application, you will see that the business logic is the most important component of any application.

Usually it is when there are only going to be a small number of users who will ever use the application. When I say small number, I mean about 100 or fewer users. Another time to use two-tier architecture is when other applications will not need to access the functionality provided by the two-tier application. Take for instance an application that performs some function that is only needed in this one instance—you probably will not need to worry about incorporating this functionality into other applications. Because the functionality does not need to be reused, there is no point in creating a reusable component.

When multiple users try to update a single record at the same time, you will have concurrency issues. In a single-tier application, this is never an issue because there is only one user accessing data. In a two-tier system, you as the developer have the option of implementing either pessimistic or optimistic locking—however, this depends on the Relational Database Management System (RDBMS) because not all databases support optimistic locking. In most two-tier applications, you are always connected to the database when you are reading and writing data. If you set up pessimistic concurrency, when one user is trying to update a record, no other user can update the record at the same time (they will receive an error message explaining that the record is locked). If you implement optimistic concurrency, you will have to write code to handle the occurrence of one user updating a record that is not current. In a three-tier application, the developer must always handle database updates because no connection is maintained with the database. In most cases, this applies to a well-written two-tier application as well.

Microsoft’s new database access technology, ADO.NET, can help to make many of these issues easier to solve—but even ADO.NET will only throw an exception saying that someone else has updated the record. It is still up to the developer to handle this situation, and it is rarely solved the same way on any two applications. How you handle this situation depends mostly on what the users want.

The two-tier architecture is the most predominate architecture in corporate America. Although the Internet is slowly changing this model, do not be fooled into thinking an Internet application is not also a two-tier architecture—it depends on how it is written. Simply put, a two-tier architecture is one where the application runs on the user’s machine and the data is stored in a central location on a network

Two-Tier-Architecture

By its very nature, a two-tier application is not scalable beyond a certain point. There are several reasons for this. One reason is the number of connections a database can maintain concurrently. Imagine that one million users try to access the database at the same time…need I say more? There is no way to effectively manage the connections to the database when the connections are being created on the user’s machine (as opposed to being able to pool database connections). Another reason why a two-tier application is not scalable beyond a certain point is application functionality in relationship to the business process that the application supports. Take a situation where a business process changes and the program has to be altered. The company may have to roll the upgraded application out to 30,000 users, which is usually too cost prohibitive to do. Scalability does not have to just reflect whether an application can support a growing number of users but also how expensive it is to support them.

Then there is the concurrency issue; that is, what happens when two or more users try to access the same record in the same database at the same time to make changes to it? Usually one or more users are blocked from making changes, which can cause the application to temporarily hang. In a two-tier application, this can be both a positive and a negative aspect of the application. The positive aspect is that one user cannot alter a record that another user is modifying. The negative aspect is that it can cause the second user’s query to wait if there is a lock on the record they want to read. If the application is programmed correctly, the lock should not last for more than a few milliseconds, but on some database platforms, if the user who placed the lock is prematurely disconnected from the database, the result is a lock that cannot be removed except by the database administrator or by the database after a certain period of time. This has the potential to cause numerous problems. This particular issue is never a problem with a three-tier application, but other, more complicated issues appear with regard to this aspect of the database.

Multitasking is the ability of an operating system to run multiple programs concurrently. Basically, the operating system uses a hardware clock to allocate “time slices” for each currently running process. If the time slices are small enough—and the machine is not overloaded with too many programs trying to do something—it appears to a user as if all the programs are running simultaneously.

Multitasking is nothing new. On large mainframe computers, multitasking is a given. These mainframes often have hundreds of terminals attached to them, and each terminal user should get the impression that he or she has exclusive access to the whole machine. In addition, mainframe operating systems often allow users to “submit jobs to the background,” where they are then carried out by the machine while the user can work on something else.

Multitasking on personal computers has taken much longer to become a reality. But we now often seem to take PC multitasking for granted. As I’ll discuss shortly, to some extent the earlier 16-bit versions of Microsoft Windows supported multitasking but in a somewhat limited capability. The 32-bit versions of Windows all support both true multitasking and—as an extra bonus—multithreading.

Multithreading is the ability for a program to multitask within itself. The program can split itself into separate “threads” of execution that also seem to run concurrently. This concept might at first seem barely useful, but it turns out that programs can use multithreading to perform lengthy jobs in the background without requiring the user to take an extended break away from their machines. Of course, sometimes this may not be desired: an excuse to take a journey to the watercooler or refrigerator is often welcome! But the user should always be able to do something on the machine, even when it’s busy doing something else.

A simple rule is, “Always use `0′ or `NULL’ for null pointers, and always cast them when they are used as arguments in function calls.”

The fact that null pointers are represented both in source code, and internally to most machines, as zero invites unwarranted assumptions.  The use of a  preprocessor macro (NULL) suggests that the value might change later, or on some weird machine.

A “null pointer” is a language concept whose particular internal value does not matter.  A null pointer is requested in source code with the character “0″.   “NULL” is a preprocessor macro, which is always #defined as 0 (or (void *)0).

A constant 0 in a pointer context is converted into a null pointer at compile time.  A “pointer context” is an initialization, assignment, or comparison with one side a variable or expression of pointer type, and (in ANSI standard C) a function argument which has a prototype in scope declaring a certain parameter as being of pointer type.  In other contexts (function arguments without prototypes, or in the variable part of variadic function calls) a constant 0 with an appropriate explicit cast is required.

When Microsoft introduced Windows 1.0 in 1985, it was the most sophisticated solution yet devised to go beyond the limitations of DOS. Back then, Windows ran in real mode, but even so, it was able to move memory blocks around in physical memory—a prerequisite for multitasking—in a way that was not quite transparent to applications but almost tolerable.

Multitasking makes a lot more sense in a graphical windowing environment than it does in a command-line single-user operating system. For example, in classical command-line UNIX, it is possible to execute programs off the command line so that they run in the background. However, any display output from the program must be redirected to a file or the output will get mixed up with whatever else the user is doing.

A windowing environment allows multiple programs to run together on the same screen. Switching back and forth becomes trivial, and it is also possible to quickly move data from one program to another; for example, to imbed a picture created in a drawing program into a text file maintained by a word processing program. Data transfer has been supported in various ways under Windows, first with the clipboard, later through Dynamic Data Exchange (DDE), and now through Object Linking and Embedding (OLE).

Yet the multitasking implemented in the early versions of Windows was not the traditional preemptive time-slicing found in multiuser operating systems. Those operating systems use a system clock to periodically interrupt one task and restart another. The 16-bit versions of Windows supported something called “nonpreemptive multitasking.” This type of multitasking is made possible because of the message-based architecture of Windows. In the general case, a Windows program sits dormant in memory until it receives a message. These messages are often the direct or indirect result of user input through the keyboard or mouse. After processing the message, the program returns control back to Windows.

The 16-bit versions of Windows did not arbitrarily switch control from one Windows program to another based on a timer tick. Instead, any task switching took place when a program had finished processing a message and had returned control to Windows. This nonpreemptive multitasking is also called “cooperative multitasking” because it requires some cooperation on the part of applications. One Windows program could tie up the whole system if it took a long time processing a message.

Although nonpreemptive multitasking was the general rule in 16-bit Windows, some forms of preemptive multitasking were also present. Windows used preemptive multitasking for running DOS programs and also allowed dynamic-link libraries to receive hardware timer interrupts for multimedia purposes.

The 16-bit Windows included several features to help programmers solve—or at least cope with—the limitations of nonpreemptive multitasking. The most notorious is, of course, the hourglass mouse cursor. This is not a solution, of course, but just a way of letting the user know that a program is busy working on a lengthy job and the system will be otherwise unusable for a little awhile. Another partial solution is the Windows timer, which allows a program to receive a message and do some work at periodic intervals. The timer is often used for clock applications and animation.