中国IT动力,最新最全的IT技术教程
最新100篇 | 推荐100篇 | 专题100篇 | 排行榜 | 搜索 | 在线API文档
首 页 | 程序开发 | 操作系统 | 软件应用 | 图形图象 | 网络应用 | 精文荟萃 | 教育认证 | 硬件维护 | 未整理篇 | 站长教程
ASP JS PHP工程 ASP.NET 网站建设 UML J2EESUN .NET VC VB VFP 网络维护 数据库 DB2 SQL2000 Oracle Mysql
服务器 Win2000 Office C DreamWeaver FireWorks Flash PhotoShop 上网宝典 CorelDraw 协议大全 网络安全 微软认证
硬件维护  CPU  主板  硬盘  内存  显卡  显示器  键盘鼠标  声卡音箱  打印机  机箱电源  BIOS  网卡  C#  Java  Delphi  vs.net2005
  当前位置:> 程序开发 > 编程语言 > Java > 测试
Why Web Applications Can be Problematic and Unreliable @ JDJ
作者:未知 时间:2005-08-10 22:33 出处:Java频道 责编:chinaitpower
              摘要:Why Web Applications Can be Problematic and Unreliable @ JDJ

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.

关闭本页
 
首页 | 投资与合作 | 服务条款 | 隐私政策 | 收藏本站 | 设为首页 | 新用户注册 | 免责声明 | 使用帮助
Copyright ©2005-2008 chinaitpower.com All rights reserved. www.chinaitpower.com 版权所有