Mobile Code: Java v. ActiveX

Camille LeBlanc, Hialing Jiang, Aylin Kuntay, Kevin Gerson
SIMS 206, Fall 1997
SIMS, UC Berkeley
December 1, 1997

I. Mobile Code

Mobile code is code that can be transmitted across a network and executed on the other end. A mobile code system provides a foundation for mobile agents, which allow you to distribute code and data across clients and servers. A mobile object is a self-contained piece of executable code. Unlike traditional software, mobile code is dynamically loaded and executed by standalone programs, such as Web browsers.

A. Criteria for mobile code

Ideally, a mobile code system will meet the following criteria:

Safe environment for execution: You should be able to control a mobile object's environment, including access to memory, system calls, and server function calls.
Platform-independence: The mobile objects should be able to execute on a variety of operating systems and hardware platforms, since they are transmitted across a network to a variety of users.
Life cycle control: The system should provide a run-time environment for loading, unloading, and executing the mobile code.
Security: The system should guarantee integrity of the code in transit, authenticate clients and servers, and provide means for preventing mobile code from becoming a virus carrier.

B. Advantages of mobile code

Here are some possible advantages of mobile code:

The network becomes distribution vehicle for software applications, reducing software distribution costs and allowing access to many customers.
Eliminates configuration and installation problems of desktop applications
Code is potentially portable to many platforms--write once, run anywhere.
Potentially many active developers, as well as a huge number of possible users.
It enhances the scalability of client/server applications; since the code can be run on the client's machine, the load on the server (which could be a bottleneck) is reduced.
It achieves performance advantages in that once the code is transmitted, subsequent execution of the code avoids network latencies caused by propagation delay; thus, animation and smooth user interaction are possible..
It could bypass the network effects of user-to-user applications by allowing a user of a user-to-user application to provide another user with a compatible piece of the application.
Interoperability of distributed applications is achieved if the distributed pieces of an application originate from a single source and are distributed dynamically as part of the setup through mobile code.

II. Java

Java is several things:

An object-oriented programming language, which defines a virtual machine and a set of libraries.
A portable operating system environment.
A mobile code system, allowing the writing of portable components that can be distributed on the Web.

Java introduces a new model of client/server interaction for the Web. It allows the writing of small component-like programs called applets (mobile objects) that can be downloaded into a browser that is Java-enabled. Applets allow the distribution of an executable, along with data, across the Web. Java applets allow the creation of highly interactive Web pages that have locally executable content. They allow the client to execute code, while the server becomes a storehouse of programs, data, and HTML pages. Java allows you to write an application once and then run it anywhere (i.e., it is platform-independent). Java is supported by both of the major browsers, Netscape Navigator and Microsoft Internet Explorer.

A. Portability

Java is designed as platform independent so that its programs can run on a variety of CPUs and operating systems without modification. This portability is achieved by using a Java "virtual machine". When a Java applet is compiled, byte-code (effectively, machine code for a virtual machine), rather than a standard executable, is created and stored on the server. When a browser requests the applet, the bytecodes are copied to a target client machine. As soon as the byte-codes reach the client, they are run through a verifier, which ensures that the code is safe. The safe code is handed to an interpreter, which is the run-time element that executes the code on the client. Thus, the byte-code can be run on any platform that has a suitable interpreter. The interpretation of the code is about 15 times slower than compiled code to run.

The Java Virtual Machine allows the execution of a program in a platform-independent way. However, Java creates platform-independent applications by providing a set of libraries for standard functions. The libraries must be maintained on each computing platform.

B. Security

The effort to bring active content to the Web raises serious security concerns. Any time you allow a new executable onto your computer, you open yourself up to a possible security risk. Importing code across the network provides opportunities for the transmission of viruses. In addition, an executable that has free reign over your hard drive can wreak all kinds of havoc. To provide tight security across distributed applications, all Java applets run in a "protected space", prohibiting access to the local disk. This is commonly referred to as "sandboxing". Although this does provided good security, it is also limits the applet's flexibility.

