I have spent a good part of the last year trying to "wrap" COM servers in Java for a content management organization. It had an array of syndication servers supported by an integrated messaging platform developed using COM.

The purpose of this exercise was to increase the organization's market penetration by hooking on to the J2EE bandwagon across multiple platform configurations. With so many different complex COM servers to work with, some supporting automation and others not, I struggled with the all too familiar JNI cycle...code, crash, code some more, and then crash. Literally speaking, I must have brought down the JVM hundreds of times. To top it off, some syndication servers worked on a "pull" mechanism, they could pull the content out from the interfacing repositories. This meant bi-directional access and an event-based interoperation.

I had a look at some Open Source projects, but they were all using native libraries and didn't sufficiently meet the requirements in hand. Ultimately, we did complete a scaled-down version of the project. I'm quite sure that most of the requirements could have been handled if a non-native solution (in the Open Source community) existed to COM interoperability.

There are a number of reasons why I believe JNI shouldn't be used for accessing COM. It may work well for a small-sized project (two or three COM servers, no bi-directional access, etc.). But for any serious initiatives, I think it has certain drawbacks. Though JNI is Java, you still need to know a lot more about the native component and the target architecture before accessing its services. One has to be proficient in Java and in the native programming language as well (some Open Source projects are trying to address this complexity, i.e., trying to abstract JNI itself). With increasing demands to deliver on time - before time, and the delivery having quality, it's usually hard to find such cross-platform resources. The native and Java layers are so tightly coupled that having dedicated resources for each proves more of a headache than a solution.

I'm pretty sure that it's obvious to you that by linking with native code, JNI takes away one of the most powerful features of the language itself, "platform independence" (write once, run anywhere). It binds the application to the host platform. For example, when using JNI in a Windows environment, the Java application is forced to rely on the native DLLs for its functionality. The same application can't be ported without porting the native library to another platform. This also requires a proxy/stub approach when you want to access a COM server from Unix. This is an invasive procedure (you are deploying a potentially unknown code on the machine where the COM server is located, even if it's in the same intranet) and may not be allowed by the administrative policies governing the domain.

Another disadvantage, when linking with native code is the instability it may bring with it. A poorly written DLL (speaking of Windows) will bring down an entire JVM, taking with it some vital applications. And of course, try debugging that!

The architectures built on JNI look more or less like Figure 1.

Okay well...so what can be done about it? I sat down some months ago to develop an open source library that implements the DCOM protocol, thus allowing for pure, non-native, bi-directional interoperability with COM servers.

I'll try explaining my work in two steps. First I'll give you a primer on DCOM and its inner workings and then I'll talk about j-Interop. If you know how DCOM functions <i> under the hood</i>, you can skip to the section about j-Interop.

DCOM: What and How
Distributed COM or DCOM is a high-level network protocol developed to provide location transparency to COM-based components. The keywords being network protocol and location transparency. Traditional COM components can only perform inter-process communication across process boundaries on the same machine. DCOM uses an RPC mechanism to send and receive information transparently between COM components (clients and servers) on the same network. DCOM was first made available in 1995 with the initial release of Windows NT 4. Essentially, it serves the same purpose as CORBA or RMI. Please have a look at Figure 2.

In terms of an ISO OSI protocol stack, this is how it looks (see Figure 3).

As you can see, DCOM is an application level protocol. It leverages most of the functionality offered by DCE/RPC (see the side bar for a brief overview of DCE/RPC). Since DCE/RPC isn't naturally object-oriented, Microsoft's implementation enhanced the protocol by adding new constructs and providing different meanings to some of the packet fields. This enhanced protocol was christened the Object RPC (ORPC) or MS-RPC. Another significant change that Microsoft made to the protocol was the addition of an NTLM Security Service Provider. One disadvantage of this was the impossibility of any interoperability with other implementations of DCOM on platforms that don't have NTLM, since NTLMSSP is available only in MS-RPC.

Let's see how DCOM works.

DCOM (MS-RPC): Under the Hood
The best way to explain the inner workings of DCOM would be by creating a (COM) client/(COM) server application. I've used Visual Studio to create one. Since "how" to create a COM server (from now on referred to as a COM component) is outside the scope of this article, I won't be mentioning it here. It's best left for a tutorial.

Our COM component is an "out of process" server, i.e., an EXE. For the sake of brevity, it has a single interface "ITestCOMServer" that has a single API call, "Add," that adds two integers and returns the result. Also note, this example is void of any error checks.

HRESULT Add (int x, int y, [out] int* result);

The COM client will execute this API.

The first step is to obtain the "handle" to the COM class serving this interface. The following calls instantiate the COM server and also provide a pointer to its IUnknown interface.

IUnknown *ptrUnknown = NULL;
IITestCOMServer *ptrTestServer = NULL;
HRESULT hr = CoCreateInstance
(CLSID_ITestCOMServer, NULL, CLSCTX_REMOTE_SERVER, IID_IUnknown, (void**)&ptrUnknown);

The second step entails getting a pointer to the actual interface in which the "Add" method resides.

hr = ptrUnknown->QueryInterface(IID_IITestCOMServer, (void**)&ptrTestServer);

if (FAILED(hr))
{
cout << "Failed to get interface pointer, quitting";
}

The third step requires us to execute the "Add" API on the pointer obtained in step 2.

else
{
     int *result = new int;
     hr = ptrTestServer->Add(1,2,result);
     cout << "result of Add is " <<*result;
delete result;
}

The last step is to release all references to the COM server and let the COM runtime garbage collect it.

if (ptrTestServer)
{
ptrTestServer->Release();
}

ptrUnknown->Release();

Simple isn't it? Well, the COM runtime does a lot of work to orchestrate this cycle. Let me try to give you an overview of what happens behind the scenes. (Sources: www.opengroup.org, www.msj.com March 1998, DCOM specification)