Component Software Meets the Web: Java Applets vs. ActiveX Controls
	By David Chappell Principal, Chappell & Associates

This article originally appeared in Network World, May 1996.

The Web has become an indispensable tool in a remarkably short time. As a way to quickly publish and access information, there's nothing like it. But the best is yet to be -- the Web is coming alive. Developers around the world are creating software components that allow the creation of Web pages with active content.

These developers face a choice, however: Should those components be written as Java applets or as ActiveX controls? Both provide the ability to create active Web pages, and each has strengths and weaknesses. This article compares these two approaches in several key areas.

Components and the Web

Component software, building applications from reusable parts, is an attractive idea. The fundamental notion is to create an application by plugging software components into some kind of container. Those components may be specifically written for this application or, better yet, reused from some other project or even purchased off the shelf. The goal is to create more reliable applications more quickly, and to spend less money doing it. While in many ways much like object-oriented development, components can also offer a bit more than typical object technologies.

Today, Visual Basic is perhaps the most common example of a container, and the components it uses are commonly loaded when needed from a machine's local disk or a file server. But there's no reason other kinds of software can't also act as containers, and file servers aren't the only source for components residing somewhere in the network.

A Web browser like Netscape Navigator or Microsoft's Internet Explorer can also play the role of a container. And components can be loaded not just from the local disk or a file server, but instead from a Web server located on a corporate intranet or on the Internet. We're no longer constrained to downloading into our browsers just dead bits -- text, JPEG files, and such -- but can now load executable code, too. To a user, interacting with Web pages, this allows the creation of Web pages with active content, where, for example, data is downloaded along with the code required to work with that data.

This approach allows much more than just creating Web pages with fancier graphics. By providing a natural interface to downloadable components, then using the Web browser as a container, it's possible to build very useful applications. The provider of a specialized data service, for example, might supply a specialized viewer with that data, allowing a user who accesses the service to manipulate the data in powerful ways. This viewer is a component, one loaded as needed from the network, that runs inside the container provided by the Web browser.

One way to create Web pages with active content is to embed executable scripts in HTML-defined Web pages. JavaScript allows this, as does Microsoft's Visual Basic Script. For more complex components, however, these relatively simple tools won't suffice -- something more powerful is required. The two most visible technologies for building powerful, downloadable components are Java applets and Microsoft's ActiveX controls (formerly called either OLE controls or OCXs).

How Java Applets Work

The term Java is commonly used to refer to distinct but related things. Java is a programming language, in many ways a simpler (and to many, a better) C++. Java also defines a number of standard APIs, allowing generic access to things like a graphical user interface and other system services.

It's entirely legitimate to write stand-alone applications using Java. So far, however, most of the considerable excitement around this new language environment has focused not on Java applications, but rather on Java applets. An applet is a software component that typically runs inside some kind of container. By far the most common example of a container for Java applets is a Web browser like Netscape Navigator.

When a Java applet is downloaded from a Web server, it sends a partially translated version of the applet program, expressed in the Java byte code, to the browser. The browser contains an implementation of the Java virtual machine, software that's capable of executing the byte code instructions. The browser also has a standard set of class libraries that the applet can trust will be there. The virtual machine executes the applet, and the user sees the result.

How ActiveX Controls Work

Like Java applets, ActiveX controls are self-contained pieces of functionality that run inside some kind of container. And as with Java applets, a Web browser is a good choice for that container, allowing ActiveX controls to be embedded in Web pages and downloaded on demand.

Unlike Java applets, however, ActiveX controls can be written in various languages (in fact, it may at some point be possible to write ActiveX controls in Java), although the most common choice today by a wide margin is C++. Also unlike Java applets, which are downloaded in a machine-independent format and usually interpreted within the browser, ActiveX controls are binaries. The typical target system for an ActiveX control is, not surprisingly, an Intel-based machine that supports the Win32 interface, which generally means that it's running Windows 95 or Windows NT.

How do ActiveX controls compare with Java applets? How can a developer decide which one to use? Answering these questions requires looking at both technologies from a number of different perspectives.

Containers

Components by definition can't survive on their own -- they require some kind of container in which to execute. Java applets today are supported primarily by only one kind of container: Web browsers. Netscape's browser currently supports Java applets, and Microsoft's soon will.

ActiveX controls, on the other hand, are supported by all kinds of containers. Microsoft changed the name from OLE controls to ActiveX controls to emphasize their newly added Internet-related capabilities, but whatever they're called, they remain the largest component market by far.

Many organizations offer a plethora of different ActiveX controls, most currently unrelated to the creation of active Web pages. A casual perusal of the ads in any magazine aimed at Visual Basic programmers will yield controls implementing spreadsheets, mainframe connectivity, voice recognition, and much more. Despite being created with other environments in mind, many of these existing controls are capable of being downloaded and executed within an ActiveX-capable browser. This means that there's an instant supply of available ActiveX components for creating active Web pages. And unless more containers emerge that are capable of hosting Java applets, those applets are destined to remain cordoned off in the Web browser ghetto. It's a not a bad place to be, to be sure, but it is a limited part of the picture.

