RE: webfacing and competing products

Trevor,

> 
> I live in the US - lexicon invention is part of the deal!!
> 

Not only do you guys mess with definitions but also pronunciation
and spelling. Lexical invention could be interpreted in this
context as propaganda?

> While your points are valid, they do not seem to apply to the 
> majority of the server-based tools on the market. You may be 
> taking a new approach, but the majority of currently 
> available server-based refacing tools simply intrude on the 
> code or the data stream, take the same green screen data that 
> was originally being sent in a 5250 format, and redisplay it 
> in an HTML format. The original application still operates in 
> the manner in which it was designed - it thinks it is having 
> a conversation with a terminal.

I am not referring to how it is currently done by others, rather
how it could/should be done while protecting the investment and
skills embodied in most application systems on an iSeries. Intrusion
introduces duality of being for any application, pre and post
conversion. Dilemmas and bear traps abound here in an expensive,
complex neo tech landscape. Most times I see over engineered
solutions being used as leverage for training and service revenue
intrinsically bound to user pays client based licensing regimes.
You have assertions and assumptions here that have been introduced
by vendor attempts focused on conversions not transitions.
Existing applications do indeed use 5250 protocol but are not
limited by it. Even today's display files can do lots more than
just  character based interaction, vendors just do not support
full scope available. 

> Using a simplified OSI model for example (where there are a 
> presentation layer, application layer and database layer for 
> the development model) most refacing tools simply integrate 
> to the presentation layer. Without reengineering the original 
> application to remove the presentation layer - for example, 
> let's re-write all our interactive RPG withOUT a display file 
> - we are still screen scraping the original display file 
> screen conversation.

The concepts underlying the three layers that are at the heart
of Open Systems Interconnect (OSI), the Transport Layer, the
Session  Layer, and the Presentation Layer do not tally with
your assertion? The MVC paradigm is a way of breaking an
application, or even  just a piece of an application's interface,
into three parts: the model, the view, and the controller.
MVC was originally developed  to map the traditional input,
processing, output roles into the GUI realm:

Input --> Processing --> Output
Controller --> Model --> View

Your lexicon again! you are misinterpreting differing concepts.
Limiting the conversation to 5250 only? this is not necessarily
the case. Major motivation to rewrite is to avoid CPW limitations,
this can be done without touching your applications or sacrificing
any function.

> I assert that the diversion of the data stream at an earlier 
> point than a telnet connection is still screen scraping.

Telnet? who mentioned Telnet? Host access is not restricted to
an ageing, static and rigid RFC manifesto of interaction these
days.  By your definition SNA sessions over IP are screen-scraping.
You miss a fundamental point I think, instead of automatically and
transparently dealing with a protocol, inspection and intrusion are
what characterize screen-scrapers. The approach attaches  significance
to application data that has no definition within the protocol or the
application. To compensate for the lack of meta  data available,
screen-scrapers invent their own product specific application lexicon.
A guess at application meaning by one product  is as good as another
I suppose but hardly acceptable. Manual programmer intervention is
generally required to ameliorate  misinterpretation of application
data with screen-scrapers which consequentially introduces a
nightmare test scenario of immense  complexity coupled with interface
fragility. In contrast, application meta data is readily available on
host servers providing  current, formal and accurate definitions with
no redundancy or deployment issues.

> If we continue to think that our legacy applications are 
> pigs, then we will continue to need lipstick, plastic surgery 
> and beyond. When our legacy applications are rewritten so the 
> presentation layer is separate from the application layer and 
> the database layer, then a server-based presentation layer 
> will be a powerful tool. Until that industry wide 
> reengineering takes place, the lexicon of the 80s will remain 
> in the marketing vernacular - pig, lipstick, screen scraping, 
> etc. and screen scraping will survive.

I have never consider iSeries applications to be of swine, wrote
a few myself-). What do iSeries companies do while awaiting your
"industry wide reengineering" to happen? Logical transitions not
conversions are required;

- Web access to thousands of existing "green-screen" applications
- No double-maintenance
- Existing displays to include graphics, text, and links
- Utilize existing tools and skills to develop new Web applications 
- Clients not restricted to a particular emulator or operating system 
- Complex Web applications that need to save state through a series of
  steps easily done

Tools are needed that do not cost the earth, are load-&-go and require
no intervention dealing with existing applications.

> 
> Bob, you were the one who encouraged me to write modular code 
> in 1983 on S/38. It took me some time to understand, but all 
> my applications were built modular from that moment. One 
> exception  (which rears its head in this
> moment) has always been a display file - an INTEGRAL part of 
> iSeries coding techniques. I would love to see a hand-written 
> iSeries application that utilizes display file server 
> programs, but alas, they are simply toys for some of us 
> uber-techies - mostly pigs with wings. Application 
> development on the iSeries does not have the modular 
> structure to allow us to truly separate the presentation 
> layer with a server. Without radical application 
> reengineering, the concept of a set of characters in row 2, 
> column 3 (3 or 4
> long) is inherent to our development environment, platform 
> and even our psyche.
> 
> Until that day, we have a data stream to deal with. Screen 
> scraping pervades.
> 
> I say, give that pig some wings - and at least let it ~look~ 
> like it is flying!

Always been a modular sort of guy, makes sense and is achievable.
Display files "externally described" are modular and facilitate
reuse  by variety of application units. Do not get your point?
Again, assumptions about current technology options, what you
describe is possible, just need to revisit some older technology
with new eyes and exploit proven web standards. Who knows someone
may just do something specific for the iSeries that achieves this...

Illusions are not sustainable, pork usually ends up roasted...


Bob


> 
> Trevor
> 
> 
> ----- Original Message ----- 
> From: "Bob Moore"
> Subject: RE: webfacing and competing products
> 
> 
> > Trevor,
> >
> > Screen-scrapers
> >
> > To integrate with host applications from non-standard 
> client systems, 
> > developers commonly use text - filtering systems that process the 
> > screen-by-screen results of terminal interaction. These systems are
> > generally called screen-scrapers because they have to 
> extract meaningful
> > data from a screen's worth of
> > undifferentiated information an inefficient method at best.
> > Screen-scraper interfaces are some of the least
> > robust interfaces possible because of the many assumptions 
> that have to
> > be made when determining what
> > data from each screen is important. Very little can be done to catch
> > errors or provide for unusual
> > situations with a screen-scraper because the interface 
> definition is so
> > arbitrary. If the third through fifth
> > characters of the second line of the fourth screen are used 
> to indicate
> > the three-digit product code of a
> > widget, for instance, the entire interface could be thrown 
> off by having
> > four-digit product codes come into
> > use after the interface is developed. Processing 
> application data post
> > client receipt on-the-glass is too
> > little too late. The light weight screen-scraper approach 
> does not allow
> > server based transformation where
> > application interfaces and system data are current, 
> available and known.
> >
> > Familiar? Pigs cannot as far as I know fly, new lipstick look or no!
> >
> > Inventing one's own lexicon does not alter reality!
> >
> > Bob Moore
> 
> _______________________________________________
> This is the Midrange Systems Technical Discussion 
> (MIDRANGE-L) mailing list To post a message email: 
> MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change 
> list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
>