framework question

["Richard Crosland" <richardc@xxxxxxxxxxxxxxxxxxx>]

Hi,
We are converting our existing RPG III software application system from a
green-screen base to a web browser enabled system. There are two major goals
we want to achieve by this conversion. First, the web browser based
front-end screens working with a Web Server such as Websphere on the iSeries
so that no interactive 5250 CPW is required. Secondly, we would like to
split each screen program into two, separating the screen program and
business logic service programs.  The service programs are written in RPG
ILE IV.

In an RPG AS400 environment the screen program flow is maintained by the
OS/400 system. When the first screen program is called from the menu, a
screen will pop up, then the user may press a function key or press ENTER to
call the second program, in the same manner. It may call several programs in
following layers, all screen programs are still in the memory on that
interactive job session, the call stack of all those screen programs are
kept by OS/400 automatically, it does not require any program logic within
any RPG programs to handle this situation. This is one of the excellent
features the iSeries system provides. When a user wants to return from the
current screen to a previous screen (usually F12), the current program will
exit so that the control will return to the previous screen program
automatically, and the previous screen field values are restored
automatically.

On the web side we use our own front controller MVC pattern and use PCML /
ProgramCallDocument class from the iSeries toolbox to call service program
procedures that hold the business logic.  Naturally due to the stateless
nature of the HTTP protocol there is no application stack that maintains
state across requests.  However all the service program procedures require
state be maintained across requests and procedure calls (i.e. same global
variables are used by multiple procedures in the service program).
Therefore the ProgramCallDocument object must be held in a session variable
so it is retrievable for a future http request.  As the user navigates
through web pages the ProgramCallDocument objects, JavaBean objects and the
tracking info of screens visited is added to session variables.  Once the
user returns back (F12) the current web page's ProgramCallDocument objects,
JavaBean objects and the tracking info of a screen visited can be removed
from the session variable.

The coding required to maintain the information for each screen and user
navigation is not trivial and any suggestions on frameworks or new ways of
thinking about these issues would be very helpful.

Thank you,
Rich