Platform Independence

Java applets are platform independent -- the same applet can run on any system that supports the Java environment. ActiveX controls are not -- they generally run only on Windows/Intel systems (although Microsoft is making noise about someday allowing the creation of ActiveX controls in Visual Basic or Java, then interpreting them on all kinds of clients).

Implicit in a debate about platform independence is a debate about compilation vs. interpretation. Java applets are platform independent because they're typically interpreted, which means that the applets' code is executed by the Java virtual machine rather than directly by the underlying hardware (although just-in-time Java compilers might change this by compiling an applet's byte code on arrival). In general, interpreted applications run on the order of 10 times slower than compiled applications. Does this matter? It depends. As processor speeds increase, this difference may be less and less significant. Still, imagine how happy your users would be if all their applications suddenly ran 10 times slower than they do today.

Ultimately, the importance of platform independence hinges on the target environment. An independent software vendor focused on the Web and writing for the largest possible market may well choose to create Java applets, since they're guaranteed to run on anything, no questions asked. A developer in an organization with all or even mostly Windows/Windows NT clients may instead opt to create ActiveX controls for the reasons cited above: performance and the ability to run in many kinds of containers, not just in browsers.

Security

Users download code from networked servers all the time -- that's what file servers are for. When the code is downloaded from a Web server, though, the picture gets murkier. Loading a component from a Web server that's part of an internal intranet really is no different than loading it off an internal file server. Loading the component off some Web server on the Internet, however, is quite different and introduces much more risk.

There are three fundamental approaches to security for components loaded from Web servers. The first is the one just mentioned: trust the server. Some well-managed Web servers, like those on a secure corporate intranet, can be trusted not to deliver components that contain viruses or do other kinds of damage to the system on which they're loaded and executed. Today we trust our corporate file servers to do this very thing, so it doesn't seem unreasonable to place this same faith in internal Web servers.

A second approach is to constrain the components themselves, making it impossible for them to execute functions that might do any damage to the local system. Commonly called "sandboxing" (because downloaded components are obligated to play only in their own sandbox), it can guarantee security. The downside of this approach is that sandboxed components are prohibited from doing things that can sometimes be useful, like writing to a file on the client machine's local disk.

The third and in some ways most attractive approach is to digitally sign each downloaded component. The digital signature can be checked by the browser that receives the component. If it's correct, the browser can be certain that the component was created by a specific trusted entity (such as Lotus or Microsoft or your organization's internal development staff) and that it hasn't been modified.

Java applets currently support the first and second of these methods. Like any piece of code, they can be downloaded from a trusted server, and Java applets are wonderfully designed for sandboxing. By running all applet code through a verifier, the Java environment can all but guarantee that a downloaded applet won't step outside its defined limits to wreak havoc on the machine.

ActiveX controls, on the other hand, currently support only the first of these three methods: downloading from a trusted server. Since they're shipped to the client as binaries, then directly executed, it's hard to see how sandboxing would be possible with ActiveX controls. Still, there are times when allowing a downloaded component access to, say, the local disk can be a useful thing, so sandboxing isn't appropriate for all applications.

Both the Java and ActiveX camps are working on techniques to allow digital signatures on downloadable components. Sadly, the two groups aren't working together. Digital signatures offer the most general solution to the problem, one that would work well with both technologies, and having completely different techniques for Java applets and ActiveX controls makes no sense. Let us hope that a single standard can be created that will be usable with both.

Making a Choice

Both Java applets and ActiveX controls will exist into the foreseeable future. The leading browsers, Netscape Navigator and Microsoft's Internet Explorer, will support both. But for organizations building component applications using browsers as containers, it's really not all that difficult to decide which technology to use.

If a component must run on different kinds of client systems, and if the limitations imposed by sandboxing are either acceptable or outright desirable, then building that component as a Java applet makes sense. An example of this kind of component might be a customized data viewer, like the one mentioned earlier, that will be distributed over the Internet to a diverse set of clients. Support for heterogeneous platforms is essential here, as (probably) are the security and concomitant limitations imposed by sandboxing.

If, on the other hand, the component is targeted at Microsoft systems, doesn't require sandboxing, must run as efficiently as possible, and is useful in a wider range of containers than just Web browsers, ActiveX controls are the technology of choice.

An example here might be a component performing specialized mortgage calculations that's sold to financial institutions. In many markets it's a safe bet that the clients run Windows or Windows NT. And since this component is sold rather than distributed freely over the Internet, it will likely be loaded from trusted servers within the buyer's intranet, obviating the need for sandboxing. And finally, a component like this is quite likely to be useful in many different kinds of applications built using many kinds of containers, not just with Web browsers.

Building applications from existing components is a good idea. Allowing those components to be accessed and loaded over the Web is an even better idea. And having two technologies that address this area, technologies that both compete with and complement one another, is likely to make both technologies better over time. As Martha Stewart would say, it's a good thing.

David Chappell was featured at the OSF DCE Users & Developers Conference.