RE: [WEB400] Beyond RPG CGI

["Bartell, Aaron L. (TC)" <ALBartell@xxxxxxxxxxxxxx>]

Nathan,

GREAT POST!  You have got my brain thinking "out of the box"!  I have never
thought of the communications in that manner.  I have one question for you
though about how you pass state through your applications without using
hidden fields(because this is what I do:-).

Here is what you said.
<snip>
It's also a good idea to have a service program to manage user state data,
rather than using query string parameters, cookies, and hidden form
variables to track state.
</snip>

So how do you do it?

Aaron Bartell

-----Original Message-----
From: Nathan M. Andelin [mailto:nandelin@relational-data.com]
Sent: Monday, April 01, 2002 8:59 AM
To: web400@midrange.com
Subject: Re: [WEB400] Beyond RPG CGI


> From: "Mike Skvarenina"
> So my question is, what is your shop doing beyond
> RPG CGI?  One area I am seriously considering is firing
> up our WebSphere server and learning to use it and Java.

The next step after CGI?  It has little to do with RPG or Java.  It has much
to do with how YOU choose to design your applications.  I suspect your real
interest in Java is what it might add to your resume.  That's fine, but if
you're seriously interested in the next step, you need to think more about
high-level design.

Most programmers don't conscientiously consider this next point.  But one of
the reasons that green-screen applications have been so successful is
because they are structured around the READ opcode.  Green-screen programs
spend most of their time waiting for user input.  They implement an
initialization process, followed by one or more loops in which the user I/O
is handled, then eventually a clean-up subroutine is triggered by user
input.  Structuring an application around a READ opcode provides a better
basis for highly efficient, robust, interactive use.

The CGI API on the other hand, is geared for applications in which
initialization, user I/O, and clean-up are handled for each request.  That's
not a very good model for robust, highly-interactive applications.  It's
better suited for simple transactions and inquiries that are called
infrequently.

CGI programmers tend to come up with their own sloppy tricks to overcome the
nature of the API.  Initialization code is conditioned on an IF statement.
Named activation groups are used (which often leads to file and other
resource conflicts, and essentially results in a perpetual memory leak under
high-use scenarios).  Clean-up is left to some equivalent of the ENDJOB
command.  When the database is being backed-up, or memory needs to be freed,
the HTTP server is shut down.  You find yourself dropping the HTTP server's
support of persistent connections and reducing the number of HTTP server
threads in an attempt to "tune" your site.  If you have reached that point,
then it's no wonder that you're interested in the next step.

No.  The next step is not dependent on Java or any other language.  The next
step is to implement a message interface between the HTTP Server and your
ILE applications, and to fully use Model-View-Controller design.  That
should be done regardless of your language or platform of choice.

You can still use the RPG CGI, but the CGI program should do little more
than read STDIN, then pass the input stream (and environment variables) to
your "Controller" via data queue (or other alternative), then wait for a
response from your Controller, which can then be written to STDOUT.  The
Controller should be a program that is structured around some sort of READ
loop that handles messages on the queue.

A single well-designed CGI utility program could be used to handle
communication between the HTTP server and all your Web applications.

Your Controllers should use a common set of service program subprocedures to
automatically parse any environment variables, query string parameters, and
form variables received.  Your Controllers should be able to reference any
variable values by name.  Other common subprocedures should support the
generation of formatted output, without the need to imbed HTML in your
program.  It's also a good idea to have a service program to manage user
state data, rather than using query string parameters, cookies, and hidden
form variables to track state.

If that sounds like a lot of work, then I'd encourage you to find out about
my Relational-Web framework at:

http://www.relational-data.com/products/relational-web.htm

Java programmers face many of the same issues that RPG programmers do.  The
Servlet API is slightly more robust than the CGI API.  It supports
initialization, service, and termination entry points.  But Servlets, like
CGI programs, are essentially called.  In and of themselves, they don't
support Model-View-Controller design any better than CGI programs.  For
that, you have various components within Websphere to help you, or you can
use a 3rd party product like STRUTS, or you can design your own.

I agree with Joe Pluta - that RPG is much better than Java and it's various
methods of handling database I/O and business logic.  And that a message
interface should separate the Java components from the RPG components.

Joe apparently has a nice product for converting green-screen programs to
deploy HTML and other formatted streams.  Under his architecture, I think
you're still essentially tied to the standard 24 X 80 and 27 X 132 screen
formats - but that could be a good thing.  It depends on the application.

Otherwise I'd suggest that you design your own generic data queue interface.
Use Servlets and JSPs to generate HTML formatted streams.  And use the
iSeries Java Toolbox to handle communication between your Java components
and your RPG servers.

Nathan M. Andelin
www.relational-data.com






_______________________________________________
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/web400
or email: WEB400-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.