The Components of a Web Application

The Components of a Web Application

Building Web application systems is like trying to put together a home entertainment system: The possibilities are endless. Certain home entertainment systems come with all the components bundled together and configured with predefined parameters. All you have to do is put the various pieces in a nice mahogany cabinet with shelves, plug in the power, plop down on the couch, and click the buttons on the remote control. True audiophiles, however, never rest until they pick out each individual component, connect them, fine tune them individually, and seek the maximum performance from them. Who do we say has made the right choice? Ms. audiophile or Mr. drive-home-with-an-all-in-one-system? There is no such thing as a right choice. The choices come from the person's needs and desires. To achieve optimal performance, a person has to pick out each component carefully and configure it for delivering that level of performance. Acoustics, lighting, ambient noise, elegance in storage, ability to bring out the best in various kinds of media all these factors have to be considered by anyone planning a customized entertainment system. If the person's needs are restricted only to certain media or to obtain only somewhat better than average performance, an all-in-one entertainment system can serve those needs. The advantage there is that the system is sold as one composite unit, by a single vendor, and is easy to set up and operate.

The same can be said for Web application systems. Vendors selling an end-to-end system have all their components designed and laid out to work with one another straight from the box. If a person's needs call for superlative application performance and throughput, the way to go is to craft a Web application solution by mixing various Web application technologies.

A typical Web application system has three main components:

         Front-end Web server

         Web application execution environment

         Database server

Figure 6-1 shows the layout of a typical Web application system.

Figure 6-1. A bird's eye view of a typical Web application system

Leaving aside the Web browser and firewall for now, let's consider the functional aspects of each of the other components of a Web application system. Keep in mind that each component doesn't have to run on a single computer. As with an entertainment system, they may all be fitted into a single unit or sold and connected individually.

The Front-End Web Server

The front-end Web server is primarily responsible for receiving HTTP requests from various clients and sending HTTP replies to them. Front-end servers are typically meant to cater to a high volume of requests and handle many concurrent connections at the same time while making efficient use of resources and providing high throughput. These servers are typically quite versatile. By themselves, they may not do much more than just serve static HTML files or they may possess some dynamic scripting abilities. However, they are by no means adequate to serve an entire Web application by themselves.

Functionalities of a good front-end Web server should include the following.

         Scalability and robustness: The capacities of the Web server should be easily extendable without putting a burden on the hardware of the server and the operating system being used. As the load increases, degradation in performance should be minimal. The server should lend itself to easy recovery from errors caused by subcomponents or external components interfaced with it.

         Tried-and-tested against commonly known attacks: Because front-end Web servers are the first components to be attacked, they should be hardened against commonly known vulnerabilities such as buffer overflows, meta-character insertion, and the like.

         Ability to handle a high load and a large number of concurrent connections: Front-end Web servers usually are multithreaded to handle a high volume of traffic, both in terms of number of requests served per unit time and number of concurrent connections in service at any given time. These parameters require careful tuning of the underlying operating system for maximizing Web server performance.

         Versatile configuration facilities: Customizing and configuring various aspects of the front-end Web server, such as resource type mappings, error handlers, and interfaces with external components, should be possible.

         APIs or plug-in support for integrating external components or modules: Front-end Web servers also should provide some type of application programming interface (API) or a plug-in framework to permit third-party developers to extend and customize the abilities of the Web server. The API and plug-in frameworks also allow Web application execution environments to fit seamlessly within the front-end Web server. For instance, the Apache Web server allows Distributed Shared Objects (DSO) to be written and integrated with the main Web server. Microsoft IIS has the ISAPI framework that lets developers write plug-ins and the Netscape server has a similar framework, NSAPI.

The four most popular front-end Web servers, according to a survey conducted by Netcraft (http://www.netcraft.com) are:

         Apache

         Microsoft IIS

         Netscape/iPlanet server

         Zeus Web server

The Web Application Execution Environment

The Web application execution environment is a platform for writing customized applications that receive input from HTML forms or URLs and generate HTML output dynamically. Typically, Web application execution environments are commonly referred to as Web application servers, but the terms are sometimes used interchangeably. A Web application execution environment or a Web application server component can be as simple as an extension within the front-end Web server or a separate application system altogether.

Just as modern operating systems come with a built-in scripting language or interpreters, front-end Web servers also contain a prepackaged Web scripting language component. Scripting languages and processors such as Perl, Active Server Pages (Visual Basic), and PHP, among others, are commonly bundled with Web servers such as Apache, IIS, or Netscape.

When picking a Web application server component, you should keep in mind the following factors.

         Suitability to task: Choice of the proper application programming language is crucial in designing a Web application. Generic scripting languages such as Perl have now given way to application languages more suited for developing Web applications, such as PHP and ASP. Component-driven frameworks such as Java J2EE and Microsoft's .NET also are becoming popular. In many cases, Web applications are derived from legacy client-server applications. Instead of rewriting the entire application, developers usually prefer to apply wrappers around and interface with the existing code to make it Web-enabled. Object-oriented languages are our clear choice.

         Front-end Web server interfaces: A Web application server component must be able to interface with the front-end Web server as seamlessly as possible. A good Web application server component should offer many methods of integrating with front-end Web servers. Popular Web application server components, both commercial and noncommercial, support integration with Apache, Microsoft IIS, and Netscape servers.

         Database interfaces: The Web application server component must be able to interface with popular database servers such as Oracle, DB2, SQL Server, and MySQL. Database connectivity can either be a part of the programming language library, or it can be a separate component that can be invoked from various applications.

The Database Server

Database servers in a Web application system are used to host various databases and tables needed by the application. Database servers are perhaps the most mature of all the components needed to assemble a Web application system. A database server interacts with the application via native APIs, database drivers, or middle-layer components. All database transactions are handled via SQL.