ClientServer and N -Tier Architectures

I l @ ve RuBoard

Client/Server and N - Tier Architectures

Distributed applications have come about through evolution rather than a revolution, albeit with occasional sudden leaps as new technology has become available. From the first hesitant decoupling of the desktop from the database server over a low-bandwidth network to the current situation in which the Internet predominates, the basic goal has remained the same ”to access and process shared data in a timely and secure manner.

Two-Tier Architecture

The classic two-tier architecture is what many developers mean by client/server , although if you put two developers in a room and ask them for a definition of client/server, you'll most likely end up with three opinions .

Here's how we define the terms client and server :

• A client is a process that requests a service (such as access to a database).

• A server is a process (such as a database server) that provides a service.

Notice that these definitions are process-oriented . It is perfectly feasible for both the client process and the server process to be located on the same machine, although in many cases they will be distributed ”that's the more common case, especially when a single server is handling requests from multiple clients . The usual example of this sort of architecture is the database management system (DBMS). Figure 1-1 depicts a typical database client/server system.

In this case, the services being provided are requests to retrieve data and requests to create, modify, or remove items from the database. The client application and the server communicate using an agreed-upon mechanism ”for example, structured query language (SQL) over a common network protocol. The server interprets the SQL statement, processes it, and sends an appropriate response back to the client. If the server is serving multiple clients simultaneously (using multiple threads), it might need to ensure that concurrent requests do not conflict. For example, two clients might attempt to update the same data at the same time; the server should reschedule one client, making it wait until the other has performed its work and released the necessary resources.

Figure 1-1. A database client/server system

All of this is transparent to the client, in theory. In practice, however, a client might notice the delays that occur while the server tries to work its way through the competing client requests. The database design, application code, and other tuning issues become paramount in ensuring that the system scales well.

Further complications can arise when a designer realizes that a server can also be a client, and vice-versa; in order to perform its service, a server might need to request services from other servers, which in turn might use further servers, and so on. In a distributed database (depicted in Figure 1-2), the DBMS might be configured to forward requests to access data in a particular table to another DBMS (using a linked SQL Server, for example).

Note

One could conceivably end up in a situation in which the DBMS that is contacted directly by a client simply becomes a channel through which all requests for data are passed to one or more other DBMSs. The original DBMS will still perform a useful service and can enforce various security and integrity checks as the client requests or updates data, but it's not being very DBMS-like anymore.

Figure 1-2. A distributed database (SQL Server)

N -Tier Architecture

N -tier systems (where n is 3 or more) require careful design and even more careful implementation. It is usual, but not mandatory, for each tier to contain components that perform well-defined roles. Different organizations give different names to each tier, reflecting the responsibilities of each tier. Examples of tiers from the Microsoft world include the User Services Tier, the Business Services Tier, and the Data Services Tier. The User Services Tier contains the presentation logic used for displaying data and gathering user input, the Business Services Tier contains the business rules and associated logic, and the Data Services Tier contains the components needed to manage persistent storage, usually using a DBMS.

Figure 1-3 depicts an example of a three-tier architecture.

Figure 1-3. A three-tier architecture

This all sounds simple. But in practice, things can become very complicated very quickly, and there's a lot of room for developers to have deep and meaningful debates about the following issues:

• What code should actually go into each tier?

• How should components in one tier communicate with components in another tier?

To answer these questions, you should take a step back and consider the issues that led to the development of this architecture in the first place. For example

• What type, or types, of client will your system have to support: a GUI desktop application, an HTML browser, a batch application that requests and processes data but has no interactive user interface?

• Where is the data held, and in what format? Is there more than one data store?

• What are the data integrity requirements of the system? Where is the integrity of data checked? How do the business rules change over time?

You should also bear in mind that the tiers that result from partitioning a system in this manner are logical rather than physical. Na ve developers have been known to mistakenly assume that a three-tier architecture implies three separate computers: one for the desktop, another running the business components, and a third holding the database. This is not always so. Often, part of the business logic is located on the user's physical machine, some of the data storage logic might be located on the machine implementing the business rules, and the implementation of the business rules might be spread across several computers.

The choice of what components should go where is all part of the design. Many patterns have been proposed for automating some of the decisions developers have to make. (See http://www.theserverside.com/patterns/index.jspfor useful examples relating to distributed Java applications. They are based on Java 2 Enterprise Edition but can be adapted to .NET.) But by and large, you still have to understand the nature of the system being built in order to make the best choices and design a good structure.

The Northwind Traders Example

Consider an implementation of the Northwind Traders system ”the sample database you're familiar with if you've spent any time using Microsoft SQL Server, Microsoft Access, Microsoft Visual Basic, or many other Microsoft applications. Northwind Traders is a fictitious organization that sells exotic edible goods. The Northwind database contains information about the goods that customers can order, information about the orders themselves , and the names and addresses of all the customers. Northwind Traders does not manufacture the goods; it orders them from suppliers as stock levels demand. Orders are sent to customers using a designated shipping company, depending on the location of the customer. Northwind Traders also maintains information about its employees and assigns each employee a target territory; the employee is responsible for maintaining and growing the customer accounts in the specified territory. Each territory belongs to a region. Figure 1-4 shows the schema for the Northwind database. The physical diagram of the database is shown in Figure 1-5.

Figure 1-4. The Northwind Traders database schema

Figure 1-5. A physical diagram of the Northwind Traders database schema

Application Requirements

Here is a description of the requirements for the Northwind Traders system, as elicited by the user representative temporarily assigned to the development team building the system:

The Northwind Traders system must support several kinds of users, including customers who want to order goods and track their orders, employees who need access to customer and product information, clerks who dispatch orders and maintain inventory levels in the warehouse, and accountants who need to ascertain whether the company is making a profit. Customers will access the system using the Web and a browser. Employees, clerks, and accountants might use an internal desktop system or possibly an intranet. Part of the clerks' role in interacting with external agencies (suppliers and shippers) can be automated using a business-to-business (B2B) solution and the Internet. And further enhancements might be added in the future.

This list is complex but is by no means an atypical set of requirements. It would be easy to start throwing together pieces of code and components that support selected parts of the functionality, but unless you understand the bigger picture ”how the system might need to collaborate with other systems ”and can predict reasonably accurately any future needs, such an approach is unlikely to be successful.

Design Patterns

Fortunately, designers and developers tend to be pretty open about solutions they've discovered . There are few unique puzzles in the realm of distributed system design, and many common design patterns are publicly available, each designed to solve a particular problem in a defined context. The designer's job has become a matter of recognizing the problem and the context and then applying the appropriate pattern.

Perhaps the most famous design patterns are those published by the "Gang of Four" ”Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides ”in Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995). The 23 patterns in this book have passed into software folklore, and I won't repeat them all here. Other organizations have also proposed and published patterns, some of which are specializations of the original 23 (to target Web-based applications, for example). However, here are the keys to designing components in a flexible architecture that supports a dynamic distributed system:

• Use interfaces to decouple the functionality from the implementation.

• Hide as much detail as possible. The less you expose, the less you risk having to change "consuming code" if your component is modified in the future.

• Use generic interfaces that can be implemented by a range of components; don't define a business component that expects the GUI consumer to be a desktop application because you might end up having to rewrite the component (for example, if the consumer changes to a Web browser).

Any platform or toolset that you use to implement a distributed system using a patterns-based approach must provide support for these goals.

I l @ ve RuBoard