Accessibility / Report Error

Application of middleware in the three tier client/server database design methodology


With the popularity of personal computers and powerful workstations, today’s users are no longer satisfied with the traditional data processing. They demand eagerly to putting up graphics on existing applications, putting a lot of pressure in system re-engineering. The Client/Server architecture is a less risky and less costly approach in adding a Graphical User Interface for users. The developer has to determine data and program logic distribution among client, middleware server, and the top-tier server. Middleware is a kind of software that links programs running on different platforms, transmitting messages and data. It plays an important role in 3-tier architecture. There are two types of middlewares: the first connects client programs to server programs, and the second provides data access connections to heterogeneous data sources. The developer also needs to separate on-line transaction processing, project-oriented data processing, and history data from each other. In view of no existing standard method in developing a middleware server, this paper outlines a methodology to design a 3-tier Client/Server database system. It identifies the role of middleware as temporary storage for better performance and as database gateway for Database Management Systems connectivity. Case studies are used to illustrate the steps.

3-tier client/server system; heterogeneous databases; middleware; data distribution; logic distribution; on-line transaction processing project-oriented data processing; history data

Joseph Fong

Computer Science Department

City University of Hong Kong

Kowloon, Hong Kong.


Riemann Hui
Division of Computer Studies
City University of Hong Kong
Kowloon, Hong Kong.


With the popularity of personal computers and powerful workstations, today’s users are no longer satisfied with the traditional data processing. They demand eagerly to putting up graphics on existing applications, putting a lot of pressure in system re-engineering. The Client/Server architecture is a less risky and less costly approach in adding a Graphical User Interface for users. The developer has to determine data and program logic distribution among client, middleware server, and the top-tier server. Middleware is a kind of software that links programs running on different platforms, transmitting messages and data. It plays an important role in 3-tier architecture. There are two types of middlewares: the first connects client programs to server programs, and the second provides data access connections to heterogeneous data sources. The developer also needs to separate on-line transaction processing, project-oriented data processing, and history data from each other. In view of no existing standard method in developing a middleware server, this paper outlines a methodology to design a 3-tier Client/Server database system. It identifies the role of middleware as temporary storage for better performance and as database gateway for Database Management Systems connectivity. Case studies are used to illustrate the steps.

Keywords: 3-tier client/server system, heterogeneous databases, middleware, data distribution, logic distribution, on-line transaction processing project-oriented data processing, history data.

1 Introduction

Nowadays, information technology is moving in the direction of Client/server (C/S) computing, where multiple platforms of computing equipment are linked together, allowing users to make the best out of each piece of hardware efficiently, economically, and transparently. Application logic and databases are developed on client workstations, as well as the servers. Processing, though mostly initiated by a client and served by a server, could run in a peer-to-peer manner.

GUI applications demand huge computing resources. They offer user-friendly features such as windows, pull-down and pop-up menus, push buttons and point-and-click mouse device. Implementation of GUI directly to a traditional computer system could cause significant performance problems [1].

A C/S system increases its processing power by the distribution of its database and processing logic into different servers and client workstations, thus off-loading the workload on the database server. Such an approach meets users’ demands on the expansion of a system’s capability by incorporating GUI, desktop computing facilities, and moving towards the establishment of a global accessible database for various systems within an organization.

There are several kinds of C/S models. The most popular are the 2-tier C/S and the 3-tier C/S models. Although a multiple-tier C/S model is possible, the complexity in architecture, and the access time between the client and the top-tier discourage such approach. Their comparison appears in Table 1.

Table 1
Comparison of 2-tier and 3-tier C/S database systems

The 3-tier architecture is considered to be a second generation of client server architecture because it is extended from traditional 2-tier architecture. The 3-tier architecture adds an application server as a middleware tier between client and database servers. The middleware tier is a separate piece of software, typically running on a separate piece of hardware, that performs most of the application logic such as enforcing business rules and performing complex processing. When an application is broken into user interface, application logic and database management, it is 3-tiered.

