jCOM Concepts

Interoperability is the buzzword in the modern computing world because so many disparate systems from different vendors are being used. In the absence of compatible systems, the market of integration products is ever growing. There are quite a few integration solutions available in the market for "gluing" together the two main distributed computing technologies available today: Component Object Model (COM) and Enterprise JavaBeans (EJB).

These integration solutions are essentially "bridge" software. WebLogic Server provides its own bridging solution to enable applications deployed on WebLogic Server to seamlessly access COM objects. This bridging solution is the jCOM software bridge. The jCOM bridge allows Java applications deployed in WebLogic Server bi-directional access to COM components.

Bi-directional access is the key point here. Most bridge software provides unidirectional access because it is easier to implement it. Bi-directional bridge software is much more difficult to implement because it has to support the protocols on both sides. jCOM supports bi-directional access to COM components. This implies that the jCOM bridge software can translate a call from a Java application or an EJB component to a COM component. This is the first way of communication. The second way of communication is to enable a COM component to access Java applications or EJB components as if they were COM components. Hence, jCOM bridge software supports both the RMI/IIOP and DCOM protocols. DCOM is the distributed computing support for COM components.

Now, take a quick look at the key features of jCOM bridge software:

• jCOM supports two-way interaction between applications and components deployed on WebLogic Server and COM components.

• Data types of Java objects and COM components are mapped to enable data sharing between Java objects and COM components.

• jCOM supports both the early and late binding of Java objects and COM components. This is a powerful feature that will be discussed later.

• There is no local footprint required on the machines where the COM components are deployed. This greatly simplifies things because no special software is required on the machines where the COM components are deployed. Inside the WebLogic Server, the jCOM bridge performs the two-way translation between Java objects and COM components.

• To improve performance, the jCOM bridge also supports the calling of direct native API.

Before you proceed with the discussion of the tools available with the jCOM bridge software, you should study some useful concepts and terminologies that will help you understand jCOM better.

Binding

Binding is the mechanism of associating method/function call signatures with the actual implemented code. For example, when you use database driver libraries for accessing a database, you need to link the driver libraries when compiling and linking your application to generate the final executable file. It is at link time that the actual database functionality in the driver libraries is "bound" to the database calls that you write in your application code. There are two ways to perform binding in an application:

• Early binding Early binding is the generally preferred method used to perform the binding of functionality code with the function calls in an application. The example that you read above of compiling and linking database driver libraries to the database function calls in an application code is of static binding or early binding. Early binding is very efficient because the application code to be bound is available and known at link time. Hence, there is no translation overhead in early binding.

• Late binding When the functionality code is bound to the function calls at runtime, it is called dynamic binding or late binding. In late binding, the application (or the runtime environment) "discovers" the structure of the functionality code while the application execution is in progress, that is, at runtime. During the runtime execution, the functionality code is bound to the function calls in the application and then executed. This causes an additional performance overhead in late binding.

vtable

A vtable is a "virtual table" of pointers to function calls whose functionality is provided by an object, for example, a library object. The vtable is always required in static, that is, early binding. This is normally used in Visual Basic and Visual C++ applications when accessing COM components. For example, if you wanted to automate Microsoft Word using early binding, you would add a reference to the "Microsoft Word 8.0 Object Library" (MSWORD9.OLB file for Office 2000).

IDispatch Interface

The IDispatch interface is used during late binding when the information about the exact function being called is not known at link time (static binding time). The IDispatch interface serves as a mechanism to find information, such as data types, parameters, and so on, about the object or function at runtime, which is then used to invoke the function of the object.

Now that you are clear on these concepts regarding accessing COM components, proceed with your study of jCOM.