Building Three-Tier Client-Server Business Solutions
March 1995

Overview

Multitier architecture offers a compelling way to develop client-server business solutions. It is technology-neutral and can be implemented on any vendor’s technology that enables standard interfaces for each of the logical levels called “tiers.” With an emphasis on clean interfaces between tiers, the implementation details are hidden from users. The functionality of each tier, called “components,” can be written in many different languages and maintained independently. This capacity allows the developer to use many tools from his or her toolbox to get the job done quickly and correctly. Just as you wouldn’t expect a carpenter to have only a hammer, a developer will not have only a single development tool.

Introduction

A client-server business solution is usually defined as an application distributed between a client machine and a server machine, connected over a network. In reality, however, a client-server solution does not have to be thought of in terms of physical processors and networks. It is the business solution that is divided into distinct parts — a logical rather than physical model for client-server computing. The parts, or smallest units of functionality called “services,” can run on any physical machine or share the same processor. Movement of services, assuming availability of resources, between physical machines is strictly a performance issue and should not affect the functionality of the service. This concept of multitier partitioning running on a single machine or over many machines in a distributed environment is fundamental to designing good client-server solutions.

Decomposition Simplifies Implementation

People generally organize large, complex tasks into smaller, simpler ones in order to reach their goals more easily. By breaking up a complex job into a series of smaller tasks, we reduce risk, better understand what is needed to implement each task, and lower both the cost and time needed to achieve our goals. Business-solution development is no exception. Dividing a large computer business solution into many smaller tasks reduces the risk, cost and time of development and simplifies maintenance. Client-server multitier architecture allows for the decomposition of a complex business problem into discrete services that a successful solution must deliver. The multitier developer is able to concentrate more on the delivery of these services incrementally.

Standard Published Interfaces

The idea behind a standard published interface is that any business solution that understands the interface, and has permission, can use it. This concept is key to the future of client-server development. If client-server computing is to be successful, it must have better and faster ways of enabling business solutions. A solution can enable any available business object it needs to provide the necessary functionality and business rules. Programming is in the process of changing drastically. As use of component interfaces becomes standard operating procedure and many more components become available, solution builders will worry less about issues such as memory management and graphics generation and more about solving business problems. They simply will engage the components and services needed to complete the business task at hand. Development languages are changing to support this new concept and to provide easy ways to assemble business solutions together from a combination of commercial and custom-developed components. The fundamental enabling technology for these interfaces is OLE. OLE components encapsulate functionality and provide entry points to the functionality through open OLE-based interfaces. This allows access to the component from within any OLE-based language. Developers at all experience levels therefore can choose the tools most appropriate for them, yet all can share the same set of reusable components.

Multitier Model

A multitier model allows developers to break down complex business processes into digestible pieces, allowing for reusability. The simplest form of a multitier model is the three-tier model. This paper focuses on three-tiers for ease of explanation. You can further subdivide each tier into multiple tiers to gain complexity. The three-tier model nicely fits the client-server architecture (see Figure 1). It uses a services model that consists of the following:

 

*
Figure 1. Three-tier model

The user-services level uses the business-services level as a customer would use a department store catalog: to look up and order a service. A business solution may order many services to implement the task at hand. As an analogy to PC hardware, as programs exercise the personal computer, the CPU will call upon memory and other boards to provide services that it cannot handle on its own. To add a capability, users don’t need to throw out their PCs and buy new ones, they can add a new board, such as a fax card, modem or voice processor. Similarly, new services can be built and added to the catalog. The three-tier model can be extended in several ways:

Services Model

The three-tier approach raises the definition of services from instructions and application programming interface (API) calls to business services. A service is a logical business function that can be aggregated into physical code called a component. These components are referred to as business objects. The solution builder’s job becomes that of combining these new business components into a solution. The collection of business components can be thought of as a set of business-service relationships. By grouping these business components in different ways, we provide different business solutions. Business components can be called by other business components in the same tier or a higher tier. These business components can expose the following three capabilities:

In this model, a business object can function logically as both a client and a server. It can be called by another business object and it can call upon other business objects to complete its tasks. This concept is similar to one of consumers and the supplier chain. A consumer buys a home PC from a PC vendor (supplier) who, in turn, buys parts from many different vendors to construct the PC. The critical characteristic of a business object is that it encapsulates its details and hides them from the consumer. Four-year-olds who use PCs successfully certainly do not understand each interface, component and program that makes up the PC. Ideally, they do not know that these details exist at all. Similarly, user services or business services do not need to know about the internal details of the business objects they call. Only the interface is important.

