WebLogic jCOM Programming Models

 

The following sections look at the different ways in which COM-to-Java communication can be implemented using WebLogic jCOM, along with the advantages and disadvantages of each implementation:

• WebLogic WebLogic jCOM Components

• Defining the Terms

• WebLogic WebLogic jCOM Programming Models

 

---

WebLogic jCOM Components

BEA WebLogic jCOM allows you to access Java objects (including Java components) running on any Operating System from COM clients running on Microsoft Windows.

In essence, WebLogic jCOM is a kit which provides you with the runtime environment and necessary components to create a Java COM-to-Java bridge. In all the examples we look at, the bridge is on the same machine as the WebLogic Server machine.

The jCOM.jar runtime is required to compile and run the bridge. The bridge itself is a Java process, created by the user, which runs in the background to handle the COM to Java communication between the client and the server. The bridge, JCOMBridge.java, provided with the examples serves both as a bridge for the examples and a base for creating your own bridge.

In addition to the runtime file, WebLogic jCOM also provides a number of tools and components which are used for configuring the client and server environments.

Note that the Java Virtual Machine always runs as a separate process to the VB process, possibly even on another machine. WebLogic jCOM cannot be used to put a Java bean inside a VB window, since they are in separate processes.You do however have access to all public methods and fields of any public Java class from your Visual Basic programs.

COM-to-Java communication can be achieved using any of the following programming models:

• DCOM Zero Client Programming Model

• DCOM Late Bound Programming Model

• DCOM Early Bound Programming Model

• DCOM Late Bound Encapsulation Programming Model

• Native Late Bound Programming Model

• Native Early Bound Programming Model

 

---

Defining the Terms

DCOM Mode

The DCOM (Distributed Component Object Model) mode uses the Component Object Model (COM) to support communication among objects on different computers.

Native Mode

Native mode uses native code (DLLs), which are compiled and optimized specifically for the local operating system and CPU, resulting in better performance.

Zero Client Installation

Zero client installation means that you do not have to install any software on the Windows client machine. There is no deployment overhead.

Late Binding

Late binding is a way of providing access to another application's objects. In late bound access, no information about the object being accessed is available at compile time; the objects being accessed are dynamically evaluated at runtime. This means that it is not until you run the program that you find out if the methods and properties you are accessing actually exist.

Early Binding

Early binding is a way of providing access to another application's objects. Early bound access provides you with information about the object you are accessing while you are compiling your program; all objects accessed are evaluated at compile time. This requires that the server application provide a type library and that the client application identify the library for loading onto the client system.

 

---

WebLogic jCOM Programming Models

COM-to-Java communication can be implemented using either DCOM or Native mode. Each of these modes provides a choice of programming model.

In all the implementations, the COM client runs on a Microsoft Windows platform. The Java component runs on a Java^TM 2 Platform, Enterprise Edition 1.3 and WebLogic Server 6.1. The client and server/bridge can run on the same system in a one-system implementation.

DCOM Zero Client Programming Model

A DCOM zero client installation is easy to implement. No WebLogic jCOM specific software is required on the client side.

Zero client installation utilizes late binding and therefore provides the same flexibility in terms of changes made to the Java component. However, this implementation requires that the bridge location and port number be hard coded into the COM client, which means that if the bridge location is changed, this reference has to be regenerated and changed in the source code.

The DCOM zero client installation is more error prone than the DCOM early bound implementation.

Relative to the DCOM late bound implementation, DCOM zero client installation provides a gain in performance on initialization at runtime.

Figure 2-1 Runtime installation for a typical DCOM zero client implementation.

For the client to access the Java component:

1. The WebLogic jCOM bridge location is hardcoded into the client using a objref moniker string. The objref moniker is generated by the user and it encodes the IP address and port of the WebLogic jCOM bridge. Once the bridge connection is established the client can link a COM object to an interface in the Java component.

2. Any further references in the client to this COM object will use the Java method as if it were a COM method.

For an example of zero client installation implementation see the Zero Client Installation example installed in the samples/examples directory of the WebLogic jCOM installation.

DCOM Late Bound Programming Model

DCOM late bound access is easy to implement and it is a flexible implementation since objects referenced are only evaluated at runtime. This however also means that no type checking can be done at compile time, which makes this implementation more error prone.

 

Figure 2-2 Runtime installation for a typical DCOM late bound implementation.

