by Bryan Morgan
The purpose of this chapter is to point out the strengths and weaknesses in Microsoft's ActiveX technology. A key point to remember is that with Microsoft Visual J++, the Java developer has two options to play with: pure Java and ActiveX. In other words, the topic of ActiveX and Java is no longer an either/or discussion. Therefore, developers have the responsibility of picking the best tool for the job (which is the way it is supposed to be).
In any fair discussion, nearly every new technology has a set of advantages and disadvantages. ActiveX has been praised by many and criticized by just as many others. (This type of debate usually at least indicates that the technology does something interesting!) Nonetheless, with the advent of the Microsoft Internet Explorer 3.0 browser, the Microsoft Virtual Machine for Java, and Visual J++, ActiveX is going to be around for quite some time. This discussion focuses on the advantages of ActiveX and its benefits for Web programmers. The starting point is that ActiveX enables Web programmers to do some things that they simply cannot do using any other technology. Consequently, ActiveX is often the only game in town.
The ActiveX technologies are all binary technologies. Therefore, unlike Java, they don't require a runtime interpreter that translates bytecodes into machine code. Downloaded components (ActiveX controls) are able to run at true machine speeds, and consequently, ActiveX controls run much faster than comparable Java applets.
A dynamically loaded object can be said to be persistent if that object remains on the local system after it has been used. Although in some instances persistence can be a disadvantage, when ActiveX controls are initially downloaded, they are installed on the local system and remain there. (Future versions of Internet Explorer will allow the user to set defaults that control how ActiveX controls are saved.) The next time the user visits a page containing this ActiveX control, no downloading needs to be done. Instead, the ActiveX control is embedded immediately within the form. Java applets, meanwhile, are only cached on the local file system during the Web browser's current session. The next time the user visits the Web site (after closing the browser), the applet most likely will have to be downloaded again. Downloading an applet may not seem like a big deal, but because many applets inherit and use a wide variety of other classes, many of these additional classes also have to be downloaded. It is not unusual for a single applet to download 50 separate class files before it can be used within the Web page.
Although Java is an extremely exciting technology and may be the language of choice for many in the coming years, ActiveX technologies have been around since 1990. An extremely large base of code currently exists in the thousands of ActiveX controls available on the market today. Because of the component object model (COM) foundation, all OLE controls available before the introduction of ActiveX can be downloaded and used within a Web browser just like ActiveX controls. The primary difference between ActiveX controls and OLE controls is that ActiveX controls are required to implement only one interface: Iunknown. Therefore, ActiveX controls can be much smaller than OLE controls, although in some cases ActiveX controls are no different in size than their OLE counterparts.
ActiveX controls are hugely popular, and an entire industry already exists and thrives on their production and sales. Among the ActiveX controls currently installed on my machine are
Although existing Java applets can perform some of the functionality mentioned above, some of the operations are beyond the scope of Java-applet technology. For instance, it is possible to write a stock ticker Java applet to retrieve stock quotes. However, that applet will be unable to save the data it retrieves to a local file. In addition, many of the available Java spreadsheet and chart classes (to pick some examples) suffer from extremely poor performance and low functionality.
Meanwhile, the market has pretty much sorted out the winners from the losers in the ActiveX control arena. Companies such as Sheridan, Micro-Help, and Visual Components have established excellent reputations for building high-performance, high-functionality ActiveX objects. When you purchase components from these companies, you have some assurance that they will work as advertised.
The following applications can be built with Visual J++ and the controls listed previously:
The Windows Virtual Machine for Java makes all this functionality possible. You may be surprised to learn that even the Microsoft Virtual Machine itself was built as an ActiveX object! Thousands of developers have spent huge amounts of time and money investing in application development using ActiveX components. It is wishful to expect all these developers to simply stop everything they have been doing for the past two years, retool, and begin developing Web-based Java applications. ActiveX acts as a bridge between the two technologies by allowing existing components to be reused while new components are added to applications. These components could be written in Java, Visual Basic, Delphi, C++, or any other language that supports the creation of ActiveX controls.
ActiveX objects have one additional advantage: They can be written
in any language and can be called from any other language.
| Note |
Before continuing with this topic, let me take a moment to define the word any in the world of Microsoft. Developers cannot simply sit down with a FORTRAN compiler and immediately start using ActiveX controls. Instead, the compiler needs to be able to support the linkages between ActiveX and standard code. Likewise, for a language to call an ActiveX object, the compiler must be "ActiveX aware" and support the hooks necessary to dynamically link together ActiveX objects with binary code. |
Under Windows 95/NT, the development tools that control the lion's share of the PC software development market all support the usage of ActiveX controls. As mentioned earlier, this list includes Visual Basic and C++, Delphi, PowerBuilder, FoxPro, and Access. C++, Delphi, and Visual Basic also support the creation of ActiveX controls. Therefore, an ActiveX object written in C++ could be dropped onto a Delphi form (or an HTML page for viewing in Microsoft Internet Explorer). The word object is intentionally used here to mean a programming construct that encapsulates data and methods in an atomic object.
Programs written in Java, meanwhile, can have only limited communication with code written in other languages through the use of native methods. Once these methods are used, Java classes cannot "travel" to remote machines as they do when they are downloaded to a client browser. Because native methods can link only to static object code, Java does not have a way to dynamically update the linked-in code; in contrast, ActiveX objects have such a mechanism.
With the advent of distributed COM (DCOM) in Windows NT 4.0, ActiveX objects also have the capability of communicating with objects located on remote machines. These objects could be placed on other machines for a variety of reasons:
Much attention has been paid to the two-tier design of traditional client/server applications. In this development mode, all display and application logic resides on the client (Web browser containing applets/controls or a normal GUI application), and the database operations reside on the server. Several problems arise with this development paradigm. The biggest problem is that the display code and the application code often become so intertwined that code maintenance is extremely difficult. If a screen needs to be dramatically changed, a huge amount of reworking is involved. Breaking applications into logical portions and distributing these segments across multiple tiers (often called n-tiers) leads to better maintainability, performance, and scalability.
Believe it or not, despite the marketing hype surrounding ActiveX, it does have some real disadvantages. These disadvantages are outlined in an unbiased manner in the following sections.
Microsoft advertises ActiveX as having "cross-platform support." Although versions of ActiveX are being readied for the Macintosh and UNIX operating systems, the fact remains that today ActiveX can be used only on Microsoft's own operating system (Windows). To Microsoft's credit, the COM in no way specifies any vendor- or platform-specific implantation features. However, thus far no one besides Microsoft has stepped forward and built an implementation on top of COM.
A discussion seems to continually rage in the Java newsgroup (comp.lang.java) over whether the words cross-platform even matter. After all, Microsoft owns nearly a 90 percent share of the personal computing operating system market-so who cares about cross-platform? In other words, what good does being cross-platform do you if all of your customers' platforms are the same? This point is extremely interesting, and like all good questions, it doesn't have an easy answer. In an ideal world, individual users could choose their computing environment based on their personal preferences. That is, the software would come to the user, rather than the user being forced to go to the software.
Java itself is not completely above this discussion. Although Java code may be able to run unmodified on virtually any platform, it is unable to interoperate with other parts of the operating system. In a generic Web-centric environment, the Web browser could act as the operating system and applet execution environment. However, this approach excludes all applications that take advantage of operating system features to provide more value to the end user (for example, printing, file access, interapplication data sharing).
Microsoft has announced its intention to develop ActiveX-aware versions of the Internet Explorer browser for the Macintosh and UNIX operating systems. The time frame in which these browsers are introduced combined with the success of the Mac and UNIX ports of ActiveX will play key roles in the success of Microsoft's cross-platform ActiveX strategy.
Java was designed from the ground up to ensure that a client machine running Java code could be nearly certain that the code would not harm the local system. Java applets have no ability to read or write to the local file system or to make any operating system calls whatsoever (a security technique known as sandboxing). No matter who the developer of the Java applet is, a user can download an applet, run it, and never really think about the security implications of doing so. Although no system connected to the outside world via the Internet can ever be 100 percent secure, the Java language and runtime environment go a long way to preventing security flaws.
ActiveX controls, meanwhile, have full system privileges. Once an ActiveX control is downloaded, your Windows Registry may be updated and the component will be installed onto your local system. The ActiveX control is able to perform a directory search of the file system, change video resolutions, reboot your computer, or even grab files and send them over the Internet to a remote server. With these capabilities, no security model on earth will ever make users feel completely comfortable. Microsoft is trying, however, to convince the computer industry and the public in general of the virtues of its ActiveX security model. This model uses a technique known as code signing to verify the contents of ActiveX controls before they are downloaded.
Code signing is provided by an independent software testing facility
(called a certification authority) that tests code to verify that
it does what it says it does. When this software has been tested,
the code is signed using a digital signature, which contains
information that can be examined by software that supports the
Microsoft Trust Verification service (Internet Explorer, for example).
Using this service, a Web browser can determine whether a control
had been modified since being assigned a digital signature. If
tinkering has occurred, the Web browser can alert the user or
disallow downloading.
| Caution |
Keep in mind that ActiveX components, unlike Java applets, do not undergo any runtime verification. Therefore, once the control is installed on a machine, it is free to do whatever it wants. |
ActiveX controls are not required to use code signing. In fact, Internet Explorer 3.0 allows users to control the security level at which they wish to operate (see Figure 19.1).
Figure 19.1 : The Internet Explorer security Options dialog.
Security can mean different things in different contexts. Java is secure in that Java code is unable to access the local operating system when running within a Web browser. ActiveX security, though not as foolproof, can still provide the same level of security that is found today in shrink-wrapped software. Perhaps the biggest problem with ActiveX security is that it leads the public to trust only software produced by the major software manufacturers. A tiny, brand-new software company may have difficulty convincing people to download and run their ActiveX code, especially when a major manufacturer (such as Microsoft) offers a comparable product.
One other disadvantage of ActiveX controls that is often ignored is their size. Going back to the partial list of ActiveX controls currently installed on my machine, the following list shows these controls and their size. Some of these controls are OLE controls; others are actual ActiveX controls, and they are noticeably smaller (the Stock Ticker and RealAudio controls, in particular). The following list illustrates the file sizes of some typical ActiveX controls:
In contrast, the 469 Java classes included in the Visual J++ classes.zip file take up a total of 769KB, or approximately 1.75KB each. Although some applets also download a number of additional classes in order to be interpreted and run, all 469 files in the Visual J++ class library will be included on the local Windows machine as part of the Microsoft Virtual Machine. (In other words, they don't need to be downloaded.) Microsoft has gone a step further with the Visual J++ product and allowed developers to package all of the required class files for an applet together into a single CAB file. This file is compressed on the server side, and the individual class files are extracted from the CAB file as the Java Virtual Machine needs them. Compressing files in this way greatly reduces download time of Java classes.
Some ActiveX controls also require dynamic link libraries (DLLs) and other files to be installed along with the ActiveX control. When these controls are downloaded, an installation routine will often start and install the control on the local machine. Although this process has to be completed only once, it still causes a long enough wait that many users may just cancel the operation altogether. Developers who have built OLE controls should obtain the ActiveX SDK and really look at converting these controls to true ActiveX controls in order to save download time.
As you are probably well aware by now, ActiveX is supported natively only in Microsoft's Internet Explorer 3.0 browser. A Netscape plug-in from nCompass Labs also allows the Netscape Navigator to display pages containing ActiveX controls, but Netscape does not support this product. Through the 4.0 release of the Navigator, Netscape has no plans to add ActiveX support to its browser either. Therefore, if you were to build Web pages containing ActiveX controls or Java applets communicating with ActiveX components (as you will see later in this chapter in the section titled "Combining Java and COM Using Visual J++"), those pages would display properly only within Microsoft Internet Explorer.
As new ActiveX-enabled versions of Microsoft Internet Explorer become available for the Macintosh and UNIX platforms, the situation is sure to change. At that point an overwhelming majority of operating systems would feature support for ActiveX and Java; then all bets are off. However, developers interested in ActiveX should realize that a growing contingent of users are worried about ActiveX's security drawbacks as well as its platform dependence. If you are making development choices, you need to consider all these concerns.
All this jockeying for position in the Web sweepstakes has left many developers' heads spinning. Microsoft continues to release a barrage of related ActiveX technologies with little explanation of the benefits and drawbacks inherent in each technology's usage. What's worse, the real-time nature of the Web has led to the reporting of new features and products before these features are actually solidified.
In the near term, the success of ActiveX will be found in the intranet setting. At the department or division level, software and hardware resources can be quantified and controlled to a much larger degree than the entire Internet. Therefore, organizations that have already chosen Windows 95 or NT as part of their standard desktop should be able to implement ActiveX solutions with relative ease. The advantages of ActiveX really show up in this situation because the department's information services staff can continue to work with the development tools they've been using. Web servers can be set up to provide replication, if necessary, and objects on servers can be updated so that users see the changes in real-time. In fact, existing OLE controls and ActiveX controls can even be reused. At this point the professional developer should look at encapsulating application logic in the form of distributed objects on servers. The user interface can be generated fairly rapidly using standard Web publishing tools. Java can also be used throughout development projects in combination with ActiveX to match the best tool with the job.
On the other hand, ActiveX faces a much more daunting task before it can claim success across the World Wide Web. Because of security concerns and the fact that a large minority of World Wide Web clients are non-Windows machines, most developers voice skepticism about ActiveX on the Internet. As Microsoft demonstrates the effectiveness of its code-signing solution, and as ActiveX is ported to other platforms, ActiveX should slowly gain a larger measure of support than it is currently receiving.
In any case, to reach the lowest common denominator, pure Java is still the best choice for providing active Web applications to the greatest number of clients. Despite its flaws, the Java language and runtime environment were designed with the Web in mind (not retrofitted for the Web after the fact) and contain a number of advantages simply not found in any other technology on the market today. Other chapters in this book (Chapters 25, "Browser Support for Active Content," 26, "HTML and Web Page Design," and 29, "Embedding Components Within Web Pages") demonstrate how to use Java to build applets for display in Web pages. The following example illustrates the use of Java (using Microsoft Visual J++) to build a COM-aware Java applet.
Web developers skilled in Java and COM/ActiveX have the best of the desktop and the Internet at their fingertips. The Visual J++ development tool allows Java programmers to call COM objects using Java code. These COM objects look exactly the same to the developer as every other Java class. In fact, using tools included with Visual J++, actual Java class files are generated for each COM object. These classes can then be imported and used as if they were a standard class.
This "magic" is made possible through the use of the Microsoft Virtual Machine for Java. Microsoft has licensed the JVM specification from Sun Microsystems and has signed an agreement to build the "reference implementation" of the JVM for the Windows platform. Any additions that Microsoft makes to the Windows JVM can be given back to Sun for inclusion in its Java Virtual Machine specification. Unlike the Virtual Machine included with most Web browsers such as Netscape Navigator, the Microsoft Virtual Machine actually becomes part of the operating system after installation. Therefore, it becomes available to all Windows applications. Because it is implemented as a COM object, the Microsoft Virtual Machine can be utilized by any application that supports the same COM interfaces. Thus, objects created in Java can appear as COM objects to other Windows applications. With this provision, Microsoft has elevated Java to the same programming status as its other flagship languages: C++ and Visual Basic.
The javabeep example included with Visual J++ demonstrates a Java class calling a COM object (located in the beeper.dll file). This simple object is used to build a Java applet and application that will beep and print a message each time the user clicks the mouse on the application's client window.
Using the Java Type Library Wizard in Visual J++, standard Java
classes are generated from the COM object's type library.
| Note |
A type library in COM is simply a "definition" file that lists all of the methods, variables, and interfaces supported by the object that the type library represents. A type library is similar in nature to a C++ header file. |
These classes provide a mapping between the variables, methods, and interfaces used in the COM object and the variables, methods, and interfaces in the new Java class. When the Type Library Wizard is finished, two new classes will have been created for your usage in the \windows\java\lib\beeper directory:
To access these two objects (actually contained in the beeper.dll COM library), add the following line of code to your Java applet or application:
import beeper.*;
This line will import both classes in the Beeper package. To create a new beeper object for use within your Java class, the following code is sufficient:
IBeeper m_Beeper = null; É if(m_Beeper==null) m_Beeper = (IBeeper) new Beeper();
Once the object has been created, the following statement will call into the beeper.dll and issue a beep:
m_Beeper.beep();
Programmers with some Java experience will notice that syntactically everything here is standard Java code. The real work is being done at the Virtual Machine level. Figure 19.2 shows the JavaBeep project running as an application.
Figure 19.2 : A Java application calling a COM object.
Figure 19.3 shows the JavaBeep project running as an applet.
Figure 19.3 : A Java applet calling a COM object.
The ActiveX technologies are extremely powerful and have the potential to allow Web-based applications to do things that were previously impossible. You can develop truly interactive, interesting applications using ActiveX controls, ActiveX scripting, and ActiveX documents; HTML and Java applets; and the Web browser as the operating environment. With a tool such as Visual J++, the ActiveX controls can even be built using Java, and Java applets can contain ActiveX controls. This combination provides the professional software developer with the best desktop and Internet technologies.
ActiveX itself has a number of advantages and disadvantages. It has the advantages of being language independent, demonstrating good performance, and having a large existing code base. Some of its drawbacks include its platform dependence (Windows only at the current time), its access to the local operating system, and its limited browser support (Internet Explorer only at the current time).
Microsoft is taking steps to address each of these issues, but many developers are comfortable with the capabilities of Java as it currently exists. To port ActiveX to a small number of desktop operating systems requires an extensive effort, whereas the Java Virtual Machine already exists on nearly every operating platform in use today. ActiveX security (via code signing) requires an independent certification authority (that is, bureaucracy) to certify and verify a control's behavior.
Tools such as Visual J++ allow Java developers to pick and choose among different Java, COM, and ActiveX objects and build applications using the best features of all three technologies. Visual J++ comes with three wizards designed to greatly enhance your productivity as a Java programmer:
These wizards, combined with a visual debugger, online documentation, and excellent development environment, provide an extremely flexible tool that you can use for standard Java programming as well as ActiveX programming.
Over time, the question of whether ActiveX's strengths are enough to overcome its inherent weaknesses will be resolved. Until then, both technologies will probably coexist and continue to improve. This situation will be to the software developer's benefit.