Integrating Oracle and Java: Optimizing your development platform for ERP apps

Bringing Oracle and Java together in your development environment gives you an exceptionally flexible and robust application development and data-handling infrastructure that fronts an excellent data management system and is easily extended in enterprise resource planning. On top of that, it’s extremely Internet-friendly, an increasingly important consideration.

The complication you must address in choosing them in combination for application development, particularly in an ERP environment, is that there is so much available that prudent choices require some forethought. Here’s a rundown on which parts of Java are especially useful with Oracle 8i, the specifics of Oracle’s accommodation of Java, and how these can work well in ERP applications.

JServer: A Java machine living inside Oracle
Beginning with 8i, Oracle has included JServer, a suite of Java facilities that deeply integrate Java and Oracle in powerful ways. This suite features an accommodation of Java that brings all the ERP-friendly characteristics of Java—its platform independence, its flexibility in communication modes, and its powerful class library and tool base—directly into the Oracle database environment, where database interaction and efficiency can be firmly bound to Java’s application strengths.

You pay a price in complexity, to be sure, but you increase the potential power of your application interfaces by an order of magnitude (very important in ERP distributed apps where one application has multiple interfaces). You avail yourself of all the robustness of Oracle in external applications (a powerful consideration in an extended ERP environment containing multiple databases), and your interfaces are instantly portable to other environments—a boon for ERP systems.

Rethinking PL/SQL
ERP systems are primarily about tying multiple databases to myriad external applications in new ways, increasing data accessibility by an order of magnitude or so in the process (for the purpose of feeding external applications, even extending to the systems of other companies). A primary consideration in choosing an interface mechanism, then, is the facility with which an external application can execute procedures that are read- or write-intensive while accommodating multiple access paths to foreign platforms and maintaining security in the bargain. You need an extremely flexible interface toolkit for such an undertaking, and the more class libraries, the better.

Your first and foremost design choice is considering whether to hand off to Java a number of duties that you would otherwise assign to PL/SQL. How can you do this? With a Java Stored Procedure (JSP), also known as a Java Method. Since 8i, Oracle has permitted Java as a language for implementing the same sort of external procedures that are commonly assigned to PL/SQL.

You can safely implement an external procedure with Java, an interpreted language, without configuring a listener (as you must when doing external procedures in a compiled language). The Java code does not run as a separate process. Oracle even provides an area in the database address space for the execution of the procedure—the Java Virtual Machine. There is little that PL/SQL can do for you, external procedurewise, that Java won’t do better.

For example (and this is the most obvious), PL/SQL isn’t going to do you much good in coping with the external operating systems that your database interfaces are running on, and the platform-independent Java was made for such tasks. You have new possibilities open to you that PL/SQL never provided: A JSP can run operating system programs from within the database. This is useful when your external procedure is sensitive to database run-time conditions.

Why use JSPs other than for interface tasks and OS programs?
There are several reasons why Java is just plain better than PL/SQL for external procedures. For one thing, it’s much more robust than PL/SQL. Java has hundreds of classes, making interfaces of considerable functionality possible. You simply have far more options with Java than with PL/SQL.