Previous Table of Contents Next


NEW MODEL FOR DISTRIBUTED COMPUTING

The Web’s benefits derive from its architecture. A Web application is not merely a client/server application with a Web browser interface. “Web-native” applications take full advantage of this architecture. “Web-enabled” applications typically miss the full set of benefits because they are tied to an existing client/server-based architecture. Four key areas in which the Web architectural model differs significantly from that of client/server include: network infrastructure, client-side requirements, server-side requirements, and management of database login.

WAN vs. LAN

Web applications are deployed over a wide area network (WAN), in contrast to client/server applications, which are deployed over proprietary local area networks (LANs). There are two immediate implications in this difference: reach and cost.

In the WAN environment, companies can communicate with anyone connected to the WAN, including customers and business partners worldwide. LANs typically have a smaller reach and are also often expensive to install and maintain. WAN applications provide a means for a company to communicate with business partners or employees worldwide without building a global private network.

Application Publishing — Server vs. Client

Web applications, in contrast to client/server applications, are primarily server-based, with a “thin client” front end. This thin client may do some business logic processing, such as data validation, but the bulk of the business logic is processed on the server side rather than on the client.

Client/server applications, in contrast, typically support “fat clients,” in which the application is a sizeable executable running on the client. Although this model takes advantage of client CPU power for application processing, the client/server model does not provide the Web’s primary benefit — instant application distribution. Web tools that provide client-side plug-ins typically call themselves “Web-enabled” as opposed to “Web-native” because they are not taking full advantage of the Web’s architecture in instant distribution.

N-Tier vs. 2- or 3-Tier

Web applications require a multi-tier, or n-tier, server architecture. Scalability takes a quantum leap on the Web, with a much larger application audience and greater uncertainty in the number of users who might choose to access the application at any given time.

Client/server applications hit the wall with a 2-tier architecture. To solve this problem, some client/server implementations have moved to a 3-tier architecture. Given the greater number of users who can access a Web application, even 3-tier models are not enough to sustain some of the heavy-duty applications being deployed today.

In addition, the Web provides the capability to move intranet applications, such as customer portfolio management, directly to the customer over the Internet. These applications can only migrate to the Internet environment if they have been designed to scale.

Shared Database Connection vs. Individual Login

Web applications incur heavy CPU processing requirements as a result of the number of users accessing the application. As a result, well-designed systems provide users with persistent shared database connections. In this model, the user only ties up a database connection when he or she has pressed an action button, hyperlink, or image that requests data from the database. Once the data is returned, the database connection is free for another user, without requiring the database connection to be shut down and reopened for the new user.

In the client/server model, the user maintains an individual persistent database connection from the time he or she logs on to the time the application is exited. In this model, the database connection is inefficient because the user is logged onto the database regardless of whether a database action is taking place or whether the user is merely looking through the results that have been returned.

Technical Considerations

Although a Web architecture delivers significant benefits, it also introduces new technical challenges, particularly with respect to scalability, state and session, and security. When developing applications and selecting development tools, it is critical to understand these challenges and how they are being solved by different vendors in the industry today.

Scalability and Performance

Web-native applications (i.e., the application is server-based rather than a client-side browser plug-in) that provide the highest degree of scalability are deployed through an n-tier application server. Application servers first appeared in the market in December 1995 and have rapidly gained acceptance as a model that overcomes the limitations of the common gateway interface (CGI) in execution of scalable applications.

In the early stages of Web development, applications were executed through CGI. In this model, the Web server receives a request for data, opens a CGI process, executes the application code, opens the database, receives the data, closes the database, then closes the CGI process, and returns the dynamic page. This sequence takes place for each user request and ties up CPU time in system housekeeping because of the starting and stopping of processes. System housekeeping involved in executing the application increases proportionally to the size of the application executable.

Application servers, in contrast, stay resident as an interface between the Web server and database server. In this model, the Web server passes the request to the application server through a very small CGI relay or the Web server APIs. The application server manages the application processing and maintains persistent connections to the database. Enterprise-level application servers multiplex users across persistent database connections, can be distributed across multiple CPUs, and provide automatic load balancing and monitoring.

State and Session Management

The Web is a stateless environment, meaning that information about the user and the user’s actions are not automatically maintained as the user moves from page to page in the application. This presents obstacles to providing LAN-like interaction in the Web environment.

Some technology vendors have solved this problem by building session and state managers into the application server, which allows developers to build applications with persistent memory across pages. An early approach that also persists is to write “cookies” or files containing state information to the client browser. These files are read on each page access. This is a manual process that is less secure than server-based session and state memory.


Previous Table of Contents Next

Copyright © CRC Press LLC