In an ideal 3-tiered model, application logic are completely partitioned into a middle machine. The more the application design separates the interface, application logic and data service, the more easily one can change and maintain each domain without affecting the others. However, in reality, it is unlikely that the business logic can be completely partitioned to a dedicated machine. On the contrary, the application logic and business rules should be located where it makes sense.

The application logic which should be located in the client has the following features: it is very stable, data are not maintained by the database server, and it requires instantaneous response. The application logic which should be located in the application server has the following features: it is used by many applications, changes frequently, encodes sensitive information and uses data from heterogeneous data sources. The evolution of application architecture appears in Figure 1.

Figure 1 -
Application Architeture Evolution

A 3-tier architecture has many benefits in comparison with its 2-tier predecessors in performance, scalability, maintainability, presence of heterogeneous databases, and application development. It enables the system to work in a heterogeneous database environment for the following reasons:

  • The 3-tier model can work best in a heterogeneous database environment where all the database servers and the interactions with these servers are of different types because the middleware server can be used for provision of data access connections to heterogeneous data sources as database gateway.

  • The middleware server provides highspeed native access to multiple databases, so performance is improved over database connecticity solutions like Open Database Connectivity. That means one is not embedding SQL programs into client applications and not locking one´s products to specific database vendors.

  • Implementing a 3-tier application using a database gateway as a middleware server can cause the application logic and businness rules achieve database independence. This means that you can use different data sources without modification of the application logic and business rules.

  • Data access middleware software provides customers with a consistent interface to multiple data sources (relational DBMSs, nonrelational DBMSs, and file systems). Gateways can be thought of as one form of data access middleware [3].

The cooperative processing techniques in a client server architecture can be classified as shown in Table 2 [2].

Table 2
C/S processing techniques

For example, [5] reported that in the information technology division of hospital authority in Hong Kong, a system CM is responsible for (a) hospital administration, such as add ward, bed and specialties in hospital; (b) admission, bed assignment, transfer and discharge of patients. Due to the team expansion and organization reason, the CM team will be divided into two teams called CM1 and CM2 respectively. The CM1 team is responsible for hospital administration while the CM2 team is responsible for admission, bed assignment, transfer and discharge of patients. The two teams may use different DBMS to store their data because of different project management. If the CM team is really divided into two teams, the CM1 team uses the Sybase DBMS and the CM2 team uses the Oracle DBMS. The existing ward system needs to retrieve and updates data for both patient movement and hospital administration. Moreover, certain application logic of the application will be changed by the two teams. As a result, three problems arise:

  • Data integration of multiple heterogeneous database.

  • Data Migration of a system from one DBMS to another causes serious maintenance problems.

  • Modification of application logic of a system causes serious maintenance problem.

A solution can be provided by changing the existing 2-tier C/S system into 3-tier C/S system with the use of middleware server, OmniConnect, shown in Figure 2 [13].

Figure 2 -
A middleware server for heteregeneous database servers

2 Related Work

[8] pointed out that C/S systems place the application closer to the user. The result is increased performance and more sophisticated interfaces for users. One disadvantage of C/S systems is control; because of parallel processing, conflicts due to concurrency are more difficult to manage. [2] indicated that in the 3-tier C/S architecture, the top tier is usually occupied by the most powerful system and the source of corporate data, the mainframe. The second tier (middleware) contains LAN servers which act as top-tier clients sending requests to the mainframe, and as servers for the workstations residing in the third tier. It requires intra-tiered communication with inter-communication between hosts in the first tier, and between servers in the second tier. The resulting architecture becomes more complex to build and manage. However, the resulting computing capacity has increased in order of magnitude, and is scalable. As number of workstations grows, additional LANs and more servers can be put into operation.

[9] defined that computing applications can be characterized as consisting of a collection of individual components which can be categorized as

  • User Interface Processing – Software components responsible for accepting input from users and for displaying or printing result.

  • Function Processing – Software components responsible for performing the processing necessary to solve a particular business problem.

  • Data Processing - Software components responsible for accessing data stored on external storage devices.

