RE: Re: Re: Modify the IE Browser

> From: Buck
> 
> Because the browser isn't a block mode device, we need to be able to
twist
> it into something it wasn't really designed to do.  Unless we are
willing
> to
> spend a year or five and completely re-architect our implicitly block
mode
> application into a stateless, character mode application.  Few
companies
> are
> willing to do that, so we sit at this uneasy truce between RPG and the
> web.

I have a nitpick with this, but then again I sell a middleware solution
in this space, so I'm a little biased <grin>.  My disagreement is that
the browser is a stateless, BLOCK mode device, not character mode.
That's important, because it doesn't take quite as much work to go from
stateful 5250 application to stateless browser applications.  Why?
Because there is an intermediate step of rewriting the business logic
into servers and using the old 5250 interface as a front end.

That's what my original e-Deployment book was all about.  Maybe it was
just a little ahead of its time.  My idea is that you provide a
graphical front end to your existing 5250 applications using something
like PSC/400.  That gets you graphical and removes the interactive tax.
And while the screens aren't exactly beautiful, they're quite
serviceable (and we've gotten to the point where the screens are
actually very nice looking, but that's product marketing talk <grin>).

Once you've done that, you've bought yourself enough time to rewrite
mission critical workflows (such as sales order management) into
servers.  Leave the 5250 programs in place, but rewrite them to invoke
server programs - for example, a server program that retrieves a set of
orders, or a server program that updates a line item.  Once you have
converted the monolithic applications in the stream into server
programs, you can remove the middleware (i.e., PSC/400) and use your
JSPs to directly invoke the servers (well, the servlet would invoke the
servers and create beans with the data, that it would then pass to the
JSP).

That's the primary reason I like JSPs.  If you design the JSP with a
simple interface (getNextRecord, getFormattedField) then it's relatively
easy to replace the middleware beans from a product like PSC/400 with
your own custom beans that talk to your servers.

Once you've gotten to that point, you have in effect rewritten your
entire application from stateful server/client to true stateless
client/server architecture.  Yes, there are still session state issues;
you need to keep track of lots of things going on for reasons that range
from security to session reconnect, but those are system architecture
issues, and don't affect the evolutionary path of the application that
I've outlined here.

Sure, this is a thinly veiled pitch for my product, since PSC/400 gets
you to the middle step overnight, but you can in fact do it yourself.
It's a traditional make vs. buy decision.  And even if you decide to do
it yourself, go out and buy my e-Deployment book <grin>.

Joe Pluta
Pluta Brothers Design, Inc.
Developers of PSC/400 
www.plutabrothers.com/p1.html