Two Tier Software Architectures

Note

Client/Server Software Architectures, as prerequisite reading for this technology description.

Purpose and Origin

Two tier software architectures were developed in the 1980s from the file server software architecture design. The two tier architecture is intended to improve usability by supporting a forms-based, user-friendly interface. The two tier architecture improves scalability by accommodating up to 100 users (file server architectures only accommodate a dozen users), and improves flexibility by allowing data to be shared, usually within a homogeneous environment. The two tier architecture requires minimal operator intervention, and is frequently used in non-complex, non-time critical information processing systems. Detailed readings on two tier architectures can be found in Schussel and Edelstein.

Technical Detail

Two tier architectures consist of three components distributed in two layers: client (requester of services) and server (provider of services). The three components are

1. User System Interface (such as session, text input, dialog, and display management services)
2. Processing Management (such as process development, process enactment, process monitoring, and process resource services)
3. Database Management (such as data and file services)

The two tier design allocates the user system interface exclusively to the client. It places database management on the server and splits the processing management between client and server, creating two layers. Figure 1 depicts the two tier software architecture.

Figure 1: Two Tier Client Server Architecture Design

In general, the user system interface client invokes services from the database management server. In many two tier designs, most of the application portion of processing is in the client environment. The database management server usually provides the portion of the processing related to accessing data (often implemented in store procedures). Clients commonly communicate with the server through SQL statements or a call-level interface. It should be noted that connectivity between tiers can be dynamically changed depending upon the user's request for data and services.

As compared to the file server software architecture (that also supports distributed systems), the two tier architecture improves flexibility and scalability by allocating the two tiers over the computer network. The two tier improves usability (compared to the file sever software architecture) because it makes it easier to provide a customized user system interface.

It is possible for a server to function as a client to a different server- in a hierarchical client/server architecture. This is known as a chained two tier architecture design.

Usage Considerations

Two tier software architectures are used extensively in non-time critical information processing where management and operations of the system are not complex. This design is used frequently in decision support systems where the transaction load is light. Two tier software architectures require minimal operator intervention. The two tier architecture works well in relatively homogeneous environments with processing rules (business rules) that do not change very often and when workgroup size is expected to be fewer than 100 users, such as in small businesses.

Maturity

Two tier client/server architectures have been built and fielded since the middle to late 1980s. The design is well known and used throughout industry. Two tier architecture development was enhanced by fourth generation languages.

Costs and Limitations

Scalability. The two tier design will scale-up to service 100 users on a network. It appears that beyond this number of users, the performance capacity is exceeded. This is because the client and server exchange "keep alive" messages continuously, even when no work is being done, thereby saturating the network.

Implementing business logic in stored procedures can limit scalability because as more application logic is moved to the database management server, the need for processing power grows. Each client uses the server to execute some part of its application code, and this will ultimately reduce the number of users that can be accommodated.

Interoperability. The two tier architecture limits interoperability by using stored procedures to implement complex processing logic (such as managing distributed database integrity) because stored procedures are normally implemented using a commercial database management system's proprietary language. This means that to change or interoperate with more than one type of database management system, applications may need to be rewritten. Moreover, database management system's proprietary languages are generally not as capable as standard programming languages in that they do not provide a robust programming environment with testing and debugging, version control, and library management capabilities.

System administration and configuration. Two tier architectures can be difficult to administer and maintain because when applications reside on the client, every upgrade must be delivered, installed, and tested on each client. The typical lack of uniformity in the client configurations and lack of control over subsequent configuration changes increase administrative workload.

Batch jobs. The two tiered architecture is not effective running batch programs. The client is typically tied up until the batch job finishes, even if the job executes on the server; thus, the batch job and client users are negatively affected.

Dependencies

Developing a two tier client/server architecture following an object-oriented methodology would be dependent on the CORBA standards for design implementation. See Common Object Request Broker Architecture.

Alternatives

Possible alternatives for two tier client server architectures are

• the three-tier architecture (see Three Tier Software Architectures) if there is a requirement to accommodate greater than 100 users
• distributed/collaborative architectures (see Distributed/Collaborative Enterprise Architectures) if there is a requirement to design on an enterprise-wide scale. An enterprise-wide design is comprised of numerous smaller systems or subsystems.

When preparing a two tier architecture for possible migration to an alternative three tier architecture, the following five steps will make the transition less costly and of lower risk:

1. Eliminate application diversity by ensuring a common, cross-hardware library and development tools.
2. Develop smaller, more comparable service elements, and allow access through clearly-defined interfaces.
3. Use an Interface Definition Language (IDL) to model service interfaces and build applications using header files generated when compiled.
4. Place service elements into separate directories or files in the source code.
5. Increase flexibility in distributed functionality by inserting service elements into Dynamic Linked Libraries (DLLs) so that they do not need to be complied into programs.

Complementary Technologies

Complementary technologies for two tier architectures are CASE (computer-aided software engineering) tools because they facilitate two tier architecture development, and open systems because they facilitate developing architectures that improve scalability and flexibility.