An evaluation of three approaches to WWW application development

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Overview

The purpose of this article is to discuss three basic architectural approaches to WWW applications. The solutions discussed here are standards-based; other approaches, which are not purely standards-based on both client and server sides, are not considered. Our focus is on evaluation of the different approaches and the advantages, disadvantages and issues associated with each.

I. Common Gateway Interface (CGI) Solution

The CGI solution is the most widely used of the three architectural approaches. CGI itself is a protocol by which HTTP servers invoke external applications in response to a user requesting a URL. The external applications would respond to the request by dynamically building the Web page. In order to fulfill the request, this application may access a relational database or other data store.

The client for the application could be any Web browser that is able to interpret standard HTML (such as Netscape Navigator or the Microsoft Browser). HTML is capable of basic text formatting, hypertext links, clickable images, forms and tables. This is sufficient to build a functional and interactive interface. Additional functionality can be derived by using browser-specific functions such as JavaScript, plug-ins, ActiveX, and others. However, in utilizing these extensions, you may lock your application into a specific browser.

A CGI application is a collection of functions which respond to specific user requests. Each of these functions is executed as a discrete process on the machine where the HTTP server is located. Therefore, each function is a separate executable, usually written using a language such as C or a scripting language such as PERL. The Web server for the this approach could be any server supporting the CGI protocol. Figure 1 illustrates how the components of a CGI application interact.

Figure 1 CGI Approach

Advantages:

Simple and Proven Methods. The Common Gateway Interface approach uses HTML, CGI, and C or PERL, all of which are proven technologies. The CGI solution is fairly simple to develop. It is stable, not reliant on new and/or emerging standards, and does not require an extremely sophisticated body of knowledge to maintain.

Any Browser or HTTP Server May Be Used. Assuming no browser-specific HTML is employed, any web browser capable of interpreting standard HTML may be used to access the application. The appearance of the application may differ slightly from browser to browser, and some modifications may be necessary to ensure a satisfactory appearance on the popular browsers. In addition, no specific server reliance exists, thus allowing existing hardware to be leveraged.

Performance. As long as user activity levels remain relatively low, the performance of the system should be very good, since HTML is the only front-end interface being used. Standard HTML is quickly interpreted by market-leading Web browsers and does not suffer some of the performance penalties of Java or JavaScript. On the other hand, HTML does not offer the more advanced features and capabilities of these technologies. Using C language for the back-end applications will provide excellent performance and flexibility. While C may be more complex than using a scripting language, such as PERL, its flexibility and performance benefits make it worth serious consideration.

Disadvantages:

Difficult to Change Web Page Design. Since the HTML code that determines the Web page appearance is embedded in C applications, modifying the layout of the Web pages requires knowledge of the C language. Additionally, making changes will require the application to be recompiled and redeployed. This also means that Web page design packages cannot be used to produce the final HTML. Design programs can be used in the early stages to design the basic appearance of the page, but the HTML code that is produced has to then be incorporated into the C applications. After that, any changes to the pages need to be done by hand, without the help of a Web page designer.

Limited to HTML Functionality. Since only standard HTML will be used, advanced features such as those offered by JavaScript, Java, and plug-ins will not be available. In certain cases, the application requirements may dictate that these features be available.

Poor Scalability. CGI-based solutions require a discrete process to respond to each user request. This not only leads to inefficient use of available server resources, but also means applications with high transaction volume requirements will not provide satisfactory response times.

Session Management. A session exists if there is a virtual circuit between the client and the server, which is established at the client log-on and destroyed at client log-off. Typically, there would also exist session context information which would contain a connection to the database. CGI does not support this paradigm, hence the identity of the user making the request is not available between requests. Work-around solutions to this problem require more development effort and maintenance time than would be required with more technologically complex solutions.

II. Server Application Tools Solution

Development tool vendors, recognizing the limitations of pure CGI, have developed tools that address these limitations out of the box. HTTP vendors, Microsoft and Netscape offer alternatives to CGI which utilize server resources in a much more efficient manner. These alternatives are known as Internet Server Application Programming Interface (ISAPI) and Netscape Server Application Programming Interface (NSAPI) respectively. The combination of the two provides a solution, which manages context and provides easy access to all popular relational databases, as well as maximizing server resources.

The development tools now offered provide context management and other utility functions that are tested and well documented, allowing developers to focus on application-specific functionality. Most of the tools offer a choice of CGI or CGI alternatives. Offering CGI as an alternative serves to prevent the risk of HTTP server vendor lock-in.

