Designing Web Based 3 tier applications

Anju Gupta, CSE584



In an age of information overload, client/server computing emerged as the method of choice for culling the ever-growing mountain of data. The 3-tier is becoming the dominant form of client/server. So what are 3-tier? Tiers are the logical partitioning of an application across clients and servers. Splitting the processing load is a central client/server concept. But it also introduces the previously unnecessary - but now persistent - design issue of where to put these loads. Tiers let us describe the basic architectural choices as discussed below:

Two-tier client/server model

The two-tier model is tied to the physical implementation, a desktop machine operating as a client and a network server housing the back-end database engine. In the two-tier model, logic is split between these two physical locations, the client and the server.

  Presentation Layer(client) --------- Database Layer(server)

 Over time it has become apparent that two-tier client/server model has three critical limitations:

    1. Not scalable. The inability of a two-tier approach to grow beyond the physical boundaries of a client machine and a server machine prevents this model from being scalable.
    2. Unmanageable. Since you cannot encapsulate business rules and deploy them centrally, sharing common processes and reusing your work is difficult at best.
    3. Poor Performance. The binding of the graphical interface to the data source consumes major resources on the client machine, which results in poor performance.


Three-tier client/server model

Three-tier client/server helps address these limitations by putting another physical server between the users and the database. This central, application server, can more efficiently manage network traffic and the load on the database server. The logical three-tier model divides an application into three logical components. They are:

    1. Data Services. These services join records and maintain database integrity
    2. Business Services. These services apply business rules and logic
    3. Presentation Services. These services establish the user interface and handle user input

  Presentation Layer(client) ---------Business Layer ------------Database Layer(server)

 Web-Based client/server model

In this model the presentation services are split onto a browser client and a web server. The web server is responsible for formatting the pages that the user sees. The browser is responsible for displaying the web pages. The advantages are browser client can be easily accessible and it is easy to manage.

Broweser Client ----------Web Server -------------Business Layer ------------Database Layer(server)

The advantages of web based applications are, they are low-cost and low-maintenance applications. In addition, Internet provides mobile users and those working from their homes to support material, information and even corporate data.

Three tier in Details

The Three tier applications have Presentation Services, Business Services and Data Services. Discussed following are how these layers can be implemented using various methods

Presentation Services

The presentation services are actually the most visible part of the whole application: the user –interface. Traditionally, these are the forms, menus and controls that the user uses to interact with our program. The user-interface is just how the user chooses to interact with the objects. The presentation tier can be implemented using various methods.

1. One method would be as in the figure below; here the programmers put most of their code on the user – interface. This approach works well when the applications are event driven but usually these models does not work in the object oriented model.

  User Interface <------------------------

Business Logic

User Interface <-------------------------

 2. Other method, if the program is built based on components that contain business objects then a flexible user interface can written or even a number of interface as shown below in the figure:

 User Interface ------------------------>

Business Logic

User Interface ------------------------->

 3. The Web Browser User Interface method can be described as in the figure below:

   User Interface ------------------------>

Business Logic

Active Server Pages ---------------->

Business Services

Business Objects are the core of the business solution. The user Interface is really a client, or user of the business objects. While the user – interface displays and retrieves data from the user, the business objects need to provide all the business functionality and capabilities required by user interface. At the same time, the business objects need to enforce all the business rules and relationships to meet the design requirements of the application.

    • UI – Centric

In UI-centric business objects should be designed to accurately reflect the real-world business entities that the application needs to model. This means that each object should represent some entity, along with any attributes, methods and business rules that affect that entity. The overall object model should also enforce any business rules regarding how objects interact. Any user-interface will interact exclusively with the UI-centric business objects, and so these objects must not only implement and enforce all our business rules, but they need to provide all the capabilities that the UI developer will require creating a rich, interactive interface for the user.

    • Data-Centric

By splitting the data-centric processing out of our business objects, flexibility in terms of how to deploy our application can be achieved. One can choose to implement the data-centric business objects in a DLL, so that it runs on the client workstation, or we can put them in an EXE running on another machine on the network. The data-centric business objects typically provide certain services that are used by our UI-centric business objects. When an UI-centric business object needs some work done that it can't do by itself, it just has a data-centric object do the work.

Data Services

This tier is responsible for creating, updating, retrieving and deleting data from a data source. In many cases, it also includes more complex features, such as enforcement of relational integrity and other data-related rules.