Any number of the three types of application components can be combined in various ways to create different configurations of C/S computing. Viewing computer applications as consisting of collection of components in the three categories listed above is called the three-tier model C/S computing.

[1] suggested that a C/S application can be designed for implementation across one, many or a combinations of tiers. A tier refers to a physical level within a C/S system. With each succeeding level, the architectural complexity expands significantly. Another way of structuring the application is through the definition of application layers. Layering the application refers to how the application is structured. The four basic layers of a C/S application are:

  • Presentation – User interface view.

  • Application Logic – End user’s business process requirements meet the limits and challenges of technology tools, for example, the logic of a procedural language.

  • Business rules – The implementation and maintenance of business specification.

  • Database – The access to the database.

The decision as to where these layers reside is influenced by performance requirements, maintainability issues, complexity and project team expertise.

[10] divided middleware products into two categories:

  • Primitive middleware – The middleware layer that is able to tie together many different systems to create a single logical system, a virtual system, for example, Remote Procedural Calls, Message-oriented Middleware, Object Request Brokers and Distributed Computing Environment.

  • Database-oriented middleware – It uses a primitive middleware to more information to and from a database, for example, ODBC and Java DataBase Connectivity.

[3] argued that gateways can be thought of as one form of database access middleware. One of the benefits of middleware is that a major rewrite would not be necessary if data were moved from one DBMS to another, because direct requests or calls to these DBMSs could be handled by the middleware for the purpose of reengineering. Therefore, it raises the level of abstraction from programmers by enabling them to avoid dealing with various environment-specific and data source-specific interface. However, middleware introduces a layer of software between the application and the target data source, which will cause additional instructions to be executed and can create overhead that may affect performance. In addition, if the middleware must interface to a production DBMS, the performance of that DBMS may be impacted as well. [6] concluded that the approach of a replication server provides major alternatives to a two-phase commit mechanism for designing on-line distributed databases. Among its advantages, it reduces network and data server load and reduces transaction times for users by providing local data. It improves availability, since processing continues when network links are down and supports real world problems including heterogeneous environment.

This paper outlines a C/S database design methodology using middleware and based on data processing techniques requested by the application to remotely access data and maintain database integrity. The techniques can be divided into:

  • Online transaction processing – It requires current data update to reflect business operation, and applies data passing, remote execution and interactive execution in middleware and top-tier.

  • Project-oriented data processing – It requires current data update and pass data files initially, followed by data passing, remote execution and interactive execution in middleware and top-tier.

  • History related data processing – It processes statistical data by using data passing in middleware and top-tier.

3 Three-tier Client/Server Database Design Methodology

A stepwise procedure of using middleware in 3-tier C/S database design is recommended. To illustrate its application, a case study of using middleware for project oriented data processing is made as an example, along with the methodology.


In the case study, a large container shipyard had a centralized computer system in operation for several years. The system was working 24 hours a day, 365 days a year to provide the following functions:

  • Roadside container movement in and out the shipyard

  • Railway container movement in and out the shipyard

  • Vessel Operation including container discharging from and loading to vessels

  • Ship Planning

  • Other subsystems

The existing system allowed users to capture container data at various business operation stage, to prepare vessel stowage plan, and to create crane working programme. The system also allowed users to view container inventory, ship stowage plan, roadside tractor queue, vessel operation report, railway scheduled jobs, shipyard map, and various statistical reports. A shipyard map display showed a 6 * 4 grids, with each grid stood for a container. Each screen represented a cross-section view of a particular row inside a block of containers.

Ship planners were responsible for planning containers discharging from and loading into a bay of a vessel. The container stacking criteria inside a vessel was determined by port of destination, the weight of the container, and the classification of cargo category. A bad stowage plan could cause unrecoverable sea disaster. To create a stowage plan, the ship planner required details on containers, shipyard location, and the bay structure of the ship. In order to optimize physical shipyard operation, the user used 2 terminals to acknowledge any change to shipyard position, or any additional containers. The process was time consuming, demanding highly skillful, and conscious staff.

