System iNetwork

A side note ....

Actually I am already here. I hope to learn more about WDSc 7 amoung other things. Maybe even meet some of the developers.

Back to our regualarly schedule program .....

The usual way to isolate the data and business logic from the display is by coding it in programs, particularly service programs. This is not very useful to clients which aren't running on the System i. Non System i clients require a layer between the client and the programs which implement the business model. For example, web pages require the CGI layer between the HTML (web browser) and the service program.

Java can directly execute the programs which implement the business model, but not very well or very easily. The Java toolbox provides classes to execute commands and programs as well as a flavor of XML to simplify executing programs.

It most cases it takes too long to call a command or program through the Java toolbox each time the application interacts with the System i. The user won't be happy. Execution of these classes and methods has a lot of over head. The overhead is mostly on the System i which has to do all the work to prepare for the command or program, then execute it.

I am not criticizing the Java toolkit. These classes and methods are incredibly useful, and extend the capabilities of Java both on the System i and on clients connecting with a System i. But it is my experience they take too long when called each time the user does the equivalent of pressing Enter.

Java Native Interface (JNI) is a much more efficient method for Java to run programs that implement the business model. The Java JNI classes running on the System i execute programs natively. These programs can be business models, APIs, anything that could be called with CL, C or RPG! With JNI a Java client can have comparable performance to ILE in calling sub procedures, service programs, APIs, etc.

To access these JNI classes from the desktop client (or other platform) you have to use Remote Method Invocation (RMI).

Step by step it looks like this:
- the desktop application calls a local look-a-like method whose matching method is on the System i running as a RMI
- the network layer communicates with the matching RMI running on the System i
- the RMI natively uses JNI to call the business logic program or whatever written in RPG, C, CL, etc.
- the business logic program or whatever does its work and returns its results
- through JNI the results get back into the RMI program
- the network layer communicates the results to the look-alike method on the desktop
- the desktop application gets the results from the method

From the application side it is pretty simple:

results = MyRmiClass.foobar(param1, param2);

The above steps are hidden from the application programmer. The devil is in getting to the point where you are ready to write that line.

This is really a very efficient and robust method for Java on a remote system to execute programs on the System i. Really! "Remote system" can be a GUI client, another System i, a peer-to-peer application running on any platform which supports Java. Cool stuff.

And it is almost as complicated as it sounds -- but worth it if you have a Java something which needs fast and robust access to System i programs.

In summary, Java has two ways to call System i programs. The Java tool kit classes to call System i programs and commands are easy to use. For implementing MVC, they are too slow. The other way, JNI/RMI, is fast enough but is not easy to use. There is a better way.