email article printer friendly

The In-Process
Integration Alternative
Consider applying a middleware solution for interoperability challenges as a more streamlined approach than ESBs or Web services
by Alex Krapf

October 23, 2006

Integrating applications is time consuming, expensive, and fraught with risk. Before climbing aboard the enterprise service bus (ESB) or turning to Web services, many organizations are using "in-process" integration to tackle specific Java-to-C++ interoperability challenges. In-process integration is a middleware alternative that doesn't require the external processes or servers that alternative approaches require. This lean integration approach results in improved security, less communication overhead, and performance that is faster by orders of magnitude. In a report published earlier this year, Forrester Research cited in-process integration as a strategic alternative for some companies working in a tightly distributed system.

There are many use cases that require the developer to integrate components written in Java with software written in C++. Some of the problems that are encountered often are:

• Publishing a C++ version of the developer's Java API
• Integrating a C++ application with enterprise Java APIs—Enterprise JavaBeans (EJB), Java Message Service (JMS), and Java Naming and Directory Interface (JNDI)
• Using a unique third-party Java library from a C++ application
• Displaying existing Java GUIs in a C++ application

We can discuss Java/C++ integration by looking at the second problem category—using an enterprise Java API, in this case the JMS. While the in-process integration approach is not solely reliant on or limited to JMS, we chose JMS as our example for two reasons: it's a real-life use case that is immediately appealing to many people, and it's a beautiful example of mixing in-process and out-of-process integration technology.

In case you're not familiar with JMS it's a specification for performing asynchronous messaging between Java applications. Sun Microsystems maintains the API specification, which in turn is implemented by several dozens of independent messaging providers. Every J2EE application server comes bundled with a JMS implementation, but you can also use one of many free or commercial stand-alone messaging implementations if all you need is messaging. JMS is a very popular Java enterprise API, and there are many people who have to integrate with it or would like to leverage this technology from their C++ applications. Following the old adage of "one picture being worth more than a thousand words," we can illustrate the integration problem at the architectural level (see Figure 1).

Mix It Up
As mentioned previously, a modern developer's integration toolbox contains a variety of tools for integrating Java and C++ components. The most common are ESB, CORBA, Web services, and Java Native Interface (JNI).

JNI is significantly different from not only the first three options mentioned, but all other integration approaches. JNI allows you to mix Java and C or C++ within one process. Basically, you can call a JNI C function that results in an action being taken on the Java side within your C or C++ process. Contrast that process to all the other integration approaches that have the Java and C++ components running in different processes and have to use some kind of inter-process communications to achieve integration. Consequently, in-process integration through JNI has some very attractive technical characteristics when compared with all other integration technologies:

• JNI is fast. The cost of a JNI call is comparable to the cost of an expensive virtual function call; interprocess calls are usually several orders of magnitude slower. There is also very little data marshaling involved.
• JNI is secure. There are no interprocess communications; all calls are within one process, which is comparable to calling a function that is exported by a shared library. Expensive security measures (both in terms of performance and money) like authentication or encryption are not required.
• JNI is reliable. You might cringe as you are reading this statement if you have written JNI code by hand. Your reaction is simply because of JNI's ease of use, or better, the lack thereof, not because of any technical shortcomings. When we look at the integration problem, JNI is the only approach that doesn't introduce additional failure modes into the integrated solution. An error-free, JNI-based application will either work (if it is configured correctly) or not (if it is configured incorrectly). The same cannot be said for solutions that rely on interprocess communications or the availability and reachability of server applications.