March 05, 2001, 1:29 PM — IT professionals must often marry old and new technologies, a challenge requiring the technical knowledge to evaluate which tools are best for a particular project. We show you how to integrate a legacy accounting application, which we will call "Beetle," and a new sales force automation program called "Aphid," using Java Native Interface (JNI) as our tool of choice. This article is aimed primarily at Windows developers, but many of the considerations apply to other platforms as well.
Beetle is a double-entry accounting system that tracks A/R, A/P, and payroll. Sales representatives use Aphid to track their calls, appointments, and sales by account. In accounting, the term double entry means that a credit is balanced by a debit and vice versa, so Beetle's double-entry system ensures that balance is achieved.
In application development, however, double entry means that the same information is manually entered twice, usually on two separate systems. Not only is that inefficient but also a basis for human error; our goal is to eliminate that form of double entry by integrating Aphid and Beetle. When a sales representative completes a sale, Aphid will enter the invoice into Beetle, along with the representative's 5 percent commission. To help motivate our sales force, Aphid will display all the representative's commissions, with payment status extracted from Beetle.
Assess the technology
The first step in our development project is to determine the appropriate technology for the job. Because platform, connectivity, and storage decisions are usually predetermined, often mandated from above, our best bet is to use a software model that can perform independent of, or at least very loosely dependent on, the technology. When it comes to legacy applications, we don't have too many options: Beetle was already written in C, using ODBC to manipulate an Access database. A secondary consideration is a movement elsewhere in the company to migrate to Oracle, but that's a decision over which we have no control right now.
In this case, using Java makes the most sense. Because we need to integrate with a C application, C++ might appear an attractive choice at first glance. But the sales representatives travel quite frequently, and they need access, either disconnected or dialed-in from a hotel room, to the application from their laptops. For Aphid, we want to take advantage of Java's power on both the server and the client, and use XML for storage and transmission; the need for an XML-based disconnected client/server solution determines Java as our tool of choice. When choosing a technology, remember to weigh all the project's requirements and not let one specific detail -- such as C integration -- force us into a particular implementation.
Fortunately, Java Native Interface gives us the flexibility that we require. JNI was developed as a way for Java applications to take advantage of platform-native resources; it allows the Java VM to interoperate with applications and libraries written in C, C++, assembly, and several other languages. With JNI, not only can Java call native code but the native code can also create and manipulate Java objects. The result is that JNI allows full language interoperability, making it an ideal candidate for legacy application integration.
To integrate Aphid with Beetle, we could have chosen to access the database directly through JDBC, which would have yielded disastrous consequences. Because much of the business logic that is necessary for proper operation (such as balance-based double entry) is actually encoded within Beetle, circumventing the application would require us to duplicate the business logic in Aphid.
Moreover, the possibility of an Oracle migration means that we can't be sure of the future database schema, and much of the business logic could eventually be pushed down into stored procedures. Coding Aphid directly to the database opens it up to maintenance problems down the road. Going through the JNI interface, though, localizes future changes and isolates Aphid from significant maintenance concerns.
