XML

Connecting the Three Tiers

So far you've learned that by using Windows DNA, you can split your application's services into three parts: user services components, business services components, and data services components. Now you will learn how you can tie the three parts together. In Windows DNA, this is done by exposing system and application services through the Component Object Model (COM).

The foundation of Windows is COM, which has become COM+ in Microsoft Windows 2000. (COM as used here refers to both COM and COM+.) COM provides a way for applications to communicate with COM objects. COM also enables one object to communicate with another object through method calling and property setting. How a COM object actually performs its services is not important. Objects hide or encapsulate the details of how they work. Because an object hides how it performs its services, you can change the way an object performs its services without breaking the application that uses the object.

If the services components in each tier are COM components, the communication between tiers will be COM method calls. To be specific, your user services components will call the methods of the business services components to request services from the business services tier, and your business services components will call the methods of the data services components to ask for services from the data services tier.

Physical Three-Tier Model

The physical three-tier model includes the actual computers on which the components will be placed. There are three groups of computers: client tier, middle tier, and database tier. The client tier computers provide user services, consisting mainly of the user interfaces. The middle-tier computers provide business services, consisting of enforcement of business rules and data validations. The database tier computers provide data services, consisting of the data and the ways of accessing and maintaining the data.

Several years ago, the two-tier model, also called client server, was popular. This model consisted of a client tier that communicated with a database tier. This model required the client computer to maintain a continuous connection to the database. The database could keep track of what records were being edited and place locks on these records so that only one person could change a record at one time. Locks insured that the data would be consistent. The main drawback of this model was that the systems were not very scalable. Since developers wanted to build systems that could scale to hundreds and even thousands of users, they needed another solution.

The solution to making systems more scalable was to break the connection the client had with the database. Originally, the data was passed to the client computer where CRUD operations could be performed on the data. If the data was updated, this data could be sent back to the database. With this disconnected model, the database could no longer lock records because the client had no connection to the database. Thus, the database had no way to reconcile inconsistencies. An alternative to locking records was developed that allowed the client to communicate with an application located on the server that could make changes to the database. This application is the data services component we have been discussing in this section. Instead of running this application on the database tier, the middle tier was added to host the data services components.

The idea of a middle-tier computer had existed long before the use of a disconnected model. In non-Windows operating systems, applications were commonly placed on a central server and used by many clients. These clients often had little functionality and were called dumb terminals. The middle-tier computer can still be used to host components, such as the business or data services components that can be used by multiple clients, but now modern clients are usually fully functioning and have many applications running on them.

Before we look at how to place components created in the logical model onto the computers in the physical model, which we'll do in the section "Locating Logical Components" later in this chapter, we must first examine the component state.