RE: framework question

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: Richard Crosland
> 
> 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.

In my opinion, this is the problem.

If you want to take advantage of the capabilities of the AS/400 concept
of an interactive job, I would move the controller to the AS/400.  The
controller pieces invokes the service programs, but then it determines
which JSP to present to the user.

Typically, the flow is like this: user logs on, servlet calls a startup
class that creates data queues and submits a job.  The submitted job is
the controller.  That controller then determines what the next screen to
display is.  Typically this would be a main menu.  So, the controller
would call a server to retrieve the main menu options and sends them to
the servlet as messages.  The servlet takes those messages and builds
beans in the session.

Finally, the main menu controller tells the servlet which JSP to show
(the main menu JSP).  This JSP displays the appropriate beans, then
initiates a response back to the servlet.  The servlet formats the
response and sends it back to the controller.

At this point, the controller can call another program.  The new program
is also a controller, but it is now application specific.  Maybe it's a
customer inquiry screen, and its job is to present a list of customers.
So it invokes a server to collect the customer records, formats each
customer into a message and sends it to the servlet.  The servlet
formats these messages into a bean in the session, and eventually the
customer list controller sends a request for the appropriate JSP.  This
JSP is presented to the user, the user (for example) selects a customer,
the customer selected is formatted and sent back to the controller, and
the controller now calls the customer maintenance controller.

I call this server/client programming; your RPG programs still retain
control of the application flow, using the browser as a pure replacement
for the 5250.  Of course, it is much more elegant, as you can send all
manner of initial information at the beginning and create session-level
beans that can be shared by all JSPs, and if you've designed your
controller carefully, you can easily shortcut from one panel to another.

The design is fast, flexible, and most of your logic is in RPG.  There's
really very little work required on the web side except to show beans
and convert messages to objects and vice versa.

Joe