Interoperability issues have long made integration of Microsoft® Component _object_ Model (COM) and Java™ components a daunting task. The Development Tool for Java-COM Bridge, available from IBM alphaWorks, simplifies the job and also provides an evolutionary approach to migrating applications from COM to the Java platform. IBM Rational's Cheng-Yee Lin, Thomas Houser, and Peter Parapounsky, creators of the bridging technology, explain its basics and present a sample application that leverages its capabilities.
The IBM Rational Java-COM Bridge (RJC
not only supports bridging from Java components to COM and from COM to Java components, but it also produces reasonable performance in intensive interactions between components through the bridges. The tooling for building RJCB bridges -- the Development Tool for Java-COM Bridge (DTJC
-- integrates with the open source Eclipse IDE----.
Understanding RJCB technologyThe RJCB technology uses the Java Native Interface (JNI) _frame_work to bridge Java code and COM code. JNI lets you call native code in the Java language, and vice versa. You can declare a method in the Java language and define the method body in C or C++. Conversely, you can call Java methods in C or C++ code.
Figure 1 illustrates the structure of an RJCB bridge.
The green boxes in Figure 1 represent the RJCBRT.jar and RJCBRT.dll files that come in the RJCB installation. They provide supporting classes and services used by the generated bridge code (and to a limited extent, by your Java code). The red boxes represent code that's generated by the RJCB bridge generator and are specific to a particular COM API.
Every COM API is described by a special file called a type library. A standalone type library typically has a .tlb extension. Type libraries can also be _embed_ded inside of executable (.exe, .dll, and .ocx) files. The RJCB bridge generator reads a type library and generates the Java and C++ bridge code _base_d on the API that the type library describes.
COM interfaces typically provide two different method-call mechanisms: late-bound and early-bound. Using late-bound calls requires resolving method names at runtime and packaging and unpackaging all the method parameters into or from a special variant array. An early-bound call takes advantage of knowing exactly which method is being called and what its parameter types are. For an in-process COM server (in the same COM apartment), an early-bound call is equivalent to a C++ vtable call (the standard C++ mechanism for calling a virtual method.
The late-bound mechanism is provided by the implementation of a special super-interface called IDispatch. The IDispatch interface provides a method for looking up a COM interface's methods (or properties) symbolically by name, which then returns the method's dispid. The IDispatch interface also provides another method for invoking a COM interface's method given its dispid and an array of variants containing the call parameters. Invoking COM methods via the IDispatch interface is quite inefficient compared to making a simple C++ vtable call (even if you avoid the late-bound feature of IDispatch and just invoke the method with a hard-coded dispid).
The major motivation for the development of the RJCB bridging technology was to create the fastest Java/COM bridge possible. We were bridging some high-traffic APIs between Java and COM, so we needed to achieve the best possible performance from our bridges. For this reason, RJCB bridges support only COM APIs that provide early-bound vtable interfaces. The RJCB-generated bridge code makes direct, interface-specific vtable calls. It does not use the IDispatch superinterface.
The RJCB code generator generates Java proxies for each vtable interface and coclass defined in the COM type library. It also generates Java units containing module constants and enum literals defined in the type library.
For more information refer to
http://www.ibm.com/developerworks/library/j-intbridge/
Favoured: 0
