[ Team LiB ] Previous Section Next Section

Choosing Among DCOM, Native In Process, and Native Out of Process Modes

You can choose from three different setup modes with jCOM. Each relates to the physical configuration of your objects and the means of interprocess communication used between them. The modes are DCOM mode, native out of process mode, and native in process mode. Each mode addresses particular needs and has distinct advantages and disadvantages over the other.


The first option, DCOM mode, provides the most versatility and is required when the COM client and Java objects will be located on different physical machines (see Figure 33.2). DCOM is a wire-level protocol that was originated by Microsoft to allow distributed COM objects to communicate over the network.

Figure 33.2. Accessing Java objects in DCOM mode.


Although DCOM can run over many protocols, it runs on top of TCP/IP when used in conjunction with jCOM. DCOM mode uses a pure Java implementation, so there no native COM code (no DLLs) is required on the Java server side. Therefore, the operating system can be Unix or any other environment with an installed JVM. This can be a clear advantage, but it comes at the expense of performance. Each call between applications incurs a network delay. The delay exists even when objects reside on the same machine.

Native Out of Process Mode

Native out of process mode is available when you're running the client and server on the same machine. As shown in Figure 33.3, in this mode, all interprocess communication occurs via COM.

Figure 33.3. Accessing Java objects in native out of process mode.


Native In Process Mode

Native in process mode is essentially the same as native out of process mode except for the fact that everything is run within the process memory space of the client application (see Figure 3.4). In this scenario, everything you need to bridge between your COM client application—JVM, Java objects, and jCOM runtime—are contained in the process address space of the COM client application.

Figure 33.4. Accessing Java objects in native in process mode.


It's important to note that when running under each of the native modes, WebLogic Server must be installed on the server machine where both the COM and Java objects will reside. A separate license for WebLogic Server is not required for this purpose, however.

As the name implies, native modes use native calls. Whether between COM clients and WebLogic, or Java objects and COM applications, the call is a native one and is therefore compiled and optimized by the operating system, which results in improved performance. Native modes also take advantage of WebLogic's T3/IIOP protocols when communicating between the COM client and WebLogic Server. This helps to speed things up as well because fewer overall network calls are required to perform individual programming steps. You also gain access to WebLogic's failover and load balancing features in native mode. Because native libraries are currently available only for Microsoft Windows environments, WebLogic Server must run on a Windows machine to work in native mode.

    [ Team LiB ] Previous Section Next Section