| DCOM Explained by Rosemary Rock-Evans Digital Press ISBN: 1555582168 Pub Date: 09/01/98

Previous | Table of Contents | Next

Web pages and Java

Java is a combination of a programming language and an environment for executing that language, called the Java Virtual Machine. Because no operating system is assumed, each Java Virtual Machine has to use Sun’s Abstract Windowing Toolkit (AWT). The Abstract Windowing toolkit is a windowing system and defines the way the user interface looks on the Internet. It includes a set of desktop widgets that it believes to be common to all platforms—Sun, Macintosh, Windows, and so on. The Java interface will thus not be the same as the one the user uses when the Internet is not used.

The developer “compiles” the Java language, and the virtual machine then interprets these instructions at runtime. The aim of this approach is to ensure that Java programs can run on any operating system or hardware. Compiled Java programs can be run wherever a Java virtual machine runs, providing “instant portability” for any compiled Java program.

You may have frequently heard the expression “write once, run anywhere” used with respect to Java. Of course, the run anywhere capability depends on the existence of the Java Virtual Machine on that platform, and versions have not been developed for every platform. But they do exist for Windows and various flavors of Unix (Solaris is an obvious one).

Java programs which run in a browser are called applets. As we have seen, Web pages normally contain HTML and pointers (URLs). In order to accommodate Java, HTML has been modified to include tags that identify the Java code to be run and any arguments passed to it. What makes Java so special, however, is that when a page that points to a Java applet is down-loaded, not only is the page downloaded to the client machine, but the Java applet is downloaded along with it.

This has obvious benefits. Using this approach, the IT department can always be sure that the user has the most up-to-date software on the client and has no need to continually distribute and update client software. It also means that a casual user can access and use your applications.

Applets are intended to be small, easily downloaded parts of an overall application.

When we say small, we mean small. If the user is accessing your applications across an external line as opposed to an internal network, even a medium-sized applet could take forever to download. The bulk of Internet connections to end users are still either 14.4 Kb or 28.8Kb serial lines. Assuming a generous actual average bandwidth of 2K bytes/second, even a 100K applet will take 50 seconds to download!

If you have an internal network, of course the problems may not be the same, but you probably don’t want to have to write two versions of an Internet-based application—one for internal Internet use and one for external use. So on the whole, the rule is keep them really small.

Once the page is downloaded, the Web browser activates the Java classes, which then become an autonomous program running from within the confines of the Web browser. This concept of confinement is important to the whole way Java works and is worth a mention.

Once the Java applet starts working, it is allowed to work only within what is called its sandbox. A sandbox (where it can play!) is limited to the environment of the Web browser. The applet can’t access the client files or external memory or muck about with code on the client machine interacting with existing applications or even applets on the client machine.

The Browser software and JVM prevent (or should prevent) access by applets to any resources on the client upon which it is running, and the applet is usually destroyed when the page is flushed from cache. Furthermore, Java applets cannot listen on a network for requests or open a network connection to any IP address other than the one from which the applet was downloaded.

The reasons should be obvious. If it is this easy to download software without the user’s being aware software has been downloaded, the user is very vulnerable. A less scrupulous Web page designer may (if no restrictions are in place) send the poor hapless individual viruses, applets which read files and report on them, applets which steal data from files—anything really. The poor end user could be totally unaware that a rogue applet was wandering his or her hard disk. By having a restricted model of access, the user has some level of protection from the unscrupulous designer.

Previous | Table of Contents | Next