RPG (iSeries) Modernization using JTOpen - What is possible?

We would be in near future implementing a solution to modernize our iSeries applications开发者_Python百科 written as RPG programs with some stored procedures, and our preferred way is leveraging the latest and greatest of what Java has to offer in this space.

From googling and checking other questions here on STOVFlow, JTOpen seems to be the defacto library/toolset which has worked for most and I was encouraged to see that Tomcat runs on an I-series box with out any issues.

With this as the background, I am thinking of the following as the high level sol arch

1. Install IBM JRE and use JTOpen's capabilities to invoke RPG Programs and in some cases directly call the stored procedures running on DB2
2. Have Tomcat host a modern web application built using Grails and other frameworks (Camel, Smooks) to provide an application logic layer which would fill any mediations, transformations required for the old functionality to be offered to the user from a browser

Questions-

1. If any one of you has been involved in such an exercise, please share the pitfalls with this approach
2. Is there a significant performance drop with respect to response times for the end user?
3. Would it be better to some how expose the JT400 code as web services and run the web app on a different machine altogether consuming these web services?

Be very careful with calling RPG from Java because RPG is not threadsafe without some changes.

When I was at COMMON, the best product I felt on the market was Profound UI. There are several others from a variety of vendors. Most of these products do not use Java. Java on the i tends to be slow. (There are things that can be done to make it faster, but native is always faster.) You'll pay the price for these products, but just imagine how much time it would take you to do this yourself. For the above, I was quoted in the $20+ thousand range. But like all i products prices vary greatly based on system.

To directly answer your questions:

1. I have been doing research on modernization as time allows, the products weren't quite there yet (at the time I looked) to use it for what we wanted to use it for (before COMMON 2011). Now it looks like it might work.
2. This really depends on your system. A newer system will have less problems than an older system. Web will always be slower than the green-screen. Hands-down entry people won't like it. Executives and younger people will love it.
3. Your slow point is running the business logic. It wouldn't matter which server the HTML is coming from.

I've found that for all practical purposes an AS/400 behaves like an AIX box seen from Java code, and you must use jt400 (jtOpen) to communicate with the AS/400 specific features like data queues, files etc. This works pretty well, but the slowness of invoking the JVM pressures Java based solutions to be long running.

Note also that QTEMP is generally unavailable as a mechanism to keep state due to the nature of prestarted jobs.

Under V6R1 Java 6 is available and runs pretty well in the "new technology" edition. You can then run almost all Java based solutions, including web servers like Jetty in it. Note that Java defaults to code page 819 when accessing IFS files directly. Windows clients using AS/400 as a network drive uses a compatible code page.