The concepts of COM, ActiveX, and JDBC are rather complex. To go into great detail about these three would require us to describe a plethora of other supporting concepts in order to fully explain the ideas we're trying to get across. It could easily
take several days to cover these topics in enough detail to make them useful to you. These concepts also are more Microsoft and intranet, not Java, specific than the other chapters in the book. Also, due to the enormous amount of information available on
these subjects, much of which is changing on a regular basis, most of the information provided here will be an overview so as not to be outdated by the time you read it. Our hope, therefore, is that by the end of today, you'll have a good grasp of what
COM, ActiveX, JDBC are, how they can be used, and why you might want to consider using them. And finally, you'll learn about Visual J++'s capabilities in the following areas:
Because there is so much information to cover in one day, the information presented today will not include any of the complex examples that would require a discussion of the connection between COM and OLE. Although whole books are devoted to OLE, providing examples of COM without having the space to go into the detail necessary to explain how the examples relate to OLE would certainly be much more confusing.
Microsoft has been working with objects in one way or another in their operating systems for some time now. One of the first objects that appeared in Microsoft operating systems was OLE automation within the Office Suite. Next came OCXs (OLE-based
custom controls). After OCXs, Microsoft came out with a new specification called ActiveX. And of course, the OLE automation within the Office Suite of products (now called ActiveX objects) is still there. Eventually, Microsoft informed us, NT will become a
completely object-based operating system.
Since the beginning of OLE, Microsoft has been basing all of their objects on the Component Object Model. Although the different objects all have their subtle differences, OLE, OCXs, and ActiveXs are all grown from the same mold called COM.
Microsoft Defines the COM as the following:
"The Component Object Model is a specification that describes the process of communicating through interfaces, acquiring access to interfaces through the QueryInterface method, determining pointer lifetime through reference counting, and re-using
objects through aggregation."
What does the preceding quote really mean? Well, to help clear it up some more, here are a couple more Microsoft definitions that can be found in VC++ 4.x Books Online:
An object is defined as
"An item in the system that exposes interfaces to manipulate the data or properties of the object. An object is created by directly or indirectly calling the CoCreateInstance() application programming interface (API), which in turn creates a new
instance of the object and returns a pointer to a requested interface."
An interface is defined as
"A group of related functions. Communication between two objects in a system occurs by calling the functions in an interface through a pointer to that interface. An interface pointer is originally obtained at the time the object is created."
Pretty interesting reading. Do the preceding two definitions resemble anything from the beginning of this book?
Notice how a COM object and a COM interface sound a lot like your typical everyday Java objects and Java methods.
Visual J++ has the capability to use almost any COM object that is currently installed on your computer. Before Visual J++ can use a COM object, though, it must be run through the Type Library Wizard. The Type Library Wizard takes all of the exposed
methods in the COM object and creates a usable Java *.class file.
Microsoft defines a Type Library as "a mechanism defined by COM to store type information; each type library contains complete type information about one or more COM entities, including classes, interfaces, dispinterfaces, and others." For
more information about type libraries, see Type Libraries and the Object Description Language, or the Win32 SDK. Once again, this information is available in the VC++ Books Online packaged with VC++ 4.x.
In order to use a COM class from Java, you must first import it; this means creating a Java class that represents the COM class in the context of Java. Visual J++ includes the Java Type Library Wizard for this purpose.
The following steps show how to import a COM class for use in Java:
In the Output window, the Type Library Wizard displays the import statement(s) appropriate for each package it has created. You can use these import statements in your Java source code; this allows you to refer to classes in those packages by their
short names. Figure 15.2 shows the output statements as well as the summary.txt file created for comdlg32.ocx when run through the Type Library Wizard.
Figure 15.2. Output statements produced from the Type Library Wizard.
The Type Library Wizard also displays the complete path of the newly created file named SUMMARY.TXT. By double-clicking on this line, you can open the text file in Microsoft Developer Studio. This file lists the Java signatures of all the methods for
the COM interfaces and classes described by the type library. You can then call all of these methods from your Java program.
To find out how to use the interfaces available from a particular programmable control or automation server, you'll need to consult the documentation provided by the vendor.
For each type library imported, the Java Type Library Wizard creates a directory below the trusted library directory having the same name as the type library. The Java Type Library Wizard fills that directory with .class files, one for each COM class
and/or interface described in the type library. All the generated classes and interfaces are part of a Java package having the same name as the type library file. (If the type library contains an importlib statement, the Java Type Library Wizard creates a
separate Java package in a separate directory for the imported type library.)
Each .class file generated by the Java Type Library Wizard contains a special attribute identifying it as a wrapper for a COM class. When the Java support in Internet Explorer sees this attribute on a class, it translates all Java method invocations on
the class into COM function invocations on the COM class. For a COM interface that defines properties, the corresponding Java interface defines two methods for each property, named getproperty and putproperty. If the COM interface defines
methods with the propget or propput attributes, the Java interface versions of those methods have get or put before their names.
Once you have run the Java Type Library Wizard for a given type library, you don't need to re-run the wizard unless the type library has changed.
Once the Java Type Library Wizard has generated .class files for a type library, your Java program has no further need for the type library. When distributing an applet that uses COM, your Java program needs only its own .class files, and the .DLL,
.EXE, or .OCX files that implement the COM services, along with the generated .class files for the COM services. You must also be sure to register the COM object appropriately.
If you include COM objects with Java applets embedded on a Web page, the .OCX or .DLL files that implement the COM object should have digital signatures. Digital signatures allow users to trust your applet, allowing it to run on their system. In order
to do this, the Java applets need to be packaged into a digitally signed cabinet (.CAB) file. For more information on .CAB files and digital signatures, see Creating a Signed CAB File later in today's lesson.
For this section, you're going to use one of the examples that Microsoft ships with Visual J++. This example is called the javabeep applet. This applet consists of the following:
For the following exercise you'll need to copy some files from your VJ++ CD to your hard drive. Find the msdev\samples\microsoft\javabeep directory on the CD. Copy all the files (and subdirectory and files) in the javabeep directory to a directory
named \projects\samples\microsoft\javabeep on your hard drive. If you don't have a directory with this name already, please create it.
Once all the files are copied, fire up Microsoft Developer Studio. Open the javabeep.mdp Project Workspace, and compile the project. Figure 15.3 shows what the compiler output should look like.
Figure 15.3. Compiled javabeep project as shown in Microsoft Developer Studio.
Examine the output in the Build window. Notice that the second line says that a class library is being created from beeper.dll (just as if you ran the Java Type Library Wizard). How does this Project Workspace know to create class information for
beeper.dll? It knows because the beeper.dll file is included in the project. Click the FileView tab in the Project Workspace window to see the list of files included in the project.
In the Build window, notice also that the file beeper.dll is being registered. This is not a Java registration, but rather standard Microsoft WIN32 OLE registration.
Execute the javabeep applet. (Remember to execute it inside Microsoft Developer Studio.) After the applet loads, click anywhere in the applet window. Each time you click, a message displays at the point where the mouse cursor is and a beep is sounded.
On your own, examine the source code for javabeep, and also look at the .html file. Notice that the HTML file doesn't contain any special code to run COM-enabled applets; all the code is in your .class file (and the supporting COM files called by your
applet).
Besides allowing Java programs to use COM objects, the Java Support in Internet Explorer also allows Java programs to expose their functionality as COM services. This lets you use Java for developing component software without requiring that your
clients use Java; your clients can use any language that is compatible with COM, such as Microsoft Visual Basic or C++.
Microsoft defines ActiveX as all component technologies built on Microsoft's Component Object Model, other than Object Linking and Embedding. It defines ActiveX control as the new name for programmable elements formerly known variously as OLE Controls,
OCXs, or OLE Custom Controls. Controls previously built with the MFC Control Developer's Kit meet the ActiveX control specification.
You can embed both Java applets, COM objects, and ActiveX controls in the same Web page and use applet (or VBScript) handlers to connect them. For example, you can read values from an ActiveX control and pass them to a Java applet, or vice versa.
(However, you cannot trigger events from the Java applet.)
Basically, the methods of using an ActiveX control are identical to the methods of using a generic COM object. The preceding beeper example uses an OLE-based DLL. The beeper.dll could just have easily been compiled, using C++, as beeper.ocx.
You can download the ActiveX SDK from http://www.microsoft.com/activex/ (which is accessible using the Web Favorites command on the VJ++ Help menu) for more detailed information on ActiveX.
Java applets typically run in a carefully constrained execution environment preventing them from interfering with your system. Using COM services, though, means that your programs will need to access resources on your (or the user's) system. To prevent
Java applets from posing a security threat, the Java Support in Internet Explorer categorizes classes as either trusted or untrusted. Microsoft defines trusted and untrusted in Visual J++ Books Online as follows:
Before we tell you how to create a .CAB file, it's important that you understand the following.
Internet Explorer (when executing the .class) behaves differently depending upon whether the class is trusted or not. The primary difference is the way that Internet Explorer searches the class path. The InfoView topic in Visual J++ Books Online sums
it up best:
There are four class path-related registry keys that are relevant to the security of Java applets. All of these keys are subkeys of HKEY_LOCAL_MACHINE\Software\Microsoft\Java VM:
When executing a trusted applet, Internet Explorer looks in the following places (and in the following order) for classes referenced by the applet:
When executing an untrusted applet, Internet Explorer looks in the following places (and in the following order) for classes referenced by the applet:
In addition to restricting the class search path, Internet Explorer Java support also employs other security mechanisms. For example, any classes that are Java wrappers for COM classes are inaccessible to untrusted applets, even if those classes happen
to be located in the regular class path or in the libraries directory.
The following summarizes the major differences between a trusted applet and an untrusted applet:
Remember, too, that even though Java classes in your project directory are considered trusted when you launch Internet Explorer from the Developer Studio environment, this does not mean that an applet built using Visual J++ automatically qualifies as
trusted. Outside of Microsoft Developer Studio, an applet must be packaged into a .CAB file and digitally signed in order to use COM services. This relaxed feature of Internet Explorer under Microsoft Developer Studio is there so you don't have to package
your classes into a signed .CAB file just to execute and test them.
The cab&sign directory on the Visual J++ CD-ROM contains two tools:
Both of these are self-extracting executables that install the tools and documentation needed to, respectively, create a Cabinet (.CAB) file and digitally sign a file.
These executables are not installed by the Visual J++ setup program. You need to copy each of these executables into its own directory and run them to extract their respective tool kits.
You can also get all the tools needed for creating a .CAB file and digitally signing a file as part of the ActiveX Software Development Kit. You can download the ActiveX SDK from http://www.microsoft.com/activex/ (which is accessible using the Web
Favorites command on the VJ++ Help menu).
See the respective documentation included with the tool kits for complete information on using these tools.
If you are placing an applet that uses COM on an HTML page that is accessible from the Internet, you must ensure that any users who encounter that page have a version of the Java Support for Internet Explorer that fully supports Java/COM integration.
To do this, you must insert the following tag on the HTML page containing your applet (or on the introductory page of your Web site):
<OBJECT CLASSID="clsid:08B0E5C0-4FCB-11CF-AAA5-00401C608500" CODEBASE="http://www.microsoft.com/java/IE30Java.cab#Version=1,0,0,1"> </OBJECT>
This tag (from <OBJECT to </OBJECT>) causes the user's Internet Explorer to check the version of its Java support. If the version installed on the user's machine is not up-to-date, Internet Explorer downloads the latest version of Java support
from http://www.microsoft.com and updates the user's machine.
This section deals with database access using Data Access Objects (DAO), Remote Data Objects (RDO), Open Database Connectivity (ODBC) and Java Database Connectivity (JDBC) PDQ ASAP. Wow, that's a lot of abbreviations! In short, all of these database
tools are used in one way or another to allow you and the user access to data contained in tables. Using these tools in your Java programs, in most cases, also frees you from learning CGI and Perl.
Some differences exist for the tools. The most notable differences are the following:
Microsoft defines Data Access Objects (DAO) as a high-level set of objects that insulates developers from the physical details of reading and writing records. In a database application, for example, these objects include databases, table
definitions, query definitions, fields, indexes, and so on. DAO would be used, for example, to access a local Microsoft Access database.
The following Microsoft supplied example demonstrates the use of Data Access Objects (DAO) from Java. This example requires that you have DAO installed on your machine. You can install DAO from Visual J++'s Setup program by choosing Custom Install and
checking the Database Options checkbox.
The following steps show how to run this example:
RDO is an alternative that in many scenarios performs better than DAO. Some future version of the DAO should include all of the positive features of RDO. RDO was designed explicitly for accessing data on remote servers such as Microsoft SQL Server
version 6.0 or ORACLE®. The DAO developers designed it for accessing data from both remote servers and local workstations, for example, from xBase files, Microsoft Access files, and Paradox™files.
Even though RDO can access Microsoft Access database on a local drive, it's a bad choice for reading data because it will go through all of the layers that the DAO uses, as well as its own layer. However, RDO is an excellent choice for reading data
from Microsoft SQL Server 6.0 because the RDO developers put extra effort into tuning its performance with this database. Think of the RDO as a replacement for making DB-Library™application programming interface (API) calls or ODBC API calls—it's
a way to get performance without spending weeks coding API calls. If you're writing client/server applications with Microsoft SQL Server, RDO should be your first choice.
Why use RDO? The greatest advantage of RDO is that it does not use the Jet engine. The Jet engine is Microsoft's database engine that is used by DAO and consumes a large amount of resources and adds a lot of overhead. The RDO uses a thin layer of code
over the ODBC layer and the driver manager that establishes connections to the database. This thin layer appears very similar to the DAO but without all of the resources required by Jet on the client PC. This small memory footprint results in a huge drop
in the amount of memory required and reduces the code swapped to the hard drive on some workstations.
DAO and RDO are, arguably, incredibly Microsoft Specific database access methods. Fortunately for those of us who must write platform independent systems, Sun has provided the world with an alternative: JDBC. JDBC is located in the base java class
java.sql.*.
Because ODBC is generally the agreed upon defacto standard for database access, Sun simply wrote a Java-based API to access ODBC Drivers. The reason it's not practical to have Java use an ODBC Driver directly is that ODBC is a 'C' interface and Java
does not directly support that interface.
The JDBC is the first platform independent database driver available for Java. Because the JDBC is written as a very low level interface to an ODBC driver, it is likely that JDBC is simply the first of many various flavors of database access toolkits
for Java that will evolve from JDBC. You would expect that some of these toolkits will include dynamic mapping of tables to Java classes and embedded SQL.
Well, we said it would be an overview! But, you should notice by what we did write that there's a whole lot to learn about ActiveX, COM, and database access using Java. We hope we answered some of your questions, and also gave you enough information to
cause you to think about this powerful and exciting technology. To follow up, you should experiment on your own with the remaining examples on the VJ++ CD.
Q: How do I know if a particular browser supports ActiveX and COM?
A: Currently, only Microsoft Internet Explorer and Netscape 3.0 (with the added ActiveX plug-in) do. You should be able to check the ActiveX Web site as well as other browser developer Web sites to see what level of support is offered. As
mentioned earlier, the address for Microsoft's ActiveX Web site is http://www.microsoft.com/activex/default.htm.
Q: Where do I go from here to write a database access Java program?
A: First start by knowing your target audience. Is it Internet or intranet, or both? What is the platform? What are the requirements? Look at the Microsoft and Sun Web sites to get the latest information and implementation of the database
classes. Other than gathering as much information as possible, we'd strongly recommend using (and understanding) the examples contained on the VJ++ CD. And, above all—design big, but start small!