Among Java's defenses are the following:

Memory allocation and reference model: The memory layout decisions are not made by the Java compiler, but are deferred to run time. In addition, Java does not support pointers; instead, the Java compiled code references memory via symbolic names that are resolved to real memory addresses at run time. This means that intruders cannot infer the physical layout of a class by looking at its declaration; thus, they cannot forge pointers to memory.
Verifier: Code that reaches the client machine is run through a verifier that ensures that the code is safe.
Access control list: Java uses access control lists that lets the user control read and write access to files by imported code. If an attempt is made by a piece of imported code to access an unauthorized file, a dialog box pops up to notify the user and request access.
Browser's defense: Java-enabled browsers let you set the security mode. You can prohibit applets. You can restrict an applet's access to data that is only on the server from which they originate. You can restrict access only to resources that are outside a firewall.

When a user accesses a Web site that includes a Java applet, the user is granting the program only the following:

access to CPU time
limited space within that allocated to the browser
an area inside the browser's window
the ability to make new windows on the user's screen
access to the user's keystrokes if the user should click on an applet field
the position of the user's mouse when over the applet's window

Applets can only initiate network connections to the computer from which they were downloaded. And they can't directly access your computer's screen or other hardware. The user may also instruct the browser not to run Java applets at all.

The main danger inherent in Java lies in the complexity of the software that implements the sandbox. Because of its complexity, a breakdown is possible. If Java security does break down, the potential consequences are that a hostile program will enter a user's machine and access or sabotage the data at will. It is not currently know whether all of Java's security measures are totally effective.

C. Components

Java applications can be run as standalone programs or as applets invoked by a browser. An applet is not really a complete application. It's really a component that runs within a browser's environment. In this case, the browser acts as a framework for running the Java components (applets). Browsers provide the following framework services. First, the browser controls the applet's life cycle. It supplies the applet with attribute information. And it serves as the main program within which the applet executes (i.e., it provides the main function).

One limitation, however, is that while Java applets provide a simple component model, they cannot interact with each other. However, Sun has defined the JavaBeans specification, which is a model for building components that can be dynamic and interactive.

D. JavaBeans

JavaBeans is the platform-neutral component architecture for Java. JavaBeans extends Java's "write once, run anywhere" capability to reusable component development. The JavaBeans specification defines a set of standard component software APIs for the Java platform. In addition, JavaBeans components interoperate with ActiveX. The JavaBeans Bridge for ActiveX is provided with JavaBeans API suite. It integrates JavaBeans into ActiveX containers, like Word.

JavaBeans have the flexibility to communicate with network objects via CORBA or RMI.

E. Operating system

Java may be considered a new operating system for Internet client machines.

F. Virtual machine

The Java Virtual Machine consists of a bytecode instruction set, a set of registers, a stack, a garbage-collected heap, and an area for storing methods.

III. ActiveX

Unlike Java, ActiveX is not a programming language. Rather, ActiveX is a software component model that provides a specification for how to develop reusable software components that can communicate with each other both across the network or within a single computer. The underlying technology is based on Microsoft's component object model (OLE—Object Linking and Embedding) for the Web environment. ActiveX provides the glue (in the form of a standard interface) for components to communicate with each other, regardless of their implementation language. In addition, the specification allows for communication between controls on different platforms that support ActiveX. Like Java, ActiveX is a system that lets people attach computer programs to Web pages. They both allow Web pages to be much more dynamic and interactive than they would otherwise be.

A. Components

A component written according to an ActiveX specification is called an ActiveX control. A control is analogous to a Java applet but has a much greater access to the operating system, providing more flexibility but at a cost of decreased security. ActiveX controls can be written in different programming languages, such as C++, Visual Basic, or even Java. Objects can talk to one another without knowing the particulars of how each one operates. By contrast, only the Java language is used to create Java applets. An ActiveX module is binary, and will execute and terminate execution on its own. In addition, when a program calls to an ActiveX control, any output sent from the ActiveX control may extend from application to application, even across the Internet.