User-Services Tier -- Presentation

This tier typically runs on a user’s PC and is the direct interface between the user and the computer. It provides a familiar and standard set of interfaces that expose, edit and accept data. A good user interface should have an intuitive way of entering data, calling upon business objects to act on the data, and presenting results back to the user in an informative manner.

In the user-services tier, development is ideally split into two parts, divided by skills as follows:

The user-services tier then makes various calls to the business-services tier to act upon data and to request business objects in a businesslike way. This tier is more concerned with providing and presenting users with solutions to business problems than with the details of the way in which the problem was solved.

A well-defined user interface provides intuitive access to the various business processes that the business solution supports. A business solution will have one or more business purposes that will call upon a set of business objects to implement the solution.

Business-Services Tier -- Business Rules

The business-services tier is a relatively new concept, and it encapsulates business rules and processes enabling clarity of purpose for each individual object. A collection of detailed business objects, called a “component,” is mixed with many other components at this level. Various business solutions call upon one or more of these business components, usually through the user-services tier, to provide a solution. Many business solutions can share a set of business objects (see Figure 2).

*
Figure 2. Business-services tier

Initially, three-tier client-server development requires building business objects at the business-services tier as well as building solutions at the user-services tier. After several business solutions are built, a solid set of business objects will exist that represent the user’s enterprise-computing environment. Thereafter, development of new business solutions may require no new business objects, or only a few.

Building business components can be a complex task requiring a thorough understanding of a user’s overall business, and how various segments of the user’s business would interact with a common business object. For instance, all businesses have customers, and most segments of a business interact with customer information in some way. As a result, it makes a lot of sense to build a customer component that is reusable across the company. To do so, and to eliminate redundant customer databases, a user must understand how various departments interact with customer information, what information they manage, and what existing manual processes might be automated by this component. This is a project in itself — especially for a multinational corporation — but is a positive step toward rationalizing how a company interacts with its customers, and toward creating a single, reusable, highly functional component to do so optimally.

As a core set of business components becomes available, development takes on a much more economical face, and the components themselves become a rapid business-solution environment. A new solution only requires the linking, or “gluing,” of business services with data and presentation. Business components can be added easily to create new solution functionality. For example, assume a user has a tax-calculation business object that uses U.S. dollars as input data. Also assume that the same user’s company has a subsidiary in France that generates revenue in francs. By building a franc-to-dollar-conversion business object, the user can feed the franc revenue through the filter to the tax program.

The following are two important rules for three-tier development:

It is a good implementation practice to provide automated testing programs that exercise the various properties and methods of a business object to ensure compatibility with existing consumers. The various business objects at this tier may fall into several types as follows: Creating business components clearly requires a more rigorous, technical approach than building solutions out of components. It is important to have experience modeling business processes and data, as well as having an understanding of object-oriented modeling techniques. The tools a user chooses to build business components are more technical as well. To truly be useful, business components should be fast, small and efficient, requiring tools such as the Microsoft Visual C++™ development system.

Data-Services Tier -- Business Data

Traditionally, data business objects or servers are thought of only in terms of databases. The data-services tier consists of data in any form:

Insulating the actual data from solutions by the business-services tier improves reliability and accuracy because each function exists only once. The business objects tend to improve over time, and everyone benefits from the improvements. Corporate policy changes can be implemented immediately and placed in effect for every business solution the next time they consume or access the data. Putting the business rules in the code logic of the business objects instead of in triggers and stored procedures provides more complex logic functions for the resolution of a business function.

Conclusion

Three-tier software architecture is the next logical step in software design for businesses. Coarse-grained components that can be used and reused across the enterprise are the functional equivalent of the car industry moving from hand-crafted parts for every car to interchangeable parts.

Creating interchangeable parts requires good engineers and represents an investment. As component reusability increases, an array of problems created by inconsistent, “one-off” applications will be eliminated.

Microsoft, Visual Basic, Visual FoxPro and Visual C++ are either registered trademarks or trademarks of Microsoft Corp. in the United States and/or other countries.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

THIS DOCUMENT IS FOR INFORMATIONAL PURPOSES ONLY. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

This white paper was written by George J. Febish and David E.Y. Sarna, ObjectSoft Corp., Englewood, N.J., in conjunction with Microsoft Corp.