In most cases, this data handling will actually take place on a database server. This allows us to put quite a bit of processing on the database server, using SQL-stored procedures and triggers. This can often provide important performance benefits, since most SQL database servers can optimize stored procedures so they run very efficiently. It's important to note, however, that much of the work that a database server might have done in an application may actually be more appropriately placed in our data-centric business objects rather than in SQL code. SQL is notoriously difficult to work with. It doesn't compare to tools such as Visual Basic for features such as debugging and flexibility. While it's still very valid to do some SQL coding in an application, it is often much more cost effective to move the processing to a different layer of the application - where we can bring more powerful development tools to bear on the problem.

Middle tier - Components

The middle tier in most 3-tier applications is not implemented as a monolithic program. Instead, it is implemented as a collection of components that are used in a variety of client-initiated business transactions. Each component automates a relatively small business function. Clients frequently combine several middle-tier components within a single business transaction. A component calls other components to help it implement a request.

Server component types

There are two types of middle-tier components

    • Services implement a business function - for example, Update_check ing_account. Services are stateless procedures.
    • Objects expose a set of related procedures or "methods" not just a single procedure. The infrastructure manages all the related methods for bank accounts - such as update, delete and audit methods - as a unit. Object Request Brokers (ORBs) provide a distributed object infrastructure. ORBs can support either stateless or stateful object-oriented components.
    • Stateless Objects do not have a unique state. When a stateless object is called, it must determine what instance data it needs and then retrieve it from a database. When it's done, it must update the database. Example of stateless Object environment are Microsoft's Distributed component Model (DCOM) and Common Object Request Broker Architecture (COBRA), which supports both stateless and stateful objects.
    • Stateful Objects enable clients to request services of a specific object using object identifier. The middle-tier software must deliver the request to that specific object. If it is not already in memory, the infrastructure must find and load the object's state and methods. After the request completes, the infrastructure must store the state and delete the object from memory. Some ORBs work with an Object Database Management System to store state.


Clients sends request to components using logical names instead of physical addresses. The middle-tier infrastructure maps these logical names to physical locations and ensures the delivery of the messages. This mapping provides location transparency for server components.

The middle-tier can provide any of the following messaging alternatives:

    • Conversations an ongoing dialog involving many interactions between clients and server components.
    • Requests- response supports a single interaction between client and server components.
    • Queues decouple the client and server interactions. Messages are queued for servers. Servers access them when they are ready.
    • Publish-and-subscribe enables clients to register their interest in certain messages with an event manager. Server components then "publish" messages to the event manager. The event manager acts as a matchmaker, sending published messages to subscribers that have declared an interest in particular types of messages.
    • Broadcasts and datagrams allow one-way communication to one or more components or clients.


Planning a Web Application

The Web Client/server, the distributed object era has come a long way from the hypertext era to the interactive era. In this section discussed are the things to consider when planning the presentation layer as Web in the three-tier client/server application.

 Identifying the Audience and the Browser

A primary consideration in planning is identifying who will use the Web application—the audience. You can define your Web application’s audience by identifying those who have access to the Web application and the type of Web browser they use. Access can come through an Intranet, the Internet, or an extranet. An extranet is an area on a Web site available only to a set of registered visitors.

In many respects, access to the Web application helps you to determine the type of browser your Web application needs to accommodate. For example, if the Web application is designed for an Intranet, typically you know which browser everyone is using and can program your Web application to take advantage of its features.

The capabilities of the Web browser also shape your plans for using client and server script in your Web application. Using server script and Active Server Pages (ASP), you can generate browser-independent pages easily. The server processes the server script and then sends HTML to the browser for processing. In contrast, if you know what type of browser the user will have, you can use client script to generate the page and minimize the load on the server. Depending on the needs of your Web application, you can incorporate both to take advantage of your system and the capabilities of your target audience.

The audience also determines what type of run-time security your Web application needs. Do you want everyone to be able to read the Web application’s pages? Are some pages for everyone and other pages only for those meeting certain criteria?

Determining Content

