Re: What do I use?

Depends I suppose. For a typical query web page, we may have a half dozen graphic images on it, which web browsers on the client will retrieve, load, and place on a page. Then depending upon the complexity of the page, it can easily take a second or three to assemble, compose, and display. Just for plain old HTML. I suppose that can be optimized, but when you have a relatively complex screen, especially one that requires precise positioning on screen, I don't think sub-second response is something you are going to see a lot of.

Note also that most application servers use a psuedo-conversational method, much like CICS. The actual program (servlet) that is handling the page will usually be ran again for each submission. This involves time to gather the submitted information and despatch the correct supporting application. I understand that some newer technologies are starting to provide conversational processing.

Of course, you *do* have the same overhead in CICS, and the very fastest web pages I have ever seen (running complex applications) have been driven by CICS.

-Paul


On Apr 17, 2007, at 1:07 PM, Ron Power wrote:

If I might interject here a moment and clarify my thoughts... but the JSP
code runs on the server doesn't it? Either I'm misinterpreting how JSP
runs, but the client horsepower has no effect at all on JSP, because from
my understanding the JSP runs on the server and all that's served up to
the client is a basic html page. As for loading and interpreting
Javascript I don't think there's much overhead involved in that at all
from my experience. I've developed a few applications here that run
purely using java and jsp, with javascript for various items such as
hiding/unhiding div statements when a button is clicked, but from my
school of thought, all validation should be done on the server. Then it
comes down to how well you organize your dao's, servlets, and processing
to get subsecond response times. My first application was somewhat
cumbersome, but it was my first and it works fairly well. I learned from
that app, that I needed to create object models to hold my values, dao's
to access my data backened, and servlets to control the interaction. So
in reality, an application that runs in subsecond time on a PIV should run
the same time on a PIII or less. So long as it meets the requirements for
the web browser it is running.

Ron Power
Programmer
Information Services
City Of St. John's, NL
P.O. Box 908
St. John's, NL
A1C 5M2
709-576-8132
rpower@xxxxxxxxxx
http://www.stjohns.ca/
______________________________________________________________________ _____
Success is going from failure to failure without a loss of enthusiasm. -
Sir Winston Churchill




"Paul Raulerson" <paul@xxxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
2007/04/17 02:27 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
Re: What do I use?






I'm not trying to be either difficult or confusing. Rather, I asked you
for a sample of a Web Application that has subsecond response.
Instead of providing one, you pointed me to a trivial example which is not
a real world or working example. I have yet to see a web application,
despite your claims, that can support the sub-second response that
standard applications or green screen applications support on a regular
basis. I would be very much tickled to see one, and yes, at that point, I
would admit I was mistaken.
But I would simply have to see one first.
JSP, unless you mean something totally different from what I think you
mean, means Java Server Pages - which is essentially a compiled and
running Java program similar to a servlet that displays a web page.
Usually using JavaScript (a browser based scripting language not at all
related to Java the programming language) to present a more interactive
appearance to the user.
I have seen fast JSP applications, but the repsonse speed from these
applications is subject to, and limited by, the client and the network. In
other words, the browser has to render the page and load/interept the
Javascript. That takes a good deal of time to do anything significant.
As for the difference between this and application servers that provide
only display; it should be obvious. The processing horsepower and the
network are all centralized *and controllable*, which means that the
processing happens quickly. The only thing passing between the systems is
the display instructions, which while similar to, are far more optimized
than a browser. The remote display is still rendered by a client, but the
client does not have to content to a large number of different things,
such as HTML, StyleSheets, loading and displaying indicvidual graphics,
javascript, ASP, and the legion of other application protocols. It only
deals with display, and the protocol it understands is designed to do
nothing BUT display. Just like X11 by the way.
As for cost, you seem to have not investgated the situation throughly. Do
you know how much WebSphere actually costs to deploy, including the
hardware to do so, database backends and so forth? Hint - it is NOT cheap.

You are pointing at the cost of CALs, so I will assume you are familiar
with Windows. First off, the only *additional* cost is a Terminal Server
CAL, which *replaces* the cost of a standalone Windows workstation
license. Typcially, TS CALS run about $50 (street price.) That is quite a
bit cheaper than buying and supporting Windows on a standalone
workstation.
Better yet, take Windows out of the picture and you have a much better
economy of scale. Typically, Windows, with CALS to a server and Office
runs between $1000 and $1400 per desktop/user. (That can vary a little,
but it is a pretty good average, and applies equally well to a system
deploying WebSphere applications or a system deploying full capability
applications over a terminal server interface, or a configuration of a
bunch of standalone machines.
Linux gets that cost down to more like $140 per desktop, taking SuSE
bundled pricing for instance. Inlcuding an office suite and the capabilty
to run remotely or locally, with full licensing. WebSphere deployment can
and does add significantly to that cost, as you need WebSphere, databases
and the cost of Rational included in there.
Obviously, should there be web applications (vice applications deployed by
the web to something like an ICA client) that can provide a smooth
seamless and *fast* user experience, then I need to rethink that logic.
Basically, pretend I am from Missouri instead of Texas - show me and I'll
believe.

-Paul

From: Paul Raulerson

What's so hard? Write a simple servlet that updates a counter and
outputs
it to a JSP. Have the JSP show the counter and a button. When the
button
is hit, go back to the servlet.

I rather thought you were talking about a real application, the kinds
that have to hit a backend datasource, perform significant edits on
the data, and redisplay screens fairly quickly. Hopefully doing
things like telling the user what went wrong. You can get subsecond
response out of a Palm M100 with the kind of application you describe.

You are either trying to be difficult, or else we have a serious
communication breakdown. You're complaining about the browser as a UI as
opposed to the Citrix approach, and I'm trying to tell you that the UI
overhead of JSP is almost zero.

Since JSP is only the UI, the back end is pretty much a non-issue, isn't
it?
I mean, if the back end processing takes a long time, then the UI won't be
responsive whether it's Citrix or JSP. If the back end doesn't take a long
time, then it's not an issue.

Not that it matters, though. Since I use RPG as my back end and the JSP is
purely used for data conversion and presentation (as it should be), the
overhead due to the application is indeed negligible. The applications I'm
talking about are web-enabled ERP applications, about the most complex
thing
you have ever seen.

Certainly more complex from a business perspective than, say, a word
processor.

I have not seen a real heavy duty transaction processing application
on the web with the kinds of response time you indicate you get -
especially on applications distributed over the WAN to multiple
remote geographic locations.

I'm telling you flat out that we get sub-second or near-subsecond response
time on a WAN for traditional ERP applications. That's about as heavy
transaction processing as it gets. You don't believe me? Then we don't
have much more to discuss, Paul. My clients believe me, that's all I care
about.

And now you're bringing up a WAN and multiple remote geographics, which
means lots and lots of CALs for Citrix. Or else NoMachine, which costs
thousands of dollars, even on a Linux box.

The browser is zero cost.

I do this with my PSC product. I web-enable subfiles and even over
a WAN we get sub-second response time.

That I would really like to see - especially with some rather complex
screens that require updating based upon processing of entered data.

And will you then get on the mailing list and explain to everyone that
you're completely wrong? Of course, my clients might not want to talk to
you; they LIKE the idea of their competition using expensive, cumbersome
options like Citrix.

Joe


--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.







This email communication and accompanying documents is intended only for the individual or entity to which it is addressed and may contain information that is confidential, privileged or exempt from disclosure under applicable law. Any use of this information by individuals or entities other than the intended recipient is strictly prohibited. If you have received this in error, please notify the sender and delete all the copies (electronic or otherwise) immediately.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.