All Categories :
Java
Chapter 38
Integrating Java and ActiveX
by Michael Morrison
CONTENTS
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.
The Java Vision
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.
The ActiveX Vision
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.
Under Java's Hood
The Java technology can be divided into four major components:
- The Java language
- The Java class libraries
- The Java runtime system
- The JavaScript scripting language
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.
Under ActiveX's Hood
The ActiveX technology can be broken down into the following major
components:
- ActiveX controls
- ActiveX scripting (VBScript)
- ActiveX documents
- ActiveX server scripting (ISAPI)
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:
- Using an ActiveX control as a Java class
- Using a Java class as an ActiveX control
- Manipulating a Java applet through ActiveX
scripting
Using an ActiveX Control as a Java Class
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.
Using a Java Class as an ActiveX Control
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.
Manipulating a Java Applet through ActiveX Scripting
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.
Contact
reference@developer.com with questions or comments.
Copyright 1998
EarthWeb Inc., All rights reserved.
PLEASE READ THE ACCEPTABLE USAGE STATEMENT.
Copyright 1998 Macmillan Computer Publishing. All rights reserved.
SHOPPING
JOB BANK
REFERENCE
JOURNAL
COMMUNITY
ABOUT US