An ActiveX control can communicate with remote objects only via DCOM. Unlike JavaBeans, ActiveX controls cannot link to CORBA-based applications.

B. Portability

Unlike Java, which has support on various Windows 95 browsers, as well as browsers on other operating systems, ActiveX is platform-dependent. An ActiveX-based application will only run on its target machine and operating system. Although it is possible to package up multiple versions of a control for different platforms so that the correct version will be correctly executed, if the application makes use of any Windows API (application program interface), then the application will require significant porting to execute under any other platform, even if that platform supports ActiveX. Currently, ActiveX is supported only on the Windows operating system (Windows 95 and Windows NT) and is restricted to users running Internet Explorer or Netscape Navigator with an ActiveX plug-in.

C. Reuse

An ActiveX control is a reusable component. ActiveX makes it easier and faster for developers and Web producers to create unique, interactive applications and Web content. Because there are more than 1,500 reusable ActiveX controls already available, Web producers don't have to build all the interactive parts of their Web sites from scratch. And because ActiveX can be used with a wide variety of programming languages, a wide variety of developers can use ActiveX to create compelling content. By providing a common way to extend and link programming languages, ActiveX maximizes developers' resources for interactive Web development. In addition, ActiveX allows easy upgrade capability in that a module maintains different interfaces for each different version of the module, so that older programs relying on an earlier version of the module can continue to use the module without additional programming effort.

D. ActiveX as complement to Java

There is a sense in which ActiveX complements, rather than competes with, Java. ActiveX ties Java applets together with objects created in other languages, so that Java programmers can link to ActiveX controls directly from their Java programs. Similarly, objects written in other programming languages from multiple vendors can link to Java applets. In this way ActiveX doesn't compete with Java, but instead provides a standard way to extend all programming languages, including Java.

E. Security

ActiveX security is based on a completely different approach. Rather than limiting the system resources to which ActiveX controls may have access, ActiveX security prescribes limits for which ActiveX controls can be downloaded to the computer at all. The limitation is based on the idea of a trusted source. ActiveX controls can be digitally signed by the control author, and the signature can be registered with a credential registry. Thus, at least in theory, for any control that is signed and registered, a user can trace the control back to its author in the event of a problem.

ActiveX security thus relies entirely on human judgement. Once the client's browser has verified the signatures, the browser tells the user who signed the program and asks the user whether or not to run it. The user may either accept the program and let it do whatever it wants on the machine or reject the program completely. Thus, ActiveX security relies on the user to make correct decisions about which programs to accept.

The ActiveX model, thus, presumes that program authors that you trust will provide programs that do you no harm and that you will have no need of programs from those that you do not trust. And even if a programmer sends signed code that causes damage, a user cannot be sure of finding the person or even of finding evidence to determine which signature the user should cease trusting.

A dangerous situation arises when the program is signed by someone you do not know anything about. Even if the risk of accepting one program is low, the risk adds up when a user repeatedly accept programs. And there is no limit on how much damage a malicious program can do. The only way to avoid this possibility is to refuse all programs, as a user that directs its Web browser to a Web page that includes an ActiveX object is granting that ActiveX program authority over the entire local computer.

Keep in mind, though, that in certain circumstances security might not be a big issue. For instance, if ActiveX controls are passed within an intranet, all the creators of the controls will be known and trusted. Thus, secutiry might not deter the use of ActiveX.

F. Flexibility

The tradeoff for security, here, as always, is flexibility. Because an ActiveX control has greater control over your computer, it can do more than a Java applet. ActiveX lets you share documents as well as components. For example, an applet cannot create new files or modify old ones. Nor can they read or write files, start other programs, or load libraries.ActiveX's code-signing security system permits local file system access or local OLE links to other desktop programs.

