Designing Web Based 3 tier applications
Anju Gupta, CSE584
12/14/98
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:
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.
Over time it has become apparent that two-tier client/server model has three critical limitations:
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:
Presentation Layer(client) ---------Business Layer ------------Database Layer(server)
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.
The Three tier applications have Presentation Services, Business Services and Data Services. Discussed following are how these layers can be implemented using various methods
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:
Business Logic
User Interface ------------------------->
3. The Web Browser User Interface method can be described as in the figure below:
Business Logic
Active Server Pages ---------------->
Business ServicesBusiness 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.
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.
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.
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.
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.
There are two types of middle-tier components
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:
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.
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?
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.
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 |
Consider |
|
Static pages or client script |
.htm files |
|
Server script |
.asp files |
|
Data publishing |
Recordsets |
|
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 |
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:
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:
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.
|
Location |
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 |
|
Database |
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.
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.
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.
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.
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.
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.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.
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.
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 team had to define the schema, implement it on the selected database system and define the necessary database procedures. Two developers.
This team was to design the presentation layer - thin client for agent UI and the UI for reports. Six developers.
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 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.
Technology
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.
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.
Technology
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.
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.
Technology
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.
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:
Some of the lessons learnt from this project were:
Learning from its mistakes the team is moving ahead with following as its goals:
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.