The content includes all of the Web items and design elements used to specify the features of your Web application and fulfill the Web application’s purpose. For example, content for announcement pages can be implemented using simple HTML pages or using a database connection to populate an Active Server Page. An order-entry Web application can incorporate a variety of forms and database transactions using server script processing and client script processing. A game Web application can be created using Java applets or dynamic HTML and page objects to take advantage of quick client-side processing. After you have created your initial set of pages, you can add the text, images, and script that fulfill your Web application’s purpose. One of the main considerations in determining how you implement content is whether you want the processing performed on the client or the server. This answer depends on the audience, their browser capabilities, and the resources on your deployment system.

Identifying Items to Use

When planning your Web application’s functionality, you might want to consider using a variety of items to specify the features in your Web application. Since a Web application actually consists of a set of files that reside on a Web server, you can identify each item by its file type. For example, you can incorporate any of the following items into your Web application.

To add


Static pages or client script

.htm files

Server script

.asp files

Data publishing


Design tools

Design-time controls

Visual design

Templates, themes, and layouts, images and multimedia files

Interactive pages

ActiveX controls

Integrated Web solutions

Output files from other projects such as applets

Downloadable documents

Document files, spreadsheets


Web Security

The World Wide Web and HTTP provide the largest imaginable audience for Web applications and a proportionately increased need for. In addition, Web development teams can now span the globe. To control just how that audience and team work with Web application files and gain access to the system that supports them requires for Web applications is a complicated subject because it can be set at several levels in several different ways. The choices depend on the system and servers used and the needs of the Web application.

Some of the considerations are:

Locations for Setting

You can set options in several locations depending on your system and the assumptions you can make about your visitors. For example, basic for an Intranet can be handled and maintained in parallel with the network itself. For an Internet Web application, you can add through the pages provided to the Web browser using the Web application.

When planning which options to use for your Web application and where you want to set those options, it is helpful to consider four types of access to your site. You may want to:

    • Allow any Web visitor to execute ASP pages and read HTML pages at run time.
    • Restrict access to registered Web visitors at run time.
    • Allow Web developers and authors to write to your files at design time.
    • Restrict Web administration to certain authorized users.
User Authentication

In Web, your central concerns are identifying a user and controlling the user's access to your Web application and its resources. You accomplish this by implementing measures to authenticate users and specify access permissions.

In choosing your options, you need to specify how the user provides identification to your Web application, how that identity is verified, and what level of access or permissions that user is allowed. The following table provides guidelines to help you choose the appropriate options for your Web application.


Example interface

Operating system

Domain and user account specified in Windows NT

Web server

User accounts and server properties set in Internet Information Server Administrator


Permissions specified in SQL Server, Enterprise Manager

Web application

Web application properties set in Visual InterDev Web Permissions dialog box, login pages, and variables stored in a session

Each of these locations provides a different feature set for implementing user identification, verification, and permission levels. Depending on the systems and software you are using, the feature sets may work together to set options at the operating system level or they may change related options at other levels.

Operating System Level

Choices you make for the operating system depend on the features and options your operating system offers. For example, if you are using Windows NT, you can implement authentication for a large number of people without explicitly specifying user accounts by using a special user account, referred to as the "guest user." This account is set up by default. If you want to distinguish between individual users and track them, you need to implement options at a different level than your operating system.

In addition to authentication, the file system used by your operating system also affects the permissions you are able to grant to the user. For example, Windows NT may use either Window NT File System (NTFS) or File Allocation Table (FAT). NTFS allows you to specify an Access Control List (ACL) for files and folders so you can control access more granularly. FAT, on the other hand, does not provide the ability to specify lists and offers less control.

Web Server Level

Once the operating system has verified the identity of the user, the Web server can also evaluate the user's identity. The Web server primarily controls access at run time. For example, if you are using the default configuration for Internet Information Server, the Web server processes anonymous requests as the anonymous Internet Information Server user, IUSR_<machinename>.

The anonymous user set up by Internet Information Server is similar to an Internet guest account defined in Windows NT User Manager. However, password changes are not handled automatically. Changes to passwords for one requires an explicit change to the other.

If you have set the anonymous account to allow access to the requested file, Internet Information Server allows access to the file and satisfies the request. Otherwise, Internet Information Server rejects the request, returns an error to the client and informs the client of the authentication methods that Internet Information Server supports.

 Database Level

The measures you set for your database depend on the database management system you are using. If you are using SQL Server, you can use the features for granting and revoking privileges offered within the database management system. For example, Microsoft® SQL Server™ has a Manager that allows you to specify the privileges available to a single user or a group of users.

