From: Mike
Based on that, why use the iSeries at all except as a database
server?
In a Web 2.0 world, RPG [for us] is the thing that responds to browser
events.
By browser events, I mean ANY event - including any keyboard, mouse, or DOM
event - not just the submit button. That may seem like a bold statement, but it's true. I'll explain.
Say a page has a drop-down combo box - a list of organizational entities. RPG
might respond to the "select" event by returning a list of GL accounts
pertaining to that entity - to fill in an adjacent combo box asynchronously.
In another case, a page might have a list of email messages, where the arrow
keys move the highlight bar up or down the list. RPG might respond by returning
a complete message - for display in the content pane - when a new message is
selected.
A good way to stress-test that application might be to get about 20 users to
press and HOLD DOWN an arrow key, all at the same time, and watch messages fly
up on the screens in an unreadable blur, as the highlight bars scroll through
the list at a rate of about 25 per second.
RPG makes it possible to deploy server-based applications, that offer
desktop-like performance. You might TRY the same thing with another language & web interface, but
the interactions are so slow that you don't get the same effect.
In addition to making it possible to deploy server-based applications that
offer desk-top like performance, RPG also takes care of data concurrency issues. Say a teacher is grading classroom assignments via Web 2.0 interface.
The Ctrl-A keystroke selects [and highlights] all students in the class. The F2 key toggles update-mode on, while the 1st student's assignment record
is retrieved & displayed in the content pane.
The Enter key updates the record, the highlight is removed from that line,
the grade appears in the list, the next student's record is automatically
retrieved & displayed in the content pane.
The teacher repeats the cycle for each student, until complete. A lot of I/O
[including data & messages] going back & forth between browser &
server, all in real-time, using RPG.
If a developer were building the same type of interface, using an Adobe Flex
or Microsoft Silverlight client, and interfacing with a .Net service instead of
RPG, there would be a strong tendency to download ALL the assignment records to
the workstation in one operation, and temporarily store the updates locally as
they occur. Then post them to the server as a complete batch, in order to reduce
server I/O.
One problem with the latter is that while the data is temporarily on the
workstation, there is a potential of it becoming out-of-sync with the server.
And responding to errors in a batch is always more difficult and time consuming
than responding to individual update requests.
RPG is the better tool.
The browser interfaces that we've come up with are so streamlined now, that
we almost think of RPG as a GUI language. It's cool how one's perception can
change. Our RPG applications respond so quickly to Web 2.0 interfaces that it almost
seems like programs are running locally, on a hand-held device, laptop, or
workstation.
By indicating that an RPG program may be responding to any keyboard, mouse,
or DOM event [even repeating events - like typing or pressing and holding a key
down], I don't want to minimize the level of control that RPG programs may have
over the interface.
Most of our applications run within a web portal context, where clicking a
menu item generally launches a new instance of an application [starts a new IBM
i job] for an individual user, which has an initialization step where HTML
templates and database tables are opened, and a connection to an SQL Server
prestart job may be instantiated. That takes 1-2 seconds.
The program displays an entry-point page, then waits for any kind event from
the browser. The server is in complete control of how it responds to every event
thereafter, and may even decide to output code that automatically triggers new
events, itself. In many ways, the browser is subordinate to the server.
Until the user clicks the "Exit" link - at which time, the program releases
all its resources and the job ends. But under a web portal context, users may simply keep any number of programs
active, and toggle between any of them and the menu system, by just one click.
The portal automatically retains the state of each application where it left
off. On the other hand, a portal administrator may configure any application to
end automatically after a period of inactivity.
You solve a lot of problems by hosting both applications and data on an IBM i server.
-Nathan.
midrange.com
