Aaron,
This is interesting. You are asking for features that are standard and
included within IceBreak. IceBreak uses this exact same technique where each
session has its own System i job underneath the IceBreak subsystem.
In this way, you will have a situation where RPG fields, QTEMP, job logs,
and so on are separated like in 5250. You can even start a 5250 debug
session directly on the running RPG program (or COBOL).
But instead of having Apache as the front end server, IceBreak controls the
entire process. IceBreak is a complete native ILE engine. You can say that
IceBreak does two jobs here. First, as a ?mother router? (http server)
controlled by a session ID and second the controlling layer that calls the
?business logic? in a stateful System i job.
Regards,
Bent Ronne, Agent Data
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Aaron Bartell
Sent: 5. juni 2008 20:58
To: Web Enabling the AS400 / iSeries
Subject: [WEB400] Thinking out loud about a new RPG web framework
What if you could create a programming experience that allowed the RPG
programmer to code just like they were communicating with a green screen as
far as program state is concerned, but instead be communicating with the
browser?
Here's what I am thinking (I need to get it out of my head before it
explodes, and thanks Jon Paris for starting my wheels turning in this
direction, and to Joe Pluta for introducing the JSP approach to this):
Have a "mother router" program that sits under Apache and all it does is
receives in HTTP requests from the browser and based on a hidden form value
(or cookie storing a session ID) it would appropriately "write" that request
to a keyed data queue where a program is waiting for that specific session
key. Upon receiving the data queue entry, the business logic program
processes the contents of the HTTP post by evaluating the action that was
taken (just like how green screen programming checks for the function key).
It then determines what to respond with and goes back into a wait state on a
data queue "read" (just like waiting on EXFMT). The benefit in this case is
that all global variables, open data paths, and SQL cursors were able to
remain open and stateful as it relates to that specific users interactions.
The data queue layer is basically acting as the replacement mechanism for
EXFMT.
The issue I had previously is that each web browsing user had their own job
on the iSeries which could potentially become burdensome for a public
website with thousands of users coming in.
With V6R1 RPG is now completely thread scope safe. This means that you
could (in theory) spawn a new thread for each web browsing user within a
SINGLE job on the system. The purpose behind this would be to save on the
number of jobs on the system, though I have nothing to quantify the resource
savings of threads vs. jobs, except for I imagine spawning a thread is
"cheaper" than creating a job.
Does anybody know if the RenaissanceFramework operates in a similar fashion?
(
http://www.renaissanceframework.com/)
Obviously this only solves one of many problems RPG programmers face with
web UI programming. The other thing I have in mind is a way to compose
forms (not necessarily HTML) using an "intermediary syntax". The
intermediary syntax would basically have things like field x/y coordinates
along with size, color, onclick actions, etc. The intermediary syntax would
be rendered to the client based upon a "Render Kit" (stealing from JSF
terms here). In the case of talking with the browser, the intermediary
syntax would be rendered to HTML using CSS positioning and Javascript to
spawn user events back up to the server. In the case of talking to the
desktop, the intermediary syntax could be rendered to XML and the desktop
thin client could be written in Java/.NET/etc and spawn events back based on
user events.
I am starting to prove out the different concepts by writing smaller pieces
of code to document the proof of concept. For example, at the bottom of
this email I have included screen_stack.html and css_positioning.html
showing a couple of the concepts. My next step is to do the data queue and
"mother router" proof of concept.
I am starting an online place to start progressing on this initiative at
http://www.assembla.com/wiki/show/RPGUI
Of the upmost importance is that this project be open source and free from
vendor lock-in. Let me know if you would like to assist with this
initiative and I will give access to the assembla project.
Thoughts anyone?
Aaron Bartell
http://mowyourlawn.com
screen_stack.html:
http://code.midrange.com/95f4583917.html
css_positioning.html:
http://code.midrange.com/240aed98ca.html
midrange.com
