Re: ASNA VRPG for .net or Websmart or RPGsp or somethingelse?

Joe,

We've shared so much common ground over the years that
our exchanges never break out in flames.  I'm glad
when you qualify my generalizations.  One of my
colleagues also tells me that you're a heck of a nice
guy in person ;-).

The last time I looked at HATS, which converts 5250
screens into HTML, I seem to recall the average page
size being about 50 Kb.  I've also worked with one
.Net based tool named Revelation which generated an
average page size over 100 Kb for database maintenance
applications.  Wouldn't you agree that generating
large HTML streams, particularly with Java, consumes
significant resources?  Wouldn't you agree that it
takes quite a bit of planning and discipline, or at
least an additional framework to use JSPs properly? 
Do you really think my CPU estimates are FUD, or would
the fact that your pages are 5 Kb in size be more of a
credit to your design?

If you were designing new Web applications instead of
generating HTML front-ends for legacy green-screen
programs would you recommend using browser function
keys?  Most of my work is with K-12 public school
districts where the Macintosh has a strong presence. 
The public sector is also getting into Linux based
workstations.  My default browser is Firefox.  I
sugggested using accellerator keys for keyboard
oriented applications, which you seem to agree with.

A while back, you questioned my understanding of
multi-threaded architecture & reentrant code, when I
alluded to a synchronization bottleneck in J2EE
application servers, which stung a bit, because I've
had a fair amount of experience in both writing
multi-threaded communication servers in Java as well
as components that run in them.  I also pointed out
some of the architectural advantages that J2EE has
over CGI.

For those who would prefer using a native ILE
interface, my suggestion would be to "split" the
interface, by having a light-weight HTTP "connector"
forward HTTP environment and HTML form variables to
native applications via data queues [or a comparable
communication channel],  and providing a means for
launching application server instances that which use
an API for generating HTML,  and providing a means of
load-balancing requests across application servers,
which provides an effective means of managing
resources, while supporting any number of users, and
any number of applications.

It seems to me that your PCS400 product might be doing
something similar, where a light-weight Servlet
provides a communication interface between an HTTP
server and legacy applications, loads the data stream
returned from legacy applications into Java beans, and
dispatches JSPs to transform the beans into HTML,
although I admit to not having experience with your
product.

Most Web architectures, particularly .Net goes to
great lengths to support distributed resources.  The
HTTP server may be deployed on one box, application
components on another, and database components on yet
another.  While simple applications may not need that
type of infrastructure, Microsoft uses distributed
resources as a means of supporting more users and more
types of applications, though it also introduces more
potential points of failure, and a lot more
complexity.

One thing that has been helpful to me has been to
streamline the interface between end-users and the
database.  Less complexity.  More reliability.  Better
performance.


Nathan Andelin



--- Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:

> Gz, Nathan, are you TRYING to get me to flame on? 
> <laughing>
> 
> While many of your points are valid, you skew them
> to the point that you
> are no longer providing good information.  Let's
> take a few.
> 
> "The problem with function keys..."
> 
> Function keys work outstandingly well in IE, and not
> so well in non-IE
> browsers.  Thus, the situation is simple: if you
> have control over your
> browser and standardize on IE, you can use function
> keys.  And while
> some folks may get upset if you don't support their
> pet browser, the
> truth is that well over 95% of business desktops are
> Windows, and thus
> have IE.  Because of this, you can reasonably
> standardize on function
> keys for inhouse apps.
> 
> For pure C2B web apps such as storefronts, you can
> use the W2C standards
> for keyboard accelerators (thing like Alt and Ctrl).
>  They work quite
> nicely, and can be quickly and easily substituted
> for function keys.
> With a simple JavaScript switch, you can flip
> between function keys and
> accelerator keys.
> 
> 
> "If you decide to front-end existing green-screen
> applications with an
> HTML interface,..."
> 
> I don't know where you get your figures, Nathan, but
> a typical well
> written HTML page is about 5K, a large one may get
> up to 10-15K.  Larger
> than a 5250 datastream, to be sure, but that's
> hardly an issue.  I can
> play with numbers too: on a gigabit Ethernet line it
> takes LESS THAN A
> MILLISECOND to send that data.  As to the tremendous
> amounts of CPU
> overhead ("some Java interfaces consume 30-50
> times"), in fairness you
> ought to post the numbers for a good Java interface
> to an RPG back end,
> where the actual CPU cycles consumed for the UI is a
> small fraction of
> the overall numbers.  This "any savings in ... may
> be gobbled up" is
> pure FUD.  I suggest you prove these numbers with a
> real world
> application.  Then give me a week to tear the thing
> apart and make it
> run correctly and all your FUD numbers will
> magically disappear.
> 
> This is not to say there is no overhead associated
> with Java.  What I'm
> saying is that a sufficiently thin JSP interface
> compares favorably to
> any UI out there, and can even run comparably with a
> green screen 5250
> interface.
> 
> 
> "Scripting languages like JSP..."
> 
> JSP, especially JSP Model II, is anything but a
> scripting language.
> Especially since the JSP is first converted to Java
> code and compiled
> into bytecode, which is in itself faster than a
> scripted language.  But
> then the bytecode is itself compiled into machine
> code by the JIT
> compiler, at which point the Java code is running at
> speeds equivalent
> to compiled RPG.  In fact, for certain operations
> compiled Java is just
> as fast as compiled RPG.
> 
> So please don't lump JSP in with the other
> architectural approaches.
> None of them are capable of taking advantage of the
> flexibility of the
> JSP design.  There are some things that Java doesn't
> do well, but UI
> isn't one of them.  JSP Model II may well be the
> most efficient user
> interface standard out there, especially when you
> factor in ease of use,
> a broad knowledge base and platform independence.
> 
> Joe
> 
> -- 
> This is the Web Enabling the AS400 / iSeries
> (WEB400) mailing list
> To post a message email: WEB400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/web400
> or email: WEB400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/web400.
> 
> 



                
__________________________________ 
Discover Yahoo! 
Stay in touch with email, IM, photo sharing and more. Check it out! 
http://discover.yahoo.com/stayintouch.html