by Michael Morrison
With the full force of Microsoft behind it, it's no surprise that ActiveX has received tons of press attention lately. As an Internet developer, you probably have some degree of confusion about how ActiveX fits into the Internet landscape. More specifically, you may be worried about what impact ActiveX will have on Java. This chapter takes a close look at Java and ActiveX and where each fits in the world of Internet development. This chapter also dicusses an ActiveX technology that enables the integration of Java and ActiveX.
The goal of this chapter is to give you some perspective on the relationship between Java and ActiveX. In doing so, you learn the details surrounding what each technology offers and why they don't necessarily have to be viewed as direct competitors. You also learn about a specific technology that aims to allow Java and ActiveX to happily coexist.
In a general sense, Java and ActiveX both try to achieve the same goal: to bring interactivity to the Web. Because this is a very general goal, you probably realize that many different approaches can be taken to reach it. Java and ActiveX definitely take different routes to delivering interactivity to the Web, and for good reason-they're widely divergent technologies that come from two unique companies. Let's take a look at each technology and see what it accomplishes in its quest to liven up the Web.
First and foremost, Java is a programming language. It certainly is other things as well, but the underlying strength of the Java technology is the structure and design of the Java language itself. The architects at Sun wanted to take many of the powerful features in C++ and build a tighter, easier-to-use, and more secure object-oriented language. They succeeded in a big way: Java is indeed a very clean, easy-to-use language with lots of advanced security features. The time spent designing the Java language is paying off well for Sun because the language's structure is the primary cause of the C++ programmer migration to Java.
However, the Java language without its standard class libraries and Internet support would be nothing more than competition for C++. In fact, the Java language, as cool as it is, would probably fail in a head-to-head match with C++ strictly from a language perspective. This is because C++ is firmly established in the professional development community, and programmers need a very compelling reason to learn an entirely new language. Sun realized this, and was smart enough to present Java as much more than just another programming language.
The basic Java technology consists of the Java language, the Java class libraries, the Java runtime system, and the JavaScript scripting language. It's the combination of all these parts that makes the Java technology so exciting. Java is the first large-scale effort at creating a truly cross-platform programming language with lots of functionality from the start. Couple the slick language and cross-platform aspects of Java with its capability to seamlessly integrate Java programs into the Web environment and you can easily see its appeal.
This integration of the Web into the Java technology is no accident; Sun simply saw the potential to capitalize on a technology they had been developing for a while by fitting it to the rapidly growing needs of the Internet. This pretty much sums up the primary aim of Java: To provide a means to safely integrate cross-platform interactive applications into the Web environment using an object-oriented language. Keep in mind, however, that new innovations such as JavaOS and Java microprocessors are rapidly altering and expanding Sun's vision of the Java technology.
Microsoft has different ideas for the Internet than Sun. Unlike Sun, Microsoft initially didn't realize the immediate potential of the Internet, or at least didn't see how fast it was all happening. In fact, it wasn't until the excitement surrounding Java had begun to peak that Microsoft finally decided they had to rethink things in regard to the Internet and the Web.
The connection was finally made somewhere in Redmond that the Internet would significantly affect personal computing. They couldn't just sit idly by and see what happened; they could either take action to capitalize on the Internet or get burnt by not accepting it as a major shift in the way we all use computers. When Microsoft finally came to terms with the fact that the Internet was rapidly changing the face of computing-even personal computing-the company quickly regrouped and decided to figure out a way to get a piece of the Internet action. Keep in mind that Microsoft has never been content with just a piece of the action; they want the largest piece of the action!
Unlike Sun, Microsoft already had a wide range of successful commercial software technologies; they just had to figure out which one of them would scale best to the Internet. It turned out that one of their most successful technologies was ideally suited for the Internet: OLE (Object Linking and Embedding). They saw OLE as a powerful, stable technology with lots of potential for the Internet, and they were right; ActiveX is basically OLE revamped for the Internet.
Unlike Java, however, ActiveX isn't meant to be just a way to add interactivity to the Web. Sure, that's part of it, but Microsoft isn't the type of company to just hand out technologies for the good of humanity. OLE is a technology deeply ingrained in most of Microsoft's commercial products, as well as many other commercial Windows applications. By simply migrating OLE to the Internet (through ActiveX), Microsoft effectively assumes a huge market share of Internet products overnight. Suddenly, every piece of code written based on OLE can now be considered ActiveX-enabled with little extra work. Microsoft's new goal of migrating desktop software to the Internet suddenly looks quite attainable.
Although Microsoft is certainly looking to bring interactive applications to the Web with ActiveX, they are also looking to make sure that many of those interactive applications are Microsoft applications. This situation also ensures that Windows remains a strong presence on the Internet because OLE is essentially a Windows-derived technology. Although strategically ideal, the selection of OLE as the technological underpinnings for ActiveX has much more to do with the fact that OLE is a slick technology already tweaked for distributed computing; it's just the icing on the cake that OLE is already firmly established in the PC software community.
Microsoft isn't the only company to benefit from the positioning of ActiveX. Every PC software developer that uses OLE in its applications will benefit from ActiveX just as easily as Microsoft. Because the PC development community is by far the largest in the industry, end users also benefit greatly because many software companies will be building ActiveX applications from existing OLE code that is already stable.
In the discussion of ActiveX thus far, little has been said about programming languages. Unlike Java, ActiveX has nothing to do with a specific programming language; you can write ActiveX code in any language you choose that supports Microsoft's COM specification. Just in case you don't realize it, this is a big deal! Although Java is a very cool language, many programmers don't like being forced to learn a new language just to exploit the capabilities of the Internet. On the other hand, writing ActiveX controls in C++ is a little messier than writing Java applets in Java.
Okay, so you have an idea about what each technology is trying to accomplish-but what does each actually deliver? It turns out that Java and ActiveX are surprisingly different in their implementations, especially considering how similar their ultimate goals are.
The Java technology can be divided into four major components:
The Java language provides the programmatic underpinnings that make the whole Java system possible. It is the Java language that shines the brightest when comparing Java to ActiveX. The Java class libraries, which go hand in hand with the language, provide a wide array of features guaranteed to work on any platform. This is a huge advantage Java has over almost every other programming language in existence. Never before has a tight, powerful language been delivered that offers a rich set of standard classes in a cross-platform manner.
The Java runtime system is the component of Java that gets the least press attention, but ultimately makes many of Java's features a reality. The Java runtime system includes a virtual machine, which stands between Java bytecode programs and the specific processor inside a computer system. It is the responsibility of the virtual machine to translate platform-independent bytecodes to platform-specific native machine code. In doing so, the virtual machine provides the mechanism that makes Java platform-independent. Unfortunately, the virtual machine is also responsible for the performance problems associated with Java. These problems will go away, however, as just-in-time Java compilers evolve to become more efficient.
The JavaScript scripting language is the Java component that allows you to embed scripted Java programs directly into HTML code. The primary purpose of JavaScript is to allow Web developers who aren't necessarily programmers to add interactivity to their Web pages in a straightforward manner.
The ActiveX technology can be broken down into the following major components:
ActiveX controls are self-contained executable software components
that can be embedded within a Web page or a standalone application.
Acting as an extension to OLE controls, ActiveX controls can be
employed to perform a wide range of functions, both with or without
specific support for the Internet. ActiveX controls are essentially
Microsoft's answer to Java applets, although ActiveX controls
are significantly more open-ended than Java applets.
| Note |
Although ActiveX controls are similar to Java applets, ActiveX controls are true software components. Java Beans components, when they become available in the very near future, will be the closer Java equivalent to ActiveX controls. |
Whereas ActiveX controls are Microsoft's answer to Java applets, VBScript is Microsoft's answer to JavaScript. Built on the highly successful Visual Basic programming language, VBScript provides much of the same functionality as JavaScript, but in an environment already familiar to many PC developers.
ActiveX documents are similar to ActiveX controls, except that they are focused on the representation and manipulation of a particular data format, such as a Word document or an Excel spreadsheet. There is no logical equivalent in Java to ActiveX documents; ActiveX documents are a piece of the ActiveX technology that is completely foreign to Java.
The final component of ActiveX is the ISAPI scripting language and server support. ISAPI provides a more powerful answer to CGI scripting, which has long been used to provide pseudo-interactivity for Web pages. ISAPI even goes a step further by providing a means to build filters into Web servers. Java servlets will eventually provide a similar functionality as ISAPI scripting.
By now, you not only understand what Java and ActiveX are trying to accomplish, but you have a good idea of how each is going about delivering on its promises. I've mentioned some of the differences between each technology while describing the relevant aspects of them, but it's time to dig in and take a look at what these differences really mean.
Although ActiveX as a technology delivers a little more than Java does as far as the individual components, the primary interest for most developers is how ActiveX and Java stack up from the standpoint of adding interactivity to Web pages. This question forces you to analyze the differences between ActiveX controls and Java applets because those are currently the primary aspects of each technology that deliver Web page interactivity.
Probably the most significant divisive issue between ActiveX and Java is security. No one argues the fact that security is an enormous issue when it comes to the Internet. Both Sun and Microsoft saw the importance of security and took appropriate actions in designing their respective technologies. However, they each took a different approach, resulting in drastically different usage issues. You already learned about some of these security issues in Chapter 35, "Java Security," but I'm going to go over them again briefly here because they are so critical in the discussion of Java and ActiveX.
Let's first consider Sun's approach to security: Java's security consists primarily of verifying the bytecodes as a program is being interpreted on the client end. It also does not allow applets access to a client user's hard drive. The first solution of verifying bytecodes, although imposing somewhat of a performance hit, is reasonable. However, the limitation of not being able to access the hard drive is pretty harsh. No doubt, Sun took the safest route-it's very unlikely that anyone can corrupt a user's hard drive using Java, considering that you can't access it. Because of this limitation, it's also equally unlikely that developers will be able to write Java applets that perform any significant function beyond working with data on a server.
Now consider Microsoft's security approach with ActiveX: ActiveX employs a digital signature attached to each control; the signature specifies the original author of the control. The signature is designed so that any tampering with an executable after its release invalidates the signature. What this means is that you have the ability to know who the original author of a control is, and therefore limit your use of controls to only those written by established software vendors. If someone hacks into a control developed by an established vendor, the signature protects you. Granted, this approach pushes some responsibility back onto the user, but it's a practical reality that freedom never comes without a certain degree of added responsibility.
When it comes to security, I think Microsoft has capitalized on what a lot of people are starting to perceive as a major flaw in Java. For the record, Microsoft implemented the signature approach in ActiveX after the release of Java, meaning that they had the advantage of seeing how Sun tackled the security issue and were then able to improve on it. There is nothing wrong with this, it's just an example of how every technology, no matter how powerful and popular, is always susceptible to another one coming along and taking things a step further.
Before you think that Microsoft has won the security issue, let me add that Sun is in the process of adding an extensive digital signature model to Java. Digital signatures will more than likely lift the tight security restrictions on Java applets and put the security issue for both technologies on common ground.
Even though I've presented Java and ActiveX as competing technologies in a lot of ways, please understand that I don't see Java and ActiveX as an either/or proposition. The software development community is far too diverse to say that one technology surpasses another in every possible way. In addition, consider that both of these technologies are in a constant state of flux, with new announcements and releases popping up weekly. In my opinion, it's foolish to think that a single software technology will take the Internet by storm and eliminate all others. Java will naturally find its way to where it is best suited, as will ActiveX. Likewise, smart software developers will keep up with both technologies and learn to apply each in cases where the benefits of one outweighs the other.
And in case you're getting nervous about having to learn two completely new types of programming, here's some reassuring news: Microsoft has released a technology that allows developers to integrate Java applets with ActiveX controls. What does that mean? Well, because ActiveX is language independent, you can write ActiveX controls in Java. Furthermore, it means you can access ActiveX controls from Java applets and vice versa. To me, this is a very exciting prospect: the ability to mix two extremely powerful yet seemingly divergent technologies as you see fit.
The technology I'm talking about is an ActiveX control that acts as a Java virtual machine. What is a Java virtual machine? A Java virtual machine is basically a Java interpreter, which means it is ultimately responsible for how Java programs are executed. By implementing a Java virtual machine in an ActiveX control, Microsoft has effectively integrated Java into the ActiveX environment. This integration goes well beyond just being able to execute Java applets like they are ActiveX controls; it provides a means for ActiveX controls and Java applets to interact with each other.
Microsoft's willingness to embrace Java as a means of developing ActiveX objects should give you a clue about the uniqueness of each technology. It could well end up that Java emerges as the dominant programming language for the Internet, while ActiveX emerges as the distributed interactive application standard. I know this seems like a confusing situation, but it does capitalize on the strengths of both Java and ActiveX. On the other hand, the Java Beans component technology could emerge as a serious contender on the component front and give ActiveX some competition.
The main point is that ActiveX and Java are both strong in different ways, which puts them on a collision course of sorts. The software development community is pretty objective; if programmers can have the best of both worlds by integrating ActiveX and Java, then why not do it? No doubt both Sun and Microsoft will have a lot to say about this prospect in the near future. The ActiveX Java virtual machine is a major step in the right direction.
As you just learned, the ActiveX Java virtual machine (VM) control allows Java programs to run within the context of an ActiveX control. What does this really mean from the perspective of a developer wanting to mix Java and ActiveX? It means you can treat a Java class just like an ActiveX control and interact with it from other ActiveX controls. In other words, the Java VM control gives a Java class the component capabilities of an ActiveX control.
You now understand that Java classes and ActiveX controls can interact with each other through the Java VM control, but you're probably still curious about the specifics. One of the most important issues surrounding Java's integration with ActiveX is the underlying Component Object Model (COM) protocol used by ActiveX. COM is a component software protocol that is the basis for ActiveX. The importance it has in regard to Java is that Java's integration with ActiveX really has more to do with COM than with the specifics of ActiveX. So, when I refer to Java integrating with ActiveX, understand that the COM protocol is really what is making things happen under the hood.
This brings us to the different scenarios under which Java and ActiveX can coexist. Keep in mind that some of these scenarios require not only the Java VM control at runtime but also support for Java/ActiveX integration at development time. In other words, you may have to use a development tool that supports Java/ActiveX integration, such as Microsoft Visual J++. Following is a list of the different situations possible when integrating Java and ActiveX using the Java VM control:
It is possible to use an ActiveX control just as you would a Java class in Java source code. To do this, you must create a Java class that wraps the ActiveX control and then import the class just as you would any other Java class defined in another package. The end result is that an ActiveX control appears just like a Java class at the source code level. Because we are talking about Java source code here, the Java compiler has to play a role in making this arrangement work. So, this approach requires support for Java/ActiveX integration in the Java compiler. The Visual J++ Java compiler includes this exact support.
Visual J++ includes a tool that automatically generates Java wrapper classes for ActiveX controls. You can then import these wrapper classes into your Java code and use them just like any other Java class. Of course, behind the scenes, the ActiveX control is actually doing all the work, but from a strictly programming perspective, the Java wrapper class is all you have to be concerned with.
Just as you can use an ActiveX control as a Java class, you can also use a Java class as an ActiveX control. Because ActiveX controls are manipulated through interfaces, you have to design Java classes a little differently so that they fit into the ActiveX framework. You must first define an interface or set of interfaces for the class, using the Object Description Language (ODL) that is part of COM. You then implement these interfaces in a Java class. Finally, you assign the Java class a global class identifier and register it as an ActiveX control using a registration tool such as JavaReg, which ships with Visual J++.
I know this procedure is a little messier than simply compiling a Java class, but consider what you are gaining by taking these extra steps. You are using one set of source code and just one executable to act as both a Java object and an ActiveX control, with relatively little work. Users can then take advantage of all the benefits of component software by using your Java class as an ActiveX control.
Another less obvious scenario involving Java and ActiveX is your ability to manipulate Java applets through ActiveX scripting code. The ActiveX scripting protocol, which supports both VBScript and JavaScript, allows you access to all public methods and member variables defined in a Java applet. The ActiveX protocol is specifically designed to expose the public methods and member variables for Applet-derived classes, so any other classes you want scripting access to must be manipulated indirectly through public methods in the applet. You learn the specifics of using VBScript to control Java applets in Chapter 39, "Using Java with VBScript."
This chapter took an objective look at Java and ActiveX and where they fit in the quest to make the Web interactive. You learned not only about the philosophy and reasoning behind each technology, but also why the technologies don't necessarily have to be considered competition for each other. You finished up the chapter by learning about Microsoft's plans to integrate Java and ActiveX. This combination of two powerful technologies, although a little confusing at first, is crucial for Web developers because it lessens the need to pick one technology over the other. Possibly the biggest benefit is the peace of mind in knowing that you can continue working with Java without fear that Microsoft and ActiveX will sabotage your efforts.
This chapter touched on the ability to use VBScript to control Java applets. The next chapter gives the details about how VBScript works and what benefits it offers.