IBM SG24-6526-00 User Manual
18
Geac System21 commerce.connect: Implementation on the iSeries Server
There are two disadvantages:
The first is primarily stylistic. Using Toolbox for Java would make Java look more iSeries
specific.
specific.
The second is that Toolbox for Java would form its own connection independently of any
JDBC connection. This would mean that updates made by iSeries programs called in this
way could not easily be part of the same commit transaction as updates made through
JDBC.
JDBC connection. This would mean that updates made by iSeries programs called in this
way could not easily be part of the same commit transaction as updates made through
JDBC.
The first objection is more apparent than real. Toolbox for Java is 100% Pure Java. Therefore,
its use does not restrict the portability of the Java code. The second objection is more
significant.
its use does not restrict the portability of the Java code. The second objection is more
significant.
Java Native Interface (JNI)
Sun defines a technique for calling between Java and native code called the
Java Native
Interface
. By native, Sun means non-Java code supported by the underlying platform. All of
the Sun documentation discusses C and C++, but it is also possible with RPG on the iSeries.
At V4R4 and V4R5, it was quite difficult to integrate Java and RPG. At V5R1, it became much
easier. If V4R5 had to be supported, then the coding complexity would be an issue.
easier. If V4R5 had to be supported, then the coding complexity would be an issue.
At V5R1, there was no longer an issue but another objection remained. JNI is a direct call and
the native code would have to be on the same system. This would force an element of Java
onto the iSeries and restrict the deployment options for the application. The entire application
would not have to be on the iSeries since some form of remote invocation could be used, but
would add a considerable degree of complexity.
the native code would have to be on the same system. This would force an element of Java
onto the iSeries and restrict the deployment options for the application. The entire application
would not have to be on the iSeries since some form of remote invocation could be used, but
would add a considerable degree of complexity.
Stored procedures
There are two forms of stored procedure on the iSeries server. They may be written in
Structured Query Language (SQL) or in most other supported languages for example, RPG
and CL.
Structured Query Language (SQL) or in most other supported languages for example, RPG
and CL.
Geac does the reverse of typical usage. It does not have a stored procedure and then decide
to write it in RPG. Instead, Geac already has RPG and creates a stored procedure, which
becomes the program. This stored procedure can then easily be called using JDBC from
Java. For a programmer who has learned basic SQL and JDBC, this is easy.
to write it in RPG. Instead, Geac already has RPG and creates a stored procedure, which
becomes the program. This stored procedure can then easily be called using JDBC from
Java. For a programmer who has learned basic SQL and JDBC, this is easy.
The choice
JNI is probably the best performing option. However, its restrictions on deployment options
eliminated it. Also V5R1 did not exist at the time that Geac made the choice, and the
complexity of JNI prior to V5R1 counted against it.
eliminated it. Also V5R1 did not exist at the time that Geac made the choice, and the
complexity of JNI prior to V5R1 counted against it.
The performance of the IBM Toolbox for Java and stored procedure options is similar. The
coding complexity is similar but stored procedures have the advantage of similarity with other
SQL. The final decision was made based on the ability of stored procedures to share
connections and partake in transactions.
coding complexity is similar but stored procedures have the advantage of similarity with other
SQL. The final decision was made based on the ability of stored procedures to share
connections and partake in transactions.