System iNetwork

The Model is data queue enabled with one or more programs (servers) running on the System i. The data queue handling programs
- monitor input data queues for instructions from the view-controller (client), for example "read" a record, "update" a record, "execute" a transaction.
- call existing programs (the Model) to perform the business functions.
- send the results to the client (view-controller) on output data queues, for example the "record read", "status of the update", results of the "executed transaction."

One input and one output data queue is used. The input data queue is a non-keyed FIFO. The data on this queue is
- an identifier of the view-controller or client
- an instruction to the model
- data which the model is to act

The output data queue is keyed, the key is the identifier of the view-controller or client. The data on this queue is
- the instruction echoed back as confirmation
- the data that is the result of the model's action

The view-controller (client) sends the model (server) the request on the model input data queue and then reads the model output data queue by its identifier (key), waiting for the response.

Ideally business logic is isolated in callable programs, service or OPN-like. The data queue handling programs callses these programs that support the application business logic. The program processing the data queues accesses the business logic in whatever way makes sense.

The data queue handlers could be implemented as more than one program. Each program "peeks" at the input data queue (checking incoming messages) and the program which processes the "instruction" reads and removes it from the queue. An alternative would be to make the input data queues keyed and the different programs read for the specific keys that they operate on.

The model (server) program is "stateless". It executes with just the information from the input data queue, does it works, writes the output data queue, and waits for the next data queue entry. The program has no "state" from previous executions. The view-controller or client does all the remembering. This is similar to a CGI program for a HTML server and web page.

A very thorough explanation with examples of the data queue server model is presented in the IBM Redbook "Who Knew You Could Do That with RPG IV? A Sorcerer’s Guide to System Access and More" (SG24-5402-00). See section 5.2. The source for the examples can be downloaded. The instructions to download the source are in Appendix 1.

This design is scalable. One "server" program (or set of programs) can handle many clients. Additional instances of the "server" program (or set of programs) can be started if needed.

Remember, the "clients" or "view-controllers" can be anything which can communicate with the System i with data queues. Another System i, 5250 display programs, web services running on the System i and even C++ desktop clients. Use your imagination. The data queue handling programs won't know the difference nor will the model / business logic.

This design overcomes the performance problems of calling programs or commands through the Java toolbox. The model programs are running in batch on the System i. There is no start up penalty each time the client "communicates" with them.

What kind of performance can be expected?. The stock answer is "it depends."

For this blog I developed
- a demonstration model/server for the System i
- a demonstration Java view-controller for the desktop using the console (DOS prompt window)
The code for both of these will be posted in the future.

The System i model (server) is running on a Model 170. The PC Java view-controller connects to the System i through the Internet (cable modem). The model is like the data queue server described in the Redbook, it only move fields from one data queue to the other and doesn't do any processing.

The best times I have observed from the view-controller side is less than 100 milliseconds both to send the instruction to the model running on the 170 and to received the response from the model. That is under 100 ms (70-80 actually) each way. Not bad.

One of the console Java applications (see the code for this blog) shows the time in milliseconds it takes to send the message to the data queue and then to receive the result from the demonstration server. Test it yourself!

You can expect better performance in a local area network than over the Internet. However the performance will drop when the model actually does something, has to compete for resource, etc.