An initial proposal was to revamp the system by replacing the vessel planning system with directly connected graphical terminals. The study team acknowledged this was high risk due to the complexity of the existing system, and the processing power of the existing system to support the number of graphical terminals. An alternative proposal is required.

Step 1 Feasibility Study

In a C/S system, the majority of application logics dealing with user interface are developed in the client workstation, while all shared resources activities such as printer or database access are to be dealt at the servers. Data are distributed among workstations, and servers at each tier. The database can either be partitioned, non-replicated, replicated, or partitioned with replication. Choice of approach can be reflected from the requirement of the application ---- the greater the flexibility, independence, and reliability, the more the cost, the integrity, and the security.

The way a user interface affects the allocation of programming logic among clients and upper-tier servers could also affect the distribution of data.

Whilst most 2-tier C/S run on one network operator system, 3-tier C/S usually do not. Not all communication networks support connection oriented access, resulting in restricted processing techniques (e.g. batch file transfer). Data concurrency control and transaction management are also critical issues for a distributed database system [12].

The result of the feasibility study should be able to justify the necessity of a 3-tier architecture by identifying the role of a client, the middleware server, and the top-tier server; how they could interact, and how much benefits can they gain from the implementation. The choice of which processing technique is dependent on the nature of the application, type of databases being involved, and the underlying communication network. For the nature of decision support system application, history related data processing is appropriate. For the project-oriented application, project-oriented data processing is a suitable choice. Otherwise, OLTP is adopted (refer to Table 3).

Table 3
Data processing in C/S system


In the case study, the user requirement is to design a new C/S database to support GUI front-end processing, and improve information content for ship planning process. To achieve this, each ship planning process requires a pair of large size high-resolution graphics, one for the shipyard map, the other one for the stowage plan (bay plan) of a vessel. A planned container should disappear from the shipyard map screen, and appear at the bay plan screen. A ship stowage planning activity can be seen as a project-oriented task. During planning, the containers are still in the shipyard, and are looked after by the main system. The ship planning information is autonomous to the ship planner, until the user finishes planning and transfers the data back to the main system. Once the vessel operation is completed, the planning data are no longer needed at the user’s workstations. A 3-tier client server architecture is proposed.

Step 2 Determine Functional Requirements

All system requirements must be collected in detail. Conflict requirements should be resolved. The output is a requirement specification.


In the case study, the system requirements are:

  • Provide a user-friendly front-end system at the clients for each ship-planning process, minimum supporting 5 concurrent planning processes.

  • Specify the global schema and data in the main system, and at middleware servers.

  • Specify the fragmentation schema for the ship planning unit.

  • Allocate preferential local data for middleware server (e.g. dedicated server for certain kind of vessels).

Step 3 Conduct data analysis

Data processing is the prime objective in application development. Data items can be described in semantics diagram by grouping them into records, and relations, forming an Entity Relational model. The analysis should reflect data volume, access rate and timing, retention period, import and export requirement. Data used for on-line real-time update should be different from on-line inquiry, which should be separated from data used for historical information [8]. Data only used for client user interface should not be replicated at top-tier server, although they may be duplicated at the middleware server in some circumstances since each client sends its requests to one top-tier through middleware, but a top-tier can serve more than one middleware.


Figure 3 shows part of the E-R model for the proposed ship stowage planning system.

Figure 3
- Part of the E-R Model of Ship Planning System

Step 4 Perform functional analysis

Functional analysis can be achieved with the help of Data Flow Diagrams. In a three tier C/S, implicit functions should be incorporated to reflect access between tiers. Inconsistency found in the functional analysis and data analysis should be identified by now. Adjustment to data or functions can be made to align the two steps.