Although SQL Server for Windows NT offers three types of login, the standard choice is recommended. Standard login requires a login ID and a password to access the server. Your Web application provides this information through the data connection and your users do not need to provide any additional identification.

While not recommended for all systems, some Web applications might use integrated. If you choose to use integrated, keep in mind that SQL Server will use Windows NT to authenticate users so the Web application and database must reside on the same server. Windows NT does not delegate to another server.

Web Application Level

In your Web application, you can take advantage of the features provided through FrontPage server extensions and through the Global.asa file processing available with Active Server Pages.

Deploying and maintaining a Web Application

After you have tested the Web application and are satisfied with its performance, you can deploy it to the Web server you make available to your users. Since a Web application is actually a set of files, you need to copy the virtual root and its file set to the production web Server. If your pages use the virtual root as the basis for their links, all links should still work. If your project includes a dependent project, you need to make sure the server component outputs are properly registered on the server.

The advantage of a Web application is easy maintenance. To upgrade a Web application you don’t need to recompile and redistribute an entirely new executable file. All you need to do is add new files and replace previous versions.

During an upgrade, your users are not interrupted while they are working because their browser is using the original copy of the file it got from the Web server. When the file is replaced with a newer version, the user sees the new version only after refreshing the page not while viewing it. The upgrade to a new file set is seamless.



CMS - a 3-tier web application

With these basic definitions and concepts, I will discuss a 3-tier web application that I helped design and implement.

I work for a company, which is provider of world-class call management systems (CMS) that enable enterprises to profitably acquire, retain, and develop customer relationships. It is used generally by the call centers like collection companies, Tele marketing and promoting companies, consumer-surveying companies’ etc.

The current product that the company has is 2-tier application with a UI, which also combined the business rules, and the centralized data that is flat file based. The system had all the drawbacks of such a system - very difficult to upgrade, difficult to scale and manage.

As a result the company decided to phase out that system and develop a new system. The goals for the new design were that it had to 1) have better performance 2) have good scalability 3) be easy to enhance and add features and 4) give the customers the capability to extend and customize through APIs. 5) Utilize the latest technology.

Our team was given this responsibility and the project started in June 1997.

The application

CMS functionality can be broken up into these basic components:

1) Downloading customer information from a master customer database kept by the company into its own. The information can be customized like name; phone numbers based on the criteria selected.

2) Feed this information to the Telephone Dialer, to make telephone calls

3) Dialing Logic, which decides to rate of dialing, load distribution across the agents, matching agent - customer based on locale issues like language, time zone, telephone call charges etc.

4) Report generation with on-line visual graphs, tables, based on the information collected during the call. System monitoring and management.

5) UI for the calling agents

The development team's primary goal was to design a new system that could make good use of existing business rules on the 2-tier application.

The application and new requirements lent very well to a 3-tier architecture as described earlier.

The UI and the visual reporting tools were to be implemented as thin web clients. The business rules to back the UI, system monitoring, and selection criteria in the second tier and the data storage in the third tier.

Development teams

Once we nailed down the basic parts of the system's design, the teams were quickly organized. Each team had to come with independent prototypes and in process finalizes on the technologies.

    • The database team

The team had to define the schema, implement it on the selected database system and define the necessary database procedures. Two developers.

    • The GUI team

This team was to design the presentation layer - thin client for agent UI and the UI for reports. Six developers.

    • The Server object team

Three developers started to work on the middle layer, which was to provide business rules through server objects and also writing APIs for customers to extend the system.

The 3-tiers

Presentation services

The Internet was an important factor in the move to 3 -tier computing. With the emergence of browser technology on a wide variety of client platforms, the goal of the company was to be to give their enterprise customers choices like agents working from home, managers to be able to do monitoring work remotely and easy remote administration of the product.

As different levels of administrators, managers and agents would use CMS system; security was an important issue. The group levels of security were implemented at the Windows NT server level. Based on access log-ins, the specific users were authorized specific function and data use.


For the client of the CMS system we decided to develop a Web interface developed using Visual Basic 5.0 Active X documents on Windows 4.0 NT server. The choice of VB was mainly due to the ease of working with Visual basic for rapid application development. The team too was already familiar with this technology and it has been proven to work well in web applications. NT server was server of choice for most of our customers and it made sense going with the NT IIS server as the web server of choice. We decided on crystal reports as the technology for the reporting tool on the Web. The choice of this tool was due the company's existing customers that were already familiar with this tool.

