by Prithvi Rao
Prithvi Rao is the founder of Kiwilabs, which specializes in software engineering methodology and Java training. He has worked on the development of the MACH OS and a real-time version of MACH, and he holds two patents resulting from his work on mobile robots.
Using Beans within ActiveX
We live in a world of diversity, and the computing industry is no exception. Recently, I was writing some ActiveX code just to learn more about it, and I had an epiphany: Java Beans and ActiveX are remarkably similar.
My first thought was, "Why should I bother learning this technology?" My second was, "maybe I shouldn't." I am not suggesting that ActiveX is either a lesser or a redundant technology, but that it is an alternative to Java Beans. It also does not mean that if you write code in Java and it acts like a Bean, you are excluded from ever incorporating your Beans as reusable components into an ActiveX environment.
The focus of this article is precisely how to do just that. I am going to go through the steps of taking a piece of code written as a Java Bean and embed the Bean into an ActiveX control. I am going to look at the ActiveX bridge provided with the Beans Development Kit from Sun (BDK 1.0, <https://java.sun.com>).
The reasons for doing this are quite compelling. ActiveX and Beans are the two main component architectures. ActiveX, which is based on the Component Object Model (COM) from Microsoft, first made its debut in 1992. Recently, Sun came out with its component architecture, Java Beans, and it has gained a great deal of popularity since its inception in 1997. Java Beans are written entirely in Java and require a JVM. The Java Development Kit is available from <https://www.javasoft.com>.
I am not going to deal with the ActiveX side of things except where it is necessary to understand the process.
Beans and ActiveX
The following summarizes the two component architectures:
A Java program is a Bean under the following conditions:
The ActiveX container and the Bean never communicate directly; everything goes through the bridge. Currently, the bridge is in its third beta release.
Let's create a visible Bean (the second beta release supported only visible Beans) to see how to "bridge" the gap.
Writing the Bean
The following Bean is from Rob Englander's book, Developing Java Beans, and I use it with his permission. We are going to look at code for the BeansBook.Simulator. VisualTemperature class. Let's call this file Simulator.java and put it in ~/projects/MyBeans/Java.
// let's define the temperature bean class
// provide support for bound property listeners
// the current temperature
// constructor for this class
// remove a property change listener
// defer to support object
// get the value of the Temperature property
// set the value of the Temperature property
// save the new value
// fire the property change event
// handle a temperature pulse
// get the current temp
// if the pulse temp is > current temp
This Bean conforms to standard design patterns for accessor methods, handling events, and so forth. I'll discuss design patterns in more detail in subsequent articles.
Jarring the Bean
All Beans are "packaged" as Java ARchive files (JAR). If we want to embed the Bean in an ActiveX control, we need to create this archive file. I'll call it Simulator.jar. The first thing to do is to compile the Simulator.java file:
This creates a class file called Simulator.class
Next, create a JAR file by using the jar utility that is part of the JDK. Go to the directory containing the Simulator.class file, and run the jar utility:
jar vcf Simulator.class Simulator.jar
This command is a directive to create a new archive called Simulator.jar and make the file Simulator.class be part of it. The v switch provides verbose output and is not absolutely necessary. You might have observed that jar is very similar to the tar utility. Jar essentially compresses the file. This is especially important because Beans are intended to be accessed across a network.
Packaging the Bean
This is the main step that actually makes the Java Bean recognizable by the ActiveX control.
First, create a directory where you can place all the output from the Packager. This is where all the type libraries and registry files created will be placed, as well as the Java stub files. All of these are outputs of the Packager.
Now copy the beans.ocx file in bdk/bridge/classes into this directory. This is the copy of the beans.ocx that will be referenced by the ActiveX versions of the simulator Beans.
Before we run the Packager, we need to set the CLASSPATH environment:
setenv CLASSPATH ~/bdk/bridge/classes
Now we can run the Packager:
The Packager presents you with a dialog box that walks you through the steps needed to package a Bean. Here are the steps:
1. Specify the JAR file previously created containing the Bean. You can type in the full pathname of the file
2. The dialog box changes to show the Beans contained in the JAR file. Select the class "BeansBook.Simulator.Thermostat," and press the "Next" button.
3. Now you have to specify the ActiveX name that should be used to identify the component. Let's use "JavaThermostat," and press the "Next" button.
4. Now specify the directory into which the type library and the registry files are to be placed. These must be in the same directory as the beans.ocx file. (Remember we copied it into ~/projects/MyBeans/ActiveX.)
5. Next we are asked if we wish to "crack" the events. The discussion on this topic is for another time. For now let's "crack" the parameters. This means that event is fired into the ActiveX event firing protocol.
6. Now start the packaging process by pressing the "Start Generation" button.
The Packager tool adds new classes to the JAR file, and these classes all start with ole, which stands for "Object Linking and Embedding." One new class supports the Bean's ActiveX control interface. The rest are to support the ActiveX control event listeners.
If you wanted to use the Bean in a Microsoft Word document, you would use the Object command to select this control. The Java Bean can now be used anywhere an ActiveX component can be placed.
Understanding interoperability is a fundamental requirement of the computing world because it is one way to bridge the gap between newer and older technologies. Examples of this are CORBA/DCOM and JDBC/ODBC. The popularity of Java, and therefore Beans, is increasing, but the ability for Beans to interoperate with other component architectures will partially determine its success. Java Beans encourages the programmer to live in the design space of a problem. With the powerful, easy-to-use tools provided by the BDK distribution, we can make interoperability a reality.