Bringing Data to the Web
The problems associated with building a Web-based, database-intensive application are different and more complex than comparable client-server applications. The pros are obvious: The benefit of building a Web application is that the user interface layer, a browser, is ubiquitous and guaranteed to be deployed on a user's desktop. This eliminates the need for legions of software support specialists to install and configure the application on hundreds or thousands of desktops. Web-based applications can be deployed to users regardless of their physical location or corporate allegiance. The cons are more difficult.
When running a Web application, you realize how little control you have over who the users are and how they use the system. Usage patterns may be more sporadic than rhythmic. This is especially true if you are deploying an application on the Internet and less true if you are deploying an internal intranet application or allowing business partners to access an application through an extranet. An application that performs well in an intranet environment, however, may be swamped when it gets opened up to external users.
Database connectivity is another issue. A Web application may be inundated by thousands of users trying to access a database server simultaneously. While modern relational databases are capable of handling large numbers of transactions, they are not optimized to support thousands of concurrent clients, especially when those clients initiate a connection, execute a single, relatively brief transaction and immediately disconnect. In this scenario the database may become consumed with initiating and tearing down hundreds or thousands of connection threads.
You also need to address the problem of maintaining a transaction state across multiple connections. A typical database application will have a user log onto the database, retrieve some data, display it for edit or update, retrieve and validate edits or new data, then insert or update the data into the DBMS. Each of these steps requires at least one and possibly several, round-trip communications with the browser, Web server and DBMS. The HTTP protocol, which is the foundation of the Web, is connectionless and stateless. Therefore, when a Web server receives an HTTP request from a browser client it accepts a connection, parses the incoming message, formats the reply -- usually as a string of HTML text -- sends the HTML to the client, and closes the connection. This connectionless protocol enables fast, lightweight data transfer, but it also requires that a mechanism outside the database "remember" which step the user is executing.
Bandwidth is another issue to consider. Most client-server applications are written for a LAN environment that is rich in bandwidth. Personal computers are typically equipped with a minimum of 10 MBps Ethernet, but 100 MBps is becoming more common. The Web, however, uses WAN technology, with lower bandwidth and higher latency. An application's architecture, therefore, must conserve network bandwidth wherever possible to improve performance.
Web-based applications also create new security issues. Today’s industry news is full of stories about how private, sensitive information became accessible to unauthorized users either through malicious or accidental release. Identification, authentication, and authorization become mission-critical issues to ensure that unauthorized users are not granted access to corporate or personal data. Similarly, encryption becomes more important as this information is transmitted over public networks or private networks with dial-up access ports.
Traditional client-server applications use a development model that is different than the Web model. The client-server workstation is usually a Windows client, while the Web client is either an HTML browser or Java virtual machine. HTML pages lack the flexibility and programmability of a interactive application written using Visual Basic or Visual C++. This lack of flexibility has been offset by the availability of scripting languages that can be executed from an HTML page and Active Server Pages (ASPs) as well as Java development environments. While ASP is a popular approach to developing Web applications, it does limit platform choices. ASP applications work best on Microsoft’s IIS, while Java can run on almost any Web server.
In my next column I’ll discuss how some companies address these issues from an architectural approach. --Robert Craig is vice president of marketing at Web Engine Inc. (Burlington, Mass.), and a former director at the Hurwitz Group Inc. Contact him at rscraig@webxi.com or via the Web at www.webxi.com.