RE: webfacing and competing products

Trevor,

Glad you think you get it.

What I have written highlights that any intrusive screen-scraper reliant
on invented and redundant meta data is a flawed approach. Creates more
problems than it solves. Have also stated that host server solutions
optionally can access current, formal and accurate application meta data
definitions with no redundancy or deployment issues. Draw your own
conclusions! My opinion.

One of my "how it should be done" theories, from the distant past, is
implemented in software still available today which you well know . You
espouse this theory "Living in this world every day". Last years model
does not cut it today though, you live and learn then move on.

Funnier, maybe propagandist is ex-pat.

Bob


> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx 
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of trevor perry
> Sent: Monday, 16 June 2003 7:20 AM
> To: Midrange Systems Technical Discussion
> Subject: Re: webfacing and competing products
> 
> 
> Bob,
> 
> I had to read this a couple of times, because I was confused. 
> Now I get it.
> 
> You and I seem to agree in principle that the way most 
> CURRENT refacing tools work is to "screen scrape". This was 
> my original assertion, and your replies seem to agree.
> 
> So, the next step is, what else are we discussing? That was 
> the confusing part. I delved, and found that you are talking 
> about how you think it ~should~ be done. Since the discussion 
> was originally about ~current~ refacing approaches, I will 
> stick to that and let you continue with your "how it should 
> be done" theories.
> 
> Funny thing is, the propaganda machine is now working out of 
> Australia..
> 
> Trevor
> 
> ----- Original Message ----- 
> From: "Arterial: Bob Moore"
> Subject: 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
> 
> _______________________________________________
> 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.
> 
>