In the case study, figure 4 is part of the DFD of the ship stowage planning C/S system where the middleware server processes initial vessel data requests from a client workstation. If vessel data does not exist, the request is passed to the top-tier server to extract required vessel data, as well as the shipyard map containing the selected vessel containers. The middleware server identifies which workstation is dealing with the shipyard map, or which one is dealing with the bay plan. The data are transmitted to client workstations to prepare ship planning. The output plan is passed back to the middleware server to validate the stability. Valid plans are uploaded to the top-tier server for preparation of crane-working programme. At the end of ship stowage planning, data is uploaded to the top-tier server for planning the crane working programme.xxxxxxxxxxxx

Figure 4
- Processes of Ship Planning System

Step 5 Adentify Processing Technique

In a 3-tier C/S environment, not all systems are capable to implement interactive execution, partly due to incompatible databases, and partly due to the underlying communication network, and most important, it is the application to dictate the processing technique. The objective of selecting a particular processing technique is to allow applications to run remote data efficiently, while maintaining data integrity. Usage of data in a 3 tier C/S is categorized in Table 3.xxxxxxxxxxxxxxxxxx


In the case study, the Ship Planning Department is a separate unit, and the data is project-oriented; the technique used is Data Passing. When a planner initiates a ship planning for a vessel, all containers for the selected vessel are retrieved from the top-tier server, downloaded to the Middleware using file transfer technique. Subsequent changes of container information at the top-tier server are transmitted to the Middleware server using Data Passing technique. At the end of ship stowage planning, data is uploaded to the top-tier server for planning the crane working programme.

Step 6 Data distribution in a 3-tier Client Server

The objective of data distribution in a 3-tier C/S is to provide efficient processing of data by locating the data close to the source of processing, while maintaining sufficient data integrity. In general, data locality in a 3-tier C/S should reflect a functional split of a business unit within an organization, or an autonomous project within the organization. Refine the ER diagram according to the data distribution. The data allocation in a 3-tier C/S system is shown in Table 4.xxxxxxxxxxxxxx

Table 4
Data allocation in 3-tier C/S system


In the case study, partition of data is split by business unit function as shown in Table 5.

Table 5
Partition of data by tier

Step 7 Application Logic Distribution in 3-tier C/S system

Similar to data distribution, application logic of a 3-tier C/S system can be distributed among the processors at each tier. Requests for DBMS access and response to requests are sent over the communication network using the processing techniques as described before. The main objective is to minimize data traffic over the communication network. The programming logic distribution between client and server are shown in Table 6 (based on [9]) and Table 7. Table 7 also shows the programming logic for each tier.'

Table 6
Logic distribution and its processing technique in C/S system
Table 7
Programming logic by tiers

Figure 6 -
Client Workstation 2 - Bay Plan Information

Step 8 Design Logical Database

Map the E-R diagram to the DBMS platform. Normalize the resulting relations (or sets) as a basis for logical database. Incorporate performance tuning if deemed necessary.


After mapping the E-R model to global schema in the form of relations for middleware server and the client workstation, there are no redundancy in data attributes in tables. The tables can be used for logical database design. The data distribution has simplified the data integrity check between different tiers.

Step 9 Program Design

In a 3-tier C/S environment, programs should be developed by means of various tools. Client workstations should use their own data, or data available at the middleware server. Data required outside the middleware server should be restricted, or only a limited amount of data should be transmitted. When using interactive execution technique, programs should be divided into small programs, allowing fast recovery and error tracing, and should be stored in the tiers, as shown in Table 8.xxxxxxx

Table 8
Program storage in 3 tier C/S system


In the case study, the ship planning activities are now processed at a pair of client workstations. With the GUI, application activities are carried out at the client workstation. The middleware server provides communication link between the clients and the top-tier server, while maintaining a backup copy of client data on request. Changes to container information at top-tier level will cause an update at the client through the middleware server. Table 9 shows the stored procedure for the top-tier server that obtains stowage planning data, transmits them to middleware server and sets project status to active.

Table 9
Stored procedure for top-tier:

Step 10 Physical database design

