Coach Wei

Subscribe to Coach Wei: eMailAlertsEmail Alerts
Get Coach Wei via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Why Web Applications Can be Problematic and Unreliable

Why Web Applications Can be Problematic and Unreliable

It's no surprise that the common perception is that Web applications are unreliable and problematic. Users often experience "404," "resource unavailable," and "network unavailable" errors or even a mysterious application error telling them to "retry the application later." The truth is, a fundamental source of all these problems is the HTTP communication layer of the Web.

The Internet was initially designed for presenting and sharing hyperlinked documents in the form of Web pages. Therefore, the communication layer is based on the HTTP "Request/Response" model, which adequately serves the purpose of page browsing. However, the Internet has since evolved far beyond simply supporting browsing activity and is now being utilized as an interactive platform for supporting mission-critical enterprise applications. However, in this context, there are still problematic Web browsing assumptions made - especially with regard to the messaging layer - when it comes to Web application development.

First off, the Web's messaging layer does not support guaranteed message delivery. When a user submits a request to the server, whether this request will actually arrive at the server or not is unpredictable. If there is a network problem (either with the ISP or within the corporate network), there is a good chance the request will be lost. However, this is not always a problem for Internet browsing, as the user can always click the link a second and third time if the first URL request is lost. Although this seems like a basic example, it's a serious problem for mission-critical enterprise applications. The point is, it's not out of the realm of pos-sibility that a multi-million dollar transaction can literally be "riding on the line."

Another factor to consider is that the Web's messaging layer does not guarantee the order of message delivery. If the user submits two requests in a row, there is no guarantee that the first request will arrive at the server before the second request. Again, while this is not necessarily a problem for browsing Web pages, the result of a later request can be dependent on an earlier request when using the Internet for business applications. A random ordering of message delivery makes the application's behavior unpredictable - a pattern that many Web application users are familiar with.

Further, the Web's messaging layer does not support server-initiated or server-push communications; it supports client-pull only. In a client-pull only model, the server works like a phone that never rings. Obviously this is not a problem for browsing because the server simply responds to page requests. However, many enterprise applications require the server to initiate interactions. For example, a stock trading application needs to push the latest stock price from the server to the end user. To side step this problem, developers typically use client polling, but this significantly increases the server/network load and therefore decreases application performance.

As discussed, when considering developing and deploying Web applications, the messaging layer's unreliability and limited functionality are fundamental problems that must be seriously considered. A potential solution to the message reliability issue is to implement message queuing on both the client and server side. Thus, if a message failed to be delivered due to a temporary network problem, the message can be retrieved from the queue and re-sent once the network is available. Message queues also help guarantee the order of delivery. To get around server-push limitations, some developers leverage client-polling techniques. Although it is possible to develop a solution in-house to address some of these issues, the technical challenge can be significant and the cost to test and maintain the solution can be high.

An alternative approach is to investigate some commercially available application platforms that have built-in solutions to all these problems. Some Rich Internet Application (RIA) platform solutions now available have a built-in capability for reliable messaging and real-time server push. Such solutions not only deliver a richer application experience, but also dramatically improve the application's robustness and reliability by providing a stronger communication layer - a critical factor when considering the Internet as a means of housing enterprise-level applications.

As the Web continues to become more widely adopted as a mission-critical enterprise application platform, it's even more imperative that developers truly understand and take into consideration its flawed communication model. There are now RIA solutions available to help developers overcome these limitations. Otherwise, traditional Web applications will not only frustrate end users and IT staff, they will also introduce significant problems that disrupt everyday operations.

More Stories By Coach Wei

Coach Wei is founder and CEO of Yottaa, a web performance optimization company. He is also founder and Chairman of Nexaweb, an enterprise application modernization software company. Coding, running, magic, robot, big data, speed...are among his favorite list of things (not necessarily in that order. His coding capability is really at PowerPoint level right now). Caffeine, doing something entrepreneurial and getting out of sleeping are three reasons that he gets up in the morning and gets really excited.

Comments (6) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
mike skramstad 05/27/08 04:47:20 AM EDT

I write and use error detection scripts and automatic repair routines to ensure that applications are available all the time. Essentially, looking for the '404' or other errors before users see them and fixing them automatically.

Geoffrey Wiseman 12/20/04 09:28:51 AM EST

The internet was not designed for sharing hyperlinked documents -- nor was HTTP part of the 'design of the internet'. The web is not the internet.

RK 12/15/04 09:31:02 AM EST

The beauty of the web (read HTTP) and the cause of wide adoption is most certainly its simplicity. There is no client to develop as a standard HTTP/HTML+ client is already available with users (ala browser). By far these are the reasons why web development has exploded in the last few years. I understand that this is not perfect but I would hesitate to recommend any other protocol (RIA in this case) because of the less than 10% scenario when the limitations surface as critical issues.

Robert Roach 12/14/04 09:37:22 PM EST

The author seems to be trying to lead the reader to consider RIAs. So, why not write something more substantial about that, rather than merely a passing reference to RIAs mentioned near the end of the article. Everything else written is either obvious, repetitive or in some cases wrong (Internet designed to serve http pages, huh?). Hard to take this article seriously.

disappointed 12/14/04 03:59:03 PM EST

The Internet was initially designed for presenting and sharing hyperlinked documents in the form of Web pages???

R Martin Ladner 12/14/04 05:45:56 AM EST

Consider Macromedia Flash Communications Server for reliable two-way communication between server and client.