Business services

All the CMS business rules are defined as COM server objects. These server objects played the main role in the project developed. They are the main link between the Web client and the database. The server objects also provide standard business components that were reused across the applications. Some APIs were also published to the allow other customer applications to interact with the CMS and its data.


The server objects were developed using Visual C++ and Visual Basic 5.0 on Windows 4.0 NT server. The choice of the tool was again mainly due to ease of working with these tools and prior familiarity. It also went well with the OS of choice, which is NT.

Data services

The CMS database consists of tables containing configuration information and statistical data collected. Minimal referential integrity was implemented for faster data access. It was also decided to keep the reliance on specific technologies to minimum, so as to make the CMS database easily portable to other databases.


The application currently is based on Microsoft SQL server 6.5 on Windows NT 4.0. The choice of the tool is temporary and we decided to go with it because we were developing it on NT. But the future plan is to be able to use customers database like Oracle; Sybase and we kept this in mind while working on the database design.

Project plan

The plan was for all teams to work very closely during the design and prototype phase, but then to work independently for small milestones during the implementation phase. Then at the end of the milestone, the team would attempt to integrate the entire system. The alpha release was planned for Oct'98.

The integration lab was assembled that included a Windows NT 4.0 server for the SQL database, the Internet server and server objects. The lab also had few machines as Web Client. Initially lots of integration issues arose, primarily between the back-end and the front-end client. Eventually they were all resolved.


Testing was an ongoing process to some extent - but was weighted heavily towards end of milestones. At each milestone (a new component was functionally complete), the team follows these steps:

      1. Freeze development on the services
      2. Build the independent components and integrate them
      3. Developers are responsible for running unit and functional tests on their parts of the code
      4. Then the dedicated test team to ensure that the different components work together correctly runs integration tests.

Going into Alpha release

Our schedule has slipped and we are just getting to the alpha release.

Some of the lessons learnt from this project were:

    • To meet the very aggressive schedule of the CMS project, the team intentionally let the object model be less then perfectly object-oriented. The choice of the development tool for Object modeling as Visual Basic created incredible amount of performance problems.
    • The object locking was implemented at the very later stages of the project. This caused problems like locking up of the whole system and thus brings the whole system down. The servers had to be re-booted to load the applications again.
    • The visual basic active X documents created thick client problems. It would take minutes on the web client when the screen would refresh with fresh data. Installing the .dlls and the scripts created maintenance problems
    • The Windows NT level security was not very flexible. It could not provide solutions for many situations
    • To support a mission-critical use, the run-time environment must be managed and controlled. But in this CMS system we failed to address these issues.
    • With the ship date slip by a whole year in this world of ever evolving technologies the CMS application was already a year behind in the cutting edge market. For example, SQL 7.0 was already released; Visual Basic 6.0 version was out.

The future

Learning from its mistakes the team is moving ahead with following as its goals:

    • Keep exploring emerging technologies even during the implementation phase. For example the group is planning on moving to thin client solutions writing server side ASP pages. Java would be another choice. The COM objects would probably be re-written in C++ for better performance and ease of use.
    • Determine how the new technologies can be used to help CMS offer the best possible products and services to its customers. For example the group is looking at new technology, XML, as its report writing tool.
    • Identify, if the previously written code can be salvaged to some extent, this would save a huge development time.


Though our first shot at working on a 3tier application was not very successful, I still believe in the technology. With the success stories in the fields of Internet Banking, Internet stock Markets, Consulting business etc it comes as no surprise that the software industry on the whole has now begun to embrace distributed object computing as the mechanism that will allow Internet/intranet and "component" technologies to interface with enterprise-scale business information systems.


    1. 3-tier Client/Server at Work by Jeri Edwards with Deborah DeVoe
    2. The essential Client/Server survival Guide by Robert Orfali, Dan Harkey and Jeti Edwards
    3. Understanding Thin Client/Server computing by Joel P. Kanter
    4. Visual Basic Client/Server How -To by Noel Jerke, George Szabo, David Jung, Don Kiely
    5. Microsoft Software Developer Network, October 1998 edition
    6. XML for Dummies, by Ed Tittel, Norbert Mikula and Ramesh Chandak
    7. Programming Active Server Pages by Scott Hillier and Daniel Mezick