On first look, Java and ActiveX could seem to be incompatible-Java
is a cross-platform language while ActiveX is a Windows-specific
technology (at least for now). But this is not true. Java and
ActiveX do coexist, and you can choose a strategy which includes
both. Having said that, one needs to qualify that statement with
a few aspects-some technological, some political, and some marketing.
| NOTE |
The emphasis of this chapter is to give you a perspective and an architectural overview on interfacing Java with ActiveX. As the discussion roams around the mechanisms of ActiveX access, some basic Java knowledge is assumed. |
Technologically, ActiveX is based on components with binary interfaces, and Java is a component-based language (at some level of abstraction). The popular notion is that ActiveX is a technology while Java is a language. In Microsoft's Java VM implementation, your Java programs can see ActiveX object's properties, methods, and events. On the other hand, if you are using Sun's technologies, JavaBeans has an ActiveX bridge through which you can interact with server-side ActiveX components. The Active Desktop is becoming cross-platform from Mac to UNIX. In the future, your Java programs with embedded ActiveX controls will be able to run on OSs other than Windows.
Politically, it is not all that cozy between the competing technologies. If you mention Win32 extensions for Java, you will either elicit sharp criticism or a knowing nod, depending on whom you talk to. JavaSoft's "100% Pure Java" initiative directly counteracts Microsoft's Java SDK, Win32 extensions for Java, and some of the Java wizards that create Java code geared specifically to Windows implementation.
In a marketing sense, you need to be involved with Java. You should be developing applications in Java also. Whether you belong to the "100% pure Java" initiative also depends on the platforms you are developing. As you have come to Chapter 9in this book, my assumption is that you are catering predominantly to the Windows "crowd." If your intranet is fully Windows-based PCs, or if your applications are catering to the Microsoft Windows environment, you can write Java code with ActiveX technology and Win32 extensions. If your users include other operating systems, your Java applications should use ActiveX only if the ActiveX desktop is supported in that platform. You should sense the client platform from your Web server and offer alternatative Web pages. For server-side applications, if your platform is Windows NT, you can use all the Win32, COM, ADO, and other ActiveX technologies from your Java applets. The word is know your users, your applications, and your operating systems (client and server) and then decide accordingly. But you need not shy away from Java.
First, some theoretical discussion: The Microsoft Java Virtual Machine is implemented as an ActiveX control. From the outside, the Java applet looks like another ActiveX control and, hence, it can be integrated and controlled by scripts and other ActiveX methods. From inside, the Java applet can access other ActiveX controls' properties, methods, and events as it would access any other Java applets. Figure 9.1 shows this concept.
For a Java applet, there is no difference between other Java applets
and an ActiveX control. On the other hand, an ActiveX control
or a script sees a Java applet as another ActiveX control.
| NOTE |
Even though it is theoretically possible to create an ActiveX control using the Java language, currently it is not easy to produce an ActiveX control using the Visual J++ 1.0 product. With the current version of Visual J++ (1.0), you can create a basic COM object but not a full ActiveX control that can use ActiveX containers as VBCCE or the Control Pad. Hopefully, Microsoft will make the ActiveX control creation as easy as the VBCCE, possibly in the next version of Visual J++. |
The Java SDK from Microsoft contains tools, utilities, and documentation for writing Java applets with Microsoft Java Virtual Machine, COM, and other Microsoft extensions to the Java class libraries.
You can download the Java SDK, and a lot of other Java-related information, from http://www.microsoft.com/visualj. If you are developing database applets, you should download and install the Data Access Objects (DAO), MSSQL, and MSSQLERR help documentation. The Remote Data Objects help is available online for you to read and understand.
The SDK files are in the SDK-Java.exe, and the documentation is in the SDK-Docs.exe file. The SDK contains the latest version of the Java Virtual Machine, the Java class library with standard and Microsoft Java class extensions, tools, and utilities. The utilities include the javatlb (to convert type library files into Java classes), jexegen (to convert Java stand- alone applications to native executable binaries), and c-header files for native code and COM interfaces. The sdk-docs.exe contains the documentation for Java, COM, and so on.
To use ActiveX controls in your Java applets, you will need the Java type library compiler. In the Visual J++ development studio, the type library wizard is accessible under the Tools menu as shown in Figure 9.2.
You can select the ActiveX control you want to use from the controls list as shown in Figure 9.3.
The wizard will generate wrapper classes for the selected ActiveX controls. (It actually uses the javatlb program to generate these files.) You will find the class files, as well as a summary .txt file, in the %windir%\java\trustlib\<controlname> sub-directory. In your Java program, you will use the import <controlname>.* statement.
You can embed an applet in an HTML page and use VBScript or JavaScript
to control the applet. The ActiveX runtime for Java makes all
the public methods and variables of your embedded Java applets
visible to the ActiveX scripting languages.
| NOTE |
Only the public methods and variables in your applet-derived class are visible for scripting. If you want other classes in your applets to be visible for scripting, you should code extra wrapper methods in your applet-derived class. |
Two technologies-Data Access Objects and remote Data Access Objects-are also available from Java language. To use the RDO, you should use the Java type library wizard to generate wrapper classes for the RDO components. It will generate the classes in the %windir%\java\trustlib\msrdo32 subdirectory. Then you should use the import msrdo32*.* statement in your Java programs.
Using RDO from Java Applets The RDO (Remote Data Object) is a very powerful data access tool. It is a thin layer of code over the ODBC API so it can be used to access any database that has ODBC drivers. With RDO, you can develop simple data access applications to complex applications which use cursors and transactions. As the name implies, you are accessing data in server databases.
The only class available for the Remote Data Object is the rdoEngine COM class. Figure 9.4 shows the object hierarchy of the rdoEngine.
Figure 9.4 : Remote Data Object Hierarchy showing the objects available for programming.
The following list shows all the interfaces available for the rdoEngine.
Using DAO from Java Applets The DAO (Data Access Object) is used to access local databases in various popular databases including dBase, Access, Excel, Microsoft Jet Database, structured text, and so on.
The top level DAO object is the DBEngine, which in turn contains the workspace and the error object. One workspace object can be associated with many databases and many user objects. A database object can contain many tables, resultsets, and queries.
You can use the DAO data access when you want simple database operations usually in local databases. For such applications, DAO gives you powerful and easy-to-use objects.
You are seeing the first glimpses of Java and ActiveX integration. You can be assured that Microsoft is working on many aspects of Java to make ActiveX controls use as easy as possible. The Java type library wizard, for example, is a first-generation tool. You will see a lot more development aids in the coming months.
Because the Java Virtual Machine is thread safe and Java itself allows multi-threaded objects, Java is a good language to develop the middle-tier objects for three-tier or n-tier client/server Web applications. In such cases, if your server runs Windows NT with Active Server Pages/IIS 3.0, cross-platform issues do not arise at all.