It is important to note that the Server Application Tools solution is strictly an alternative to CGI. Issues that are related to using HTML extensions still exist. The most common extension is the use of client side scripting such as JavaScript and VBScript. Scripting allows client side logic for tasks which do not require database access. In this context, Java and ActiveX are not included and will be discussed later.

Figure 2 illustrates the components of the Server Application Tools approach and their relationships. Figure 2 also shows a configuration where the development tool utilizes an HTTP server CGI alternative.

Figure 2 Server Application Tool Approach

Advantages:

Rapid Development. The tools in this category come with easy-to-use database access, utility functions to create dynamic pages, and resolution of client request parameters. WYSIWYG HTML editing prevents maintenance headaches. In addition, sample applications and tutorials may be included to speed developers along the learning curve.

Scalable Architecture. The alternatives to CGI provided by HTTP vendors are much more efficient that CGI, enabling a significantly larger number of concurrent users to be supported.

Disadvantages:

New and Untested Technology. The vast majority of these products are immature and untested. Until you build your application and stress test it, there is no guarantee the products will perform to your expectations.

Uncertain Vendor Future. The number of vendors competing in this space is very large. Vying for this market are startup companies with roots in Internet technology, and traditional client/server tools vendors, Web-enabling their development environments. Since it remains uncertain which of the startup vendors will survive, it is wiser to select tools developed by an established and stable supplier.

Limited User Interface. Although enhanced by the HTML extensions of frames and tables, even a JavaScript enhanced user interface would not be able to provide users with the most advanced forms of GUI — tabs and outliners.

III. Distributed Objects Solution

The distributed objects solution represents the most advanced of the three approaches presented here. The Distributed Objects approach is utilized for mission-critical or heavy on-line transaction processing systems. Its architecture comprises three tiers. The client platform (tier 1) consists of any workstation platform running a Java- or ActiveX-enabled Web browser. The client provides presentation logic only. The middle, or second tier, provides objects which contain business logic. The third tier contains data, usually a relational database.

The Distributed Objects solution allows clients to have more traditional interface tools such as tab folders, spreadsheets, and tree views. In addition, the client tier has a direct connection to the second tier. All communication between the client and business objects is handled by distributed objects middleware, Common Object Request Broker Architecture (CORBA — See http://www.omg.org for details) and Distributed Component Object Model (DCOM — See http://www.microsoft.com for details).

Figure 3. Distributed Objects

Client Application. The application is implemented as an applet embedded in an HTML Web document on the Website. This applet is downloaded from the HTTP server along with the HTML documents and run in tier 1 on the client workstation. Each user is required to provide a log-in I.D. and password before any database activities will be permitted. Once authenticated, the user will interact with the system in a manner similar to traditional GUI client/server applications. All data access is handled by the data server application.

Data Server Application. The server is a collection of business objects that are exposed through DCOM or CORBA. The business objects perform data validation and database transactions to fulfill client requests. In most cases, these servers are multi-threaded.

Advantages:

Richest User Interface. The Distributed Objects approach provides a sophisticated client/server application look-and-feel combined with multimedia capabilities to the graphical front-end.

High Portability (Java only). Highly portable on clients and servers, this solution allows you to leverage the current platform as both HTTP and application server.

High Scalability. Multi-threaded server implementation scales well. Each user request is handled by a separate thread, which is significantly more efficient than a separate process.

Superior Development Environment. Excellent development environments, including fully functional debuggers for both client and server, support Java and ActiveX environments.

Related Issues

Requires High Level Development Skills. Support personnel would be required to know both Java and CORBA. This level of knowledge is in line with the complexity of C++ today.

Higher Cost. The middleware for the Distributed Objects solution can carry a substantial cost, potentially as high as $10,000 per deployed server and $5,000 per developer. Thus, the time required to gain the backing for this decision within an organization may slow initial development.

Summary

All three of these Web application development approaches have their place, depending on the specific application requirements and budget constraints. However, CGI alone should rarely be used. The productivity of server application tools is money well spent. Applications developed with these tools are best suited for reporting and automation of paper-based systems. Going further up the complexity scale, if you are developing a mission-critical or On-Line Transaction Processing application, the Distributed Objects approach offers more sophisticated user interface and scalability, thus ensuring your technology investment throughout the useful life of the application.

About the author:

Brent Hauf can be reached at the Revere Group.