This step performs the database tuning operations such as indexing, clustering, database integrity rules, and physical allocation of data. It is in particular important at the middleware server.


In the case study, in order to speed up the processing of searching active vessel containers, the physical database design of the main system introduces indices on the following keys: vessel, voyage, container_id, bay_location.

4 Conclusions

Middleware servers can be applied as a system solution in heterogeneous database environments, to serve as database gateways for virtual database connectivity. They can also be applied in meeting the data requirements in business units as temporary storage for better performance. The discussion in this paper has proposed a methodology to develop a 3-tier client/server application with enhanced graphic capability, to be applied to an existing system. The stepwise procedure suggests a standard to follow in developing a 3-tier C/S. The key task is to identify the nature of the application, the business entity and the existing heterogeneous databases environment. A case study is used to indicate how to reduce the complicated 3-tier C/S to a manageable environment. The approach does not restrict the use of a DBMS platform, allowing various data models to operate in the same C/S system. In addition, the use of the data passing technique does not affect the performance of client or the middleware server, while other tiers may be heavily involved in other activities. The practical value of the methodology is to identify the functions of middleware in developing a 3-tier C/S database system. Future research will be dedicated to using a 3-tier C/S system to implement a data warehouse system.

  • [1] L. Barnes and D. Shimberg, Client/Server & Beyond: Strategies for the 21st Century, Prentice Hall, 1997, pp. 211-213.
  • [2] A. Berson, Client/Server Architecture, McGraw-Hill Inc., 1994, pp. 39-41,
  • [3] C. Bontempo and C. Saracco, Database Management: Principles and Products, Prentice Hall, ISBN 0-13-380189-6, 1996, pp. 152-154.
  • [4] S. Ceri and Pelagatti, Distributed Database Principles & Systems. McGraw-Hill Inc.1995, pp. 84-85.
  • [5] B. Choy, A methodology for 3-tier architecture for client-Server System, Project prototype report of Department of Computer Science, City University of Hong Kong, 1997, pp. 1-107.
  • [6] L. Duggan, Is two phase commit enough, Hong Kong Computer Journal, 1993, pp. 29-31.
  • [7] J. Fong, and R. Hui, Three Tier Client/Server Database Design: A Practical Approach to in- corporate GUI into existing DBMS, Proceedings of 8th International Database Workshop, Springer Verlag, ISBN 981-3083-54-9, 1997, pp. 317-331.
  • [8] W. H. Inmon, Developing Client/Server Application in an Architectural Environment. QED Technical Publishing Group. 1991, pp. 73-92.
  • [9] D. Kroenke, Database Processing Fundamentals, Design, Implementation, Macmillan Publishing Company, 1993, pp. 513-544.
  • [10] D. Linthicum, David Linthicum’s Guide to Client/Server and Intranet Development, John Wiley & Sons, Inc., 1997. pp. 44-46.
  • [11] J. Martin, and J. Leben, Client/Server Databases Enterprise Computing, Prentice Hall, 1995, pp. 97-99.
  • [12] B. Siu, and J. Fong, Strategy for Adopting Client/Server Technology: Experience in the Hong Kong Setting, Proceedings of Database/Client-Server Conference China ’96, 1996, pp. 55-70.
  • [13] Sybase, Sybase OmniConnect Gateway. 1994, Sybase, Inc.
  • [14] T. Teorey, Distributed Database Design: A Practical Approach and example, ACM SIGMOD RECORD 18(4): 23-39, 1989
  • 1
    Move from top-tier server
    intermediate storage from top-tier server to be download to client, or the completion of ship planning for selected vessel
  • Publication Dates

    • Publication in this collection
      16 Dec 1999
    • Date of issue
      July 1999
    Sociedade Brasileira de Computação Sociedade Brasileira de Computação - UFRGS, Av. Bento Gonçalves 9500, B. Agronomia, Caixa Postal 15064, 91501-970 Porto Alegre, RS - Brazil, Tel. / Fax: (55 51) 316.6835 - Campinas - SP - Brazil