IN THE MIDDLE

The Web: Dumb Terminal And Dumber File Server

by Bruce Robertson

According to a Sun document I came across online ( http://www.sun.com and http://java.sun.com ), BusinessWeek thinks that Java is a programming language that will "turn the Internet into a giant disk drive." I can't wait.

Of course, the whole Web phenomenon is in many ways a new kind of document-specific file service. Each HTML page is just transferred to your screen via your HTML browser from a big disk out on the Internet. The Web server is just a new kind of file server. It serves up .htm inste ad of .doc files. Now with Java, it will serve up .jav files instead of .exe and .dll files. This is one reason Novell might turn out to have a successful Web server; Novell has done file service better than anyone else so far.

Unfortunately, all the parts of a single document--the HTML text file, multiple GIF or JPEG pictures, the Real Audio clip and so on--are stored separately on that disk. The Web desperately needs a compound document solution. I'm tired of posting five files to a server when it only took one in Microsoft Word.

The Web is certainly more like a file service than terminal emulation or X Window, despite the fact that many people now view the Web as the next greatest dumb terminal option for corporate applications. Attempts to make the Web more interactive are still being fleshed out (hooking Web servers to databases, adding server program process ing and so on). My general advice to those who think we can get back to terminals of any kind is this: Remember client/server . The Web isn't going to kill Windows. It'll just change the way that some applications are deployed.

Nevertheless, it is this Web server as file server that scares me. And, it should scare you. Particularly if you're thinking Java is the next best thing since sliced bread. It's not. Instead, with Java the Internet will gain weight. Because of this, the Internet will also gain wait.

Java Gets Bigger I checked out the CADIS demo ( http://www.cadis.com ) showing Java in client/server mode. I'll talk more about that in my next column, when I begin to discuss the more specific middleware implications of Java. For now, though, I have a more fundamental problem with Java: Serving up application executables over the Internet this way just won't work.

Witness my CADIS connection. First of all, it downloads a 510-KB file to my local machine. Now there's a low-calorie meal! Even with my 64-Kbps ISDN connection, it took at least a minute befor e anything other than "Krakatoa Search Engine Starting" displayed on my browser. Over a 14.4-Kbps or 28.8-Kbps dial-up connection, will anyone wait? I personally can't even stand home page graphics over 50 KB at typical async speeds. Frankly, anything that takes more than five to 10 seconds to show up has lost my interest. I've already forgotten what I asked for by that time. Studies have been done on this human factor issue: People don't wait.

What was eventually displayed wasn't great either: The demo mentions that there are known display problems on Windows95 and Netscape 2.0. Where's the cross-platform support we've been told to expect? Is this just a problem with the Java interpreter in Netscape's Windows95 browser? Let's assume that--programmers being programmers--this will be fixed very soon. I worry about things much harder to fix--like the entire Internet infrastructur e.

The Internet doesn't always work, does it? Who knows how many hops are between you and the server you're trying to reach? Sometimes you get connections quickly, but sometimes it takes a long time--even to the same host. Sometimes there's a problem somewhere along the line (overloaded router, line failure and so on) that's simply made a commonly used resource unavailable, for a while. Maybe it'll work later. And maybe it won't.

The Internet may be many things to many people, but a reliable network it is not. Can you run a business (or even live as an individual consumer) with a fundamentally unreliable and ultimately unmanaged network as the basic platform? The Internet is a playground for most. If it rains, you can't play.

After we all get over the fact that it's so cool to see all the different front pages, we settle down to wanting to do things regularly. And we expect a level of service. We're no longer just browsing. We're using or even buying.

Also, many sites haven't scaled up to handle the many connections users are throwing at them. Check out the Microsoft or ESPN et.SportZone.com sites--they're always slow. I don't wait in lines at stores much (except when forced to around Christmas). I go to another store or I don't buy at all.

The Internet Makes Me Wwwwait Now you're telling me that every site will need to send me a large Java applet each time I connect? I'm not looking forward to waiting longer for that fat content. Instead of energizing the Net with a bolt of caffeine, Java will act like a depressant, and will bog down the whole thing: not only at the servers, not only on the Internet's backbone (or your ISP's backbone), but even at the user's own link.

Java applets are going to be too big for the real Internet. It's fine for researchers with Sun boxes on Ethernets in the universities to get excited. Sitting here--still waiting for the download--I'm thinking Java is not worth the time it's going to take to experience it online.

Distributing Java Applets Java is certainly beginning to sound like it'll make the W eb server into what we now comfortably know as a NetWare file server with lots of Windows DLLs on it. But, in this case, we're expected to have one server somewhere, a huge number of hops away, that has the only copy of the DLL we need to retrieve--and we should retrieve it over our 28.8-Kbps dial-up line. Maybe we can call this dumb file service, as opposed to dumb terminal emulation.

To save the Net from Java, someone's going to have to figure out how to keep users from downloading the same Java applet every week or every day, even when the applet hasn't changed. All this local caching and even the new Web page-explicit local copiers can't cope with multiple 100-KB to 1-MB "applets" needing to be downloaded. What size disk must a local user have? Can the caching approach be handled by more local servers in an ISP?

Today we only think of the Web as an interactive data access mechanism, not as an interactive program distribution mechanism. Java will change this. It makes the We b into even more of a file server.

I think of this every time I try unsuccessfully to connect to Microsoft's site to download the latest copy of Internet Explorer. At least Netscape has about 20 sites from which to download code. Did you ever wonder how to figure out which site might in fact be closest to you? When I connect to PSI in Texas and try downloading from the Netscape Texas mirror site, is the 2.5-MB Netscape ZIP file going through PSI's central hub in Washington, D.C., or does the traffic stay in Texas? It matters.

Partitioning the Web For the Internet to be able to keep traffic localized or partitioned, data--and now programs--must be distributed closer to the end users. ESPNet should be in lots of places, not just one. We can't just say we will throw bandwidth at these problems. We will never have enough bandwidth (or at least we will never have enough money to pay for enough bandwid th).

Moreover, a directory service that would make distribution and repl ication transparent to the user is a requirement. Lotus Notes has location-independent doclinks along with replicated data stores. Clicking on a doclink takes the user to the most local copy of the referenced data. This is useful infrastructure--infrastructure the Web will require to scale.

Without it, URLs will always be hardcoded to specific physical locations. Users won't realize there's a closer copy of the data they want. Therefore, bytes will again flow needlessly across the Net. What a waste.

Moving Beyond the Buzz There's so much about the Web and the new fave buzz-thing Java that won't scale well. Why isn't Novell, for example, making more noise about using NDS to manage user accounts across multiple Web servers for single sign-on and simplified administration? Now, managing users of multiple Web servers is like managing too many NetWare 3.x servers--all separately. Why isn't Oracle touting its replication technology as the underpinning of its Web offerings? Developers are driving Web technology now; deployers and, more importantly, users are going to suffer from their myopia.

Yeah, Java is really cool technology. But it's going to make things worse before it makes things better. In the meantime, think of Java as just a programming language. Don't think of it as the future of the Net. The future of the Net will require technology with less glitz and more guts. It will require a serious distributed infrastructure overhaul.

I can't wait.

Bruce Robertson can be reached at brobertson@nwc.com.

April 15, 1996