Most of the initial client/server success stories involve small-scale applications that provide direct or indirect access to transactional data in legacy systems. The business need to provide data access to decision makers, the relative immaturity of client/server tools and technology, the evolving use of wide area networks and the lack of client/server expertise make these attractive yet low risk pilot ventures. As organizations move up the learning curve from these small-scale projects towards mission-critical applications, there is a corresponding increase in performance expectations, uptime requirements and in the need to remain both flexible and scalable. In such a demanding scenario, the choice and implementation of appropriate architecture becomes critical. In fact one of the fundamental questions that practitioners have to contend with at the start of every client/server project is - "Which architecture is more suitable for this project - Two Tier or Three Tier?". Interestingly, 17% of all mission-critical client/server applications are three tiered and the trend is growing, according to Standish Group International, Inc., a market research firm.
Architecture affects all aspects of software design and engineering. The architect considers the complexity of the application, the level of integration and interfacing required, the number of users, their geographical dispersion, the nature of networks and the overall transactional needs of the application before deciding on the type of architecture. An inappropriate architectural design or a flawed implementation could result in horrendous response times. The choice of architecture also affects the development time and the future flexibility and maintenance of the application. Current literature does not adequately address all these aspects of client/server architecture. This paper defines the basic concepts of client/server architecture, describes the two tier and three tier architectures and analyzes their respective benefits and limitations. Differences in development efforts, flexibility and ease of reuse are also compared in order to aid further in the choice of appropriate architecture for any given project.
DEFINITION
Despite the massive press coverage of client/server computing, there is much confusion around defining what client/server really is. Client and server are software and not hardware entities. In its most fundamental form, client/server involves a software entity (client) making a specific request which is fulfilled by another software entity (server). Figure 1 illustrates the client/server exchange. The client process sends a request to the server. The server interprets the message and then attempts to fulfill the request. In order to fulfill the request, the server may have to refer to a knowledge source (database), process data (perform calculations), control a peripheral, or make an additional request of another server. In many architectures, a client can make requests of multiple servers and a server can service multiple clients.
Figure 1 - Client/Server Transactions
It is important to understand that the relationship between client and server is a command/control relationship. In any given exchange, the client initiates the request and the server responds accordingly. A server cannot initiate dialog with clients. Since the client and server are software entities they can be located on any appropriate hardware. A client process, for instance, could be resident on a network server hardware, and request data from a server process running on another server hardware or even on a PC. In another scenario, the client and server processes can be located on the same physical hardware box. In fact, in the prototyping stage, a developer may choose to have both the presentation client and the database server on the same PC hardware. The server can later be migrated (distributed) to a larger system for further pre-production testing after the bulk of the application logic and data structure development is complete.
Although the client and server can be located on the same machine,
this paper is concerned primarily with architectures used to create distributed
applications, i.e. those where the client and server are on separate physical
devices. According to Bever (et al.), a distributed application consists
of separate parts that execute on different nodes of the network and cooperate
in order to achieve a common goal[1].
The supporting infrastructure should also render the inherent complexity
of distributed processing invisible to the end-user. The client in a client/server
architecture does not have to sport a graphical user interface (GUI), however,
the mass-commercialization of client/server has come about in large part
due to the proliferation of GUI clients. Some client/server systems support
highly specific functions such as print spooling (i.e. network print queues)
or presentation services (i.e. X-Window). While these special purpose implementations
are important, this paper is predominantly concerned with the distributed
client/server architectures that demand flexibility in functionality and
enhanced graphical user interfaces.
ARCHITECTURE TYPES
When considering a move to client/server computing, whether it is to replace existing systems or introduce entirely new systems, practitioners must determine which type of architecture they intend to use. The vast majority of end user applications consist of three components: presentation, processing, and data. The client/server architectures can be defined by how these components are split up among software entities and distributed on a network. There are a variety of ways for dividing these resources and implementing client/server architectures. This paper will focus on the most popular forms of implementation of two-tier and three-tier client/server computing systems.
Two-tier Architecture
Although there are several ways to architect a two-tier client/server system, we will focus on examining what is overwhelmingly the most common implementation. In this implementation, the three components of an application (presentation, processing, and data) are divided among two software entities (tiers): client application code and database server (Figure 2). A robust client application development language and a versatile mechanism for transmitting client requests to the server are essential for a two tier implementation. Presentation is handled exclusively by the client, processing is split between client and server, and data is stored on and accessed via the server. The PC client assumes the bulk of responsibility for application (functionality) logic with respect to the processing component, while the database engine - with its attendant integrity checks, query capabilities and central repository functions - handles data intensive tasks. In a data access topology, a data engine would process requests sent from the clients. Currently, the language used in these requests is most typically a form of SQL. Sending SQL from client to server requires a tight linkage between the two layers. To send the SQL the client must know the syntax of the server or have this translated via an API (Application Program Interface). It must also know the location of the server, how the data is organized, and how the data is named. The request may take advantage of logic stored and processed on the server which would centralize global tasks such as validation, data integrity, and security. Data returned to the client can be manipulated at the client level for further sub selection, business modeling, "what if" analysis, reporting, etc.
Figure 2 - Data Access Topology for two-tier architecture. Majority of functional logic exists at the client level
The most compelling advantage of a two-tier environment is application development speed. In most cases a two-tier system can be developed in a small fraction of the time it would take to code a comparable but less flexible legacy system. Using any one of a growing number of PC-based tools, a single developer can model data and populate a database on a remote server, paint a user interface, create a client with application logic, and include data access routines. Most two-tier tools are also extremely robust. These environments support a variety of data structures, including a number of built in procedures and functions, and insulate developers from many of the more mundane aspects of programming such as memory management. Finally these tools also lend themselves well to iterative prototyping and rapid application development (RAD) techniques, which can be used to ensure that the requirements of the users are accurately and completely met.
Tools for developing two-tier client/server systems have allowed many IS organizations to attack their applications backlog, satisfying pent-up user demand by rapidly developing and deploying what are primarily smaller workgroup-based solutions. Two-tier architectures work well in relatively homogeneous environments with fairly static business rules. This architecture is less suited for dispersed, heterogeneous environments with rapidly changing rules. As such, relatively few IS organizations are using two-tier client/server architectures to provide cross-departmental or cross-platform enterprise-wide solutions[2]
Since the bulk of application logic exists on the PC client, the two-tier architecture faces a number of potential version control and application re-distribution problems. A change in business rules would require a change to the client logic in each application in a corporation's portfolio which is affected by the change. Modified clients would have to be re-distributed through the network - a potentially difficult task given the current lack of robust PC version control software and problems associated with upgrading PCs that are turned off or not "docked" to the network.
System security in the two-tier environment can be complicated since a user may require a separate password for each SQL server accessed. The proliferation of end-user query tools can also compromise database server security. The overwhelming majority of client/server applications developed today are designed without sophisticated middleware technologies which offer increased security[3]. Instead, end-users are provided a password which gives them access to a database. In many cases this same password can be used to access the database with data-access tools available in most commercial PC spreadsheet and database packages. Using such a tool, a user may be able to access otherwise hidden fields or tables and possibly corrupt data.
Client tools and the SQL middleware used in two-tier environments
are also highly proprietary and the PC tools market is extremely volatile.
The client/server tools market seems to be changing at an increasingly
unstable rate. In 1994, the leading client/server tool developer was purchased
by a large database firm, raising concern about the manufacturer's ability
to continue to work cooperatively with RDBMS vendors which compete with
the parent company's products[4].
The number two tool maker lost millions[5]
and has been labeled as a takeover target[6].
The tool which has received some of the brightest accolades in early 1995
is supplied by a firm also in the midst of severe financial difficulties
and management transition[7].
This kind of volatility raises questions about the long-term viability
of any proprietary tool an organization may commit to. All of this complicates
implementation of two-tier systems - migration from one proprietary technology
to another would require a firm to scrap much of its investment in application
code since none of this code is portable from one tool to the next.
Three tier
The tree tier architecture (Figure 3) attempts to overcome some of the limitations of the two-tier scheme by separating presentation, processing, and data into separate, distinct software entities (tiers). The same types of tools can be used for presentation as were used in a two-tier environment, however these tools are now dedicated to handling just the presentation. When calculations or data access is required by the presentation client, a call is made to a middle tier functionality server. This tier can perform calculations or can make requests as a client to additional servers. The middle tier servers are typically coded in a highly-portable, non-proprietary language such as C. Middle-tier functionality servers may be multi-threaded and can be accessed by multiple clients, even those from separate applications.
Although three-tier systems can be implemented using a variety of technologies, the calling mechanism from client to server in such as system is most typically the remote procedure call or RPC. Since the bulk of two-tier implementations involve SQL messaging and most three-tier systems utilize RPCs, it is reasonable to examine the merits of these respective request/response mechanisms in a discussion of architectures. RPC calls from presentation client to middle-tier server provide greater overall system flexibility than the SQL calls made by clients in the two-tier architecture. This is because in an RPC, the requesting client simply passes parameters needed for the request and specifies a data structure to accept returned values (if any). Unlike most two-tier implementations, the three tier presentation client is not required to "speak" SQL. As such, the organization, names, or even the overall structure of the back-end data can be changed without requiring changes to PC-based presentation clients. Since SQL is no longer required, data can be organized hierarchically, relationally, or in object format. This added flexibility can allow a firm to access legacy data and simplifies the introduction of new database technologies.
Figure 3 - Three Tier Architecture. Most of the logic processing is handled by functionality servers. Middle-tier code can be accessed and utilized by multiple clients
In addition to the openness stated above, several other advantages are presented by this architecture. Having separate software entities can allow for the parallel development of individual tiers by application specialists. It should be noted that the skill sets required to develop c/s applications differ significantly from those needed to develop mainframe-based character systems. As examples, user interface creation requires an appreciation for platform and corporate UI standards and database design requires a commitment to and understanding of the enterprise's data model. Having experts focus on each of these three layers can increase the overall quality of the final application.
The three tier architecture also provides for more flexible resource allocation. Middle-tier functionality servers are highly portable and can be dynamically allocated and shifted as the needs of the organization change. Network traffic can potentially be reduced by having functionality servers strip data to the precise structure required before distributing it to individual clients at the LAN level. Multiple server requests and complex data access can emanate from the middle tier instead of the client, further decreasing traffic. Also, since PC clients are now dedicated to just presentation, memory and disk storage requirements for PCs will potentially be reduced.
Modularly designed middle tier code modules can be re-used by several applications. Reusable logic can reduce subsequent development efforts, minimize the maintenance work load, and decrease migration costs when switching client applications. In addition, implementation platforms for three tier systems such as OSF/DCE offer a variety of additional features to support distributed application development. These include integrated security, directory and naming services, server monitoring and boot capabilities for supporting dynamic fault-tolerance, and distributed time management for synchronizing systems across networks and separate time zones.
There are of course drawbacks associated with a three tier architecture. Current tools are relatively immature and require more complex 3GLs for middle tier server generation. Many tools have under-developed facilities for maintaining server libraries - a potential obstacle for simplifying maintenance and promoting code re-use throughout an IS organization. More code in more places also increases the likelihood that a system failure will effect an application so detailed planning with an emphasis on the reduction/elimination of critical-paths is essential. Three tier brings with it an increased need for network traffic management, server load balancing, and fault tolerance.
For technically strong IS organizations servicing customers with
rapidly changing environments, three tier architectures can provide significant
long-term gains via increased responsiveness to business climate changes,
code reuse, maintainability, and ease of migration to new server platforms
and development environments.
COMPARING TWO AND THREE TIER DEVELOPMENT EFFORTS
The graphs in Figures 4-6 illustrate the time to deployment for
two tier vs. three tier environments. Time to deployment is forecast in
overall systems delivery time, not man hours. According to a Deloitte &
Touche study, rapid application development time is cited as one of the
primary reasons firms chose to migrate to a client/server architecture.
As such, strategic planning and platform decisions require an understanding
how development time relates to architecture and how development time changes
as an IS organization gains experience in c/s.
Figure 4 - Initial Development Effort
Figure 4 shows the initial development effort forecast to create comparable distributed applications using the common two tier and three tier approaches discussed above. The three tier application takes much longer to develop - this is due primarily to the complexity involved in coding the bulk of the application logic in a lower-level 3GL such as C and the difficulties associated with coordinating multiple independent software modules on disparate platforms. In contrast, the two-tier scheme allows the bulk of the application logic to be developed in a higher-level language within the same tool used to create the user interface.
Figure 5 - Subsequent Development Efforts
Subsequent development efforts may see three-tier applications deployed with greater speed than two tier systems (Figure 5). This is entirely due to the amount of middle-tier code which can be re-used from previous applications. The speed advantage favoring the three-tier architecture will only result if the three-tier application is able to use a sizable portion of existing logic. Experience indicates that these savings can be significant, particularly in organizations which require separate but closely related applications for various business units. Re-use is also high for organizations with a strong enterprise data model because data-access code can be written once and re-used whenever similar access needs arise across multiple applications. The degree of development time reduction on subsequent efforts will grow as an organization deploys more c/s applications and develops a significant library of re-usable, middle-tier application logic.
Figure 6 - Client Tool Migration
Figure 6 makes the important case for code savings when migrating from one client development tool to another. It was stated earlier that client tools are highly proprietary and code is not portable between the major vendor packages. The point was also made that the PC tools market is highly volatile with vendor shake outs and technical "leapfrogging" common place. In a two-tier environment, IS organizations wishing to move from one PC-based client development platform to another will have to scrap their previous investment in application logic since most of this logic is written in the language of the proprietary tool. In the three-tier environment this logic is written in a re-usable middle tier, thus when migrating to the new tool, the developer simply has to create the presentation and add RPC calls to the functionality layer.
Flexibility in re-using existing middle-tier code can also assist organizations developing applications for various PC client operating system platforms. Until recently there were very few cross-platform client tool development environments and most of today's cross-platform solutions are not considered "best-of-breed". In a three-tier environment the middle tier functionality layer can be accessed by separate client tools on separate platforms. Coding application logic once in an accessible middle tier decreases the overall development time on the cross-platform solution and it provides the organization greater flexibility in choosing the best tool on any given platform.
SUMMARY
In the early 1980's, ANSI, in conjunction with the University of Minnesota, defined a three layer architecture for building portable systems. This architecture divided data processing into presentation, processing (functionality logic), and data. This paper has considered the role of each of these data processing layers within the framework of two popular client/server architectures.
Two tier architectures group the presentation with most of the non-database processing in a single client application. The robustness and ease of use of two tier development tools dramatically decrease initial development time, however IS organizations may pay a penalty when trying to update functionality simultaneously in a variety of systems, when trying to integrate systems, or when trying to migrate from a proprietary development tool. Three tier architectures split these three layers into three distinct software entities. This architecture requires more planning and support, but can reduce development and maintenance costs over the long term by leveraging code re-use and flexibility in product migration. Three tier architectures are also the most vendor-neutral of the architectures considered and thus can facilitate the integration of heterogeneous systems.
Kean (1991) pointed out that a firm's long term ability to compete is directly related to (enabled or limited by) the reach and range provided by the firm's technical architecture. His suggestions for defining a platform include selecting architectures which:
* protect existing IT investments
* ensure the firm's ability to adopt new technologies
* provide integration of heterogeneous resources
* accommodate emerging standards embraced by a broad base of firms[8]
Our discussion of popular client server architectures exposes the weaknesses in the overwhelming majority of current client/server systems - systems employing a two-tier architecture - as they relate to Kean's platform selection criteria. Such systems may provide adequate work group-level systems which can be developed rapidly and employ empowering interfaces. However, such systems lack the openness, flexibility, scalabilty, and integration provided by three-tier systems. The case for deploying three-tier systems will develop over time as tools mature and momentum for vendor-neutral standards increase. A variety of research opportunities exist including examining issues in migration from two-tier to three-tier systems, operationalizing the conceptual graphs presented here as they relate to development time, and studying how the level of complexity in three-tier systems acts as a barrier to its wide-spread acceptance.