An ActiveX control basically has all the power of a native application, which allows it to take advantage of powerful native APIs. Java, on the other hand, does not immediately offer this capability. Future APIs may improve this situation, but if a program requires access to a low-level system resource, only ActiveX provides the opportunity. However, the cost of using ActiveX is that it locks the application to a single platform.

An example of the power of an ActiveX control is that it could power-down your machine, automatically upload all of your Word documents and publish them in HTML, and instruct Quicken to perform a funds transfer from your bank to another bank without ever asking your permission.

IV. Promises v. Reality

We've seen above what both Java and ActiveX promise to deliver. How do these claims match up to reality?

A. Speed of applications

One interesting fact is that more than two years after its introduction in May 1995, Java is used on less than 1% of Web pages. One of the main reasons is that some Web sites find Java too slow to use (due to the fact that it is 20% interpreted). Moreover, a multimedia Java company (Dimension X) admits that native Windows or Mac programs are much faster and have more features than Java applets. The “run anywhere” Java programs are inherently slower than a Java program written specifically for one platform. In fact, Corel has dropped its plans to rewrite their applications in Java, the CEO noting that it would take two years before Java could compete directly with Windows programs.

B. Platform-independence

Regarding Java's claim that it is platform-independent, PC Magazine ran a test in spring 1997 of several Java programs and found that they would run on only 46% of the machines tested. In addition, moving a Java applet from one operating system to another (from Unix to Windows, for example) requires weeks of tedious work, according to one programmer, because of incompatibilities between virtual machines written for each system.

If Sun is serious about Java being cross-platform and non-proprietary, then it's curious to note that Sun has not handed the development of the language over to an independent body, such as the International Standards Organization, which is a move supported by a growing number of other technology companies. Sun, in fact, rejected an open letter from Microsoft, Digital Equipment Corp., Compaq Computer Corp., and Intel Corp. requesting that Sun turn Java technology over to an open-standards body. Ironically, Microsoft can take the high ground here as a standard-bearer, having itself turned ActiveX over to the Open Group several months ago.

ActiveX is clearly not platform-independent. However, it is not clear that platform-independence matters as much as was once thought. On the one hand, Windows has won the desktop war. On the other hand, the Internet is still heterogeneous, and a mobile object should be able to run on any host machine. It has also been claimed that developers prefer platform-indepence, as they want to feel they are free.

C. Power of applications

Regarding claims about the power of Java programs, it is interesting to note that developers have been able to deliver only very small applications, with limited functionality. There are several reasons for this. First, Java applets require a separate Hypertext Transfer Protocol connection for every class, data, and media file, which means that users have to download applets every time they want to use them. Also, as noted above, since Java was designed to be totally secure, applets cannot access a user's hard disk; this inability substantially limits their size and usefulness. Finally, Java's reliance on HTTP caching has created many version problems because there is no easy way to manage the cache and flush out outdated files.

D. Development tools/Reusable components

Another problem with Java is that is is still new and, thus, lacks many of the class libraries that C++ developers take for granted. The tools for programming Java, such as Microsoft's Visual Java++ and Sun's Java Workshop, are still in their early stages. At the moment, there are hardly any commercially available Java components. Worst of all for a developer is the fact that using Java means abandoning their existing code-base, which is the developer's only asset.

By contrast, ActiveX Controls are just OLE Controls under another name. Millions of Visual Basic, Visual C++, Delphi, FoxPro, and PowerBuilder developers already know how to use them. There are currently more than 1,500 commercially available ActiveX Controls.

At the time Java was introduced there were 4 million Visual Basic developers; 5 months following the introduction of Java there were 200,000 Java developers.

V. Related Links

Java computing: http://www.sun.com/java
Java (in general): http://www.javasoft.com
JavaBeans: http://www.javasoft.com/beans
ActiveX: http://www.activex.com/

VI. Slide Show

View slide show on Mobile Code: Java v. ActiveX