WebFacing project status...

>It has been a while since you've posted a
>general update on your experience with Webfacing.
>Last we heard, it was taking 60-90 seconds
>for the screens to refresh.  You were hoping
>to test it on a faster processor.

I have an 820 in house with some L2 cache and the horses to drive WAS.  With
everything straight out of the box I am seeing a first touch of about 6
seconds, and a screen to screen time about 2 seconds.  I am exploring ways
to optimise this.  The JspBatchCompiler helps some, but it'll only do a few
hundred jsps before terminating.  Of course, with the new box, we got WAS
4.0 and so I had to re-learn about WAS.  WAS 3.5 is very different from 4.0,
because 4.0 is the full J2EE version, whereas 3.5 was IBM's best guess at
what J2EE was going to be.

It's been a rather amazing experience, all things considered.  In my case,
WebSphere is running classes and jsps created by a code generator
(WebFacing) over DDS and RPG created by a code generator (Synon/Cool:2E).

Debugging one of these applications is quite difficult from its green screen
companion.  Because the RPG is OPM, I need to use STRISDB, but because there
is no physical display, viewing the results depends on the WebFacing server
and WAS.  If there's a hiccough there, then one needs to delve into the WAS
debugging magic.

Deployment has been an issue as well.  I can't deploy the full application;
I get an error in the Admin Console saying it can't find an XML file.  IBM
are working on this one.  I got around that by creating a small war file of
only the initial screen and deploying that.  Then I export the individual
objects from the WebFacing tool into the file system created by the Admin
console for the small deployment.  That has been working for me.

Outstanding items:
1) Optimise generated classes and compile the generated jsps
2) Learn WAS debugging
3) Learn how to package the lot so I can do the
   equivalent of a SAV here and a RST on my
   customer machines.

  --buck