For the client to access the Java component:

1. In the client source code, you link a COM object to an interface in the Java component. For the client to access the interface, you have to use a WebLogic jCOM tool to register the JVM in the Windows registry and associate it with the IP address and port of the WebLogic jCOM bridge.

2. Any further references in the client to this COM object will use the Java method as if it were a COM method.

For an example of a DCOM late bound implementation see the Late Bound Implementation example installed in the samples/examples directory of the WebLogic jCOM installation.

DCOM Early Bound Programming Model

DCOM early bound access is complex to implement. It requires the generation of a type library and wrappers. The type library is required on the client side; the wrappers are required on the server side. If the client and user are running on separate machines the type library and wrappers have to be generated on the same machine and then copied to the system where they are required.

Early bound access lacks the flexibility of late bound access in that any changes made to the Java component require regeneration of the wrappers and the library. See Late Bound Encapsulation Programming Model for a hybrid alternative strategy.

Early bound access does provide improved reliability. Compile-time type checking makes debugging easy and the user has the advantage of being able to browse the type library.

Relative to the DCOM late bound implementation, the DCOM early bound implementation provides improved runtime transaction performance, but slower initialization at runtime.

 

Figure 2-3 Runtime installation for a typical DCOM early bound implementation.

For the client to access the Java component:

1. In the client source code, COM objects are declared using a user generated type library. For the client to access the interface, you have to use a WebLogic jCOM tool to register the JVM in the Windows registry and associate it with the IP address and port of the WebLogic jCOM bridge. The type library is then registered on the client side and linked to the registered JVM name.

2. Any further references in the client to this COM object will use the Java method as if it were a COM method.

For an example of a DCOM early bound implementation see the Early Bound Implementation example installed in the samples/examples directory of the WebLogic jCOM installation.

DCOM Late Bound Encapsulation Programming Model

If you have used early binding and plan to alter your Java component interface, or simply wish to be prepared for the future possibility, it is recommended that you employ late bound encapsulation. Any changes made to a Java component requiring a recompilation of the wrappers, will also necessitate creation of a new client-side type library, since wrappers and type library are interdependent and version specific. This situation could arise even if the Java component interface changes are irrelevant to a particular client program. You could therefore be forced to redistribute the new type library to all client systems accessing the Java component.

When using the late bound encapsulation method, you retain the majority of the benefits of early bound programming, while implementing a more flexible late bound design that does not require wrappers or type libraries.

The basic steps described below are for a Visual Basic client but can be applied to any programming language:

1. Create a type library and implement the interface of the objects you want to use inside one or more VB classes.

2. This class can now act as a wrapper for communication with the late bound version of the object.

3. Eliminate the type library once the interface has been established (as long as it still exists the implementation will remain early bound).

Native Late Bound Programming Model

Native late bound access is easy to implement and is a flexible implementation since objects referenced are only evaluated at runtime. This however also means that no type checking can be done at compile time, which makes this implementation more error prone.

Since native libraries have only been created for Windows, implementing native late bound access requires that the WebLogic jCOM bridge be installed on the client machine.

Relative to the DCOM late bound implementation, the native late bound implementation provides a large gain in performance on initialization at runtime.

 

Figure 2-4 Runtime installation for a typical native late bound implementation.

For more on implementing native mode see Native Mode in the Reference Guide.

Native Early Bound Programming Model

Native early bound access is complex to implement. It requires the generation of a type library and wrappers. The type library is required on the client side; the wrappers are required on the server side. If the client and user are running on separate machines the type library and wrappers have to be generated on the same machine and then copied to the system where they are required.

Early bound access lacks the flexibility of late bound access in that any changes made to the Java component require regeneration of the wrappers and the library.

Early bound access does provide improved reliability. Compile-time type checking makes debugging easy and the user has the advantage of being able to browse the type library.

Since native libraries have only been created for Windows, implementing native early bound access requires that the WebLogic jCOM bridge be installed on the client machine.

Relative to the DCOM early bound implementation; the native early bound implementation provides a large gain in performance on initialization at runtime.

Relative to the native late bound implementation, the native early bound implementation provides slower initialization at runtime, but a slight gain in transaction time performance.

Figure 2-5 Runtime installation for a typical native early bound implementation.

For more on implementing native mode see Native Mode in the Reference Guide.