RE: Re: Web-Facing and 5250 removal -- WEB400

Great post.  I would simply add that Jwalk has the ability to combine
multiple panels of the RPG app into a single panel on the web UI.  Can
be nice for ERP or other apps that are a little cumbersome in the
presentation/data entry department.

John A. Jones
Americas Security Officer
Jones Lang LaSalle, Inc.
V: +1-630-455-2787 F: +1-312-601-1782
John.Jones@xxxxxxxxxxxxxxxxxxxxxxx

-----Original Message-----
From: Buck Calabro [mailto:buck.calabro@xxxxxxxxxxxx] 
Sent: Tuesday, May 11, 2004 4:01 PM
To: web400@xxxxxxxxxxxx
Subject: [WEB400] Re: Web-Facing and 5250 removal

> Web-Facing is simply a process of building/converting a Graphical User

> Interface (GUI) on top of a new or existing business application.

The term 'web-facing' and its ilk has been adopted by who knows how many
people as a generic term meaning 'uses a web UI.'  This is all too often
confused with the IBM product called WebFacing which is part of WDSCi.
It reads the DDS source and creates Java servlets and jsp pages for
deployment on WAS or Tomcat.

JWalk is a screen scraper, which is a process of reading the 5250 data
stream and interpreting the look & feel based on what it sees.
Neither WebFacing nor JWalk change the underlying RPG programs which
make up the application, but at least WebFacing uses industry standard
Java to create its UI.

Why is this important?  With IBM's WebFacing, you can convert your
application once, and re-use the converted components (JSP, servlets,
classes) in your own design.  You've already deployed WAS and Apache and
have literally all the infrastructure you need to add brand new servlets
to the application.

With a screen scraper, you get none of that and you are 'locked in' to
their solution.  You can't incrementally add to your existing deployed
web code base because you haven't got any.  When you want to make a
change, you must go back to the DDS and make your changes there.
Modern screen scrapers all have some way to customise the look of a
screen, which often means that once you've changed the DDS you have to
revisit the 'customiser' and make the GUI panel look good again.

What to choose?  It all boils down to the reason you are contemplating a
web UI.  If you don't want to pay for a leased line and want the new
office in Guatemala to access your app via a browser, you have a
different set of criteria and problems than if you are trying to use
Java because it meshes with the corporate goal of interoperability with
some other vendor's application, which in turn is a different problem
than being an ISV who needs the cachet of a web based product in order
to make sales.

In general, the screen scrapers are very easy to use and deploy, but
they have quirks in their recognition engines which are 'customised'
so the panels look good.  There's often a double maintenance penalty
(DDS and customiser) but since everybody knows DDS already it isn't seen
as that big a deal.  Scrapers often don't need source code, and handle
IBM panels like WRKSPLF.

The re-facing crowd often require source, and often make changes to it.
Almost invariably, those changes can be reused to enhance the
application in the future.  Because they use source, they don't have to
make a guess about what the panel should look like, and thus have fewer
glitches in the recognition engine.

If your company wants to go to the web in a real way (learn Java, learn
web infrastructure, good change management) then choose one of the
re-facing products (PSC or WebFacing come to mind).  If you aren't going
to invest the effort in becoming web experts, then choose a scraper
(JWalk, Newlook and I think aXes fall into this category.)
  --buck
This email is for the use of the intended recipient(s) only.  If you have 
received this email in error, please notify the sender immediately and then 
delete it.  If you are not the intended recipient, you must not keep, use, 
disclose, copy or distribute this email without the author's prior permission.  
We have taken precautions to minimize the risk of transmitting software 
viruses, but we advise you to carry out your own virus checks on any attachment 
to this message.  We cannot accept liability for any loss or damage caused by 
software viruses.  The information contained in this communication may be 
confidential and may be subject to the attorney-client privilege. If you are 
the intended recipient and you do not wish to receive similar electronic 
messages from us in future then please respond to the sender to this effect.