Network Computingwww.networkcomputing.com

While we're busy thinning the client (or slowing the fattening up of the once truly thin, but all-too-simple Web GUIs), we're being correspondingly industrious--sometimes against our better intentions--in creating fat server and fat network problems. Even with HTTP 1.1 enhancements, HTTP isn't as efficient as other protocols for downloading a lot of data. When us ed for heavy download situations, particularly over slower- and higher-latency links, HTTP's limitations are more obvious.

It's likely that Web GUI e-mail servers will be more centrally located, but there's no guarantee. So perhaps with messaging, we're not immediately building up a server scalability problem. However, we're likely to see the very users who like to deploy messaging to Web clients become those with more centralized servers. How many Web clients can access a single server simultaneously?

Assuming you find the server that actually has your mailbox data, you'll be downloading a lot to the client from there. JIT data/applet delivery to the desktop may overload the network link to that data location. For example, if the mailbox you're accessing is in your branch office, but you're traveling and coming in via an ISP or corporate PPP dial-up link to the central site, you'll have to be pushed out over slow internal WAN links to the mailbox.

I've seen an analogous situation with cc:Mobile and MS Mail Remote when dial-in servers were placed centrally (IT prefers to manage centralized modem pools), but mailboxes were not centralized. Performance between the dial-in host and remote mailbox (a Windows NT or NetWare drive mapping over a WAN link) was hideous. I've generally recommended putting primarily mobile user mailboxes on more centralized mail servers or putting modems in branch offices. In either case, the mailbox is nearer the dial-in server. When Lotus architected cc:Web (a Web GUI for cc:Mail), a problem occurred there as well--a single centralized cc:Web server was often remote from user mailbox servers and required drive mappings to see these servers. At least it looks like these new Web GUI services will be offered directly by each mailbox server in the later implementations, so HTTP traffic will traverse all links instead of file service drive mappings.

With Webified thin e-mail GUIs the network, if not the server, will become a bottleneck. We haven't seen significant single server scalability testing of e-mail servers with HTTP connected clients--only POP3/SMTP and proprietary/native connectivity. Likewise, we haven't seen significant analysis of the amount of traffic generated by such an approach.

Web GUI: Occasional Use Only? As long as users view the Web GUI for e-mail as an occasional requirement, focused on roaming users and kiosk situations, the server and network load won't be too great. If users don't use messaging much, a Web mailbox might be supportable. But, for medium-to-heavy e-mail users, this approach can only fail to satisfy. A Web GUI certainly should be in the arsenal, but it shouldn't be the only weapon to deploy.

As soon as this approach becomes the only way a user sees e-mail (remember: IT loves terminals), the bottlenecks will become more apparent. Unfortunately, we'll soon see corporations approaching messaging as yet another application to be deployed via Web/HTTP. The Web paradigm is not a panacea. In fact, we're still waiting to see these GUIs c atch up with those of the proprietary clients--ease of use is still a factor.

For some applications (like e-mail), Webification alone will not solve scalability problems. Intelligent application design and appropriate middleware technology (as usual) will be necessary. Web GUIs themselves must get fatter to be more functional--to offer more ease of use, perceived user response time and to somewhat curtail network and server utilization. The more likely applications are applet-based, rather than HTML-based, the more likely we'll end up with better network performance. I guess we'll just have to wait and see.

Application Diet and Nutrition We shouldn't assume that Web GUIs are, by default, better for application scalability--even if one believes that such approaches lead to reduced client software deployment problems. Instead, test such approaches in a network lab to see what they do after the client is JIT downloaded. Developers, do the same. Chatty network traffic characteristics are not thin, even if your client software is.

Dieting doesn't have to mean strict weight loss. After all, if we only lose weight, we'll gain it back. If we think less of getting thin and more of getting fit, we'll end up healthier. Web GUI developers would do well to focus on whole nutritional well-being for their applications, and not fall for the latest Internet diet plan fad.

Bruce Robertson is a program director with the META Group's Global Networking Strategies service. He can be reached at Bruce.Robertson@metagroup.com.