Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Standard Edition >

Integrate your legacy applications with JNI

Learn how to integrate a legacy accounting application and a new sales force automation program using JNI

By Michael L. Perry and Itworld.com, JavaWorld.com, 03/16/01

  • Print
  • Feedback
.

Page 2 of 5

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.

Model the information

Once we have decided upon the technology, the next step is to create the information model, otherwise known as the software model. Beetle is based on a relational database, so we can simply extract the entity relationship diagram in Figure 1. The most important tables are Transaction and Entry. Each transaction consists of two or more entries, each a credit or debit to a particular account. The total credits for any given transaction must equal the total debits, and Beetle's C code ensures that balance is always met.

Figure 1. Beetle's entity relationship diagram.
A transaction consists of a number of entries,
each a credit or debit to a particular account.



Because Aphid is written in an object-oriented language, its information model is most easily expressed in UML. The model for Aphid appears in the left side of Figure 2. UML's diamond notation denotes ownership instead of aggregation -- ownership is a more rigorous relationship than aggregation, as each object (except a singleton) has exactly one owner. In Aphid, the Company singleton owns everything else.

Figure 2. Aphid's UML structure diagram.
The pieces of the Beetle model that are
important to Aphid are included, trans-
lated from ERD to UML.



To illustrate the relationship between the two applications, the important pieces of the Beetle ERD are translated into UML on the right side of Figure 2. To fulfill the rule of ownership, the Beetle model also includes a Company singleton. (As we will see when we start coding, that extra object will come in quite handy.) Then we map the Aphid objects to their corresponding Beetle objects: a representative is an employee of the company, an account is the rep's term for a customer, and a sale generates both an invoice and a commission.

Aphid has its own information model, separate from -- but connected to -- the Beetle information model. Aphid will need its own storage mechanism as well. We've already decided to use XML for storage, but we still need to figure out how to join Aphid's XML document to Beetle's relational database. Beetle must share a secret about each object in which Aphid is interested, so that Aphid can persist the connection and request the object the next time it is needed. Beetle must share each record's key and, to avoid excessive dependence on Beetle's database schema, Aphid will treat all keys as text strings, or cookies. Aphid will retrieve its cookies from Beetle, return its cookies to Beetle, and make no further assumptions about the information.

  • Print
  • Feedback

Resources