|
ScreenSurfing vs. ScreenScraping
|
  
|
| ||||||||||||||||||||
| ||||||||||||||||||||
|
|
Click on any item to view... Contents
|
|
With Screensurfer, the concept of ScreenSurfing has been introduced. As the term "screen-scraping" has been used to describe the act of front-ending host applications with PC user interfaces, some clarification is in order. Screensurfing is not screen-scraping! A Little History It all began with a machine which has long since found itself in an eddy of the big computer river: the IBM 3270 PC. This oddball machine was a combination of a 3270 Terminal Device and a personal computer. As one of the first recipients of one of these beasts, the author of this guide was in some ways impressed with it compared to the typical PC, as it sported a monitor with far better resolution and color than other monitors of the time.
On the 3270PC, you could use a special hot-key to switch between one of four (count 'em, four) independent terminal sessions and one PC session, which was for executing personal productivity packages such as the revolutionary Lotus/123 or other exciting packages such as Microsoft MultiPlan or Word Version 1 (with a free mouse).
The PC session on the 3270 PC was a standard PC/DOS session with a few TSR (terminate-stay-resident) programs to support switching out the keyboard and display in order to display one of the terminal emulation sessions. You could program the PC session just like on any PC using Assembler, the Microsoft BASIC compiler or Turbo Pascal.
After only a few months on the market, a few customers started asking why they couldn't start to do stuff between the PC session and the host sessions, so that they could do fancy things like controlling the tiling of the screen or even copy information from one host session to another using a program instead of the operator's fingers.
An enterprising IBM Systems Engineer in Texas (he will remain anonymous) got the hardware specifications from the Raleigh lab and figured out an ASM program that gave a programmer the ability to access the 3270 sessions from the PC session. He quickly came-up with some useful functions for reading/writing screen data, sending keystrokes and so on.
This original program was distributed via mail to a number of bleeding edge IBM Systems Engineers including one in Vermont who, while anonymous is quite close to this story. He used it along with a bunch of assembler to fiddle and demonstrate a number of classy new capabilities to any and all that would listen.
Low becomes high The assembler code that formed the original capability to program the 3270PC was eventually given a high-level "wrapper" making it accessible to compiled BASIC (at which time the S.E. in Vermont threw away the wrapper he had already built). This new wrapper for these original, somewhat ad-hoc functions was given the dubious name of "EHLLAPI" which stands for Extended High-level Language Application Programming Interface. The rest is history. EHLLAPI became a standard for accessing and controlling 3270 sessions from PC programs, and it really has never gotten much better than it was originally. EHLLAPI is outside looking in The problem with EHLLAPI in terms of productivity, is that the developer is working "here" while the terminal emulation session is "over there". In other words, the developer is "outside looking in" at the emulation session. Any time there is an action performed by a user that requires interaction with the screen, the developer must coordinate the movement of data from the user's action to the screen. Following an enter or other AID key, each reaction by the host program must be anticipated and handled by the programmer in both normal-flow and exception routines. GUI programming--a long way from a terminal Terminals like the 3270 are controlled with streams of data and commands which format the information on the display and then control how the user's interaction with the terminal are returned to the host application program.
GUI programming, on the other hand, is an event-driven, complex environment which due to its complexity provided thousands of software tools companies with the opportunity to go broke competing with Microsoft and Powersoft. The commercial complexities aside, the programming model of GUI user interfaces creates a large gap between how the terminal works and how the PC screen works.
A maintenance headache When you combined the outside-in approach of EHLLAPI with the complexities of GUI programming, the act of front-ending host screens with client/server GUI programs involved a lot of code.
Now, once you have a lot of code, what is the worst thing that can happen? You need to maintain a lot of code. That is because host screens are not always static entities that are never changed. Quite often, the reason screenscraping was used was because the host application in question was a high-volume core business transaction that had to run on the mainframe because it was the only platform that could support the core transaction volumes.
Maintenance isn't necessarily a big problem if it is well controlled and synchronized. The problem with PC-side screen-scraping is that all those PC's need to be updated concurrently with updates to the host screens. If the number of PC's is high enough, this becomes a logistical nightmare which can actually reduce the opportunities for enhancements to those core business transactions, as scheduled maintenance can't occur as often as would be ideal.
ScreenSurfing is Different So much for the ills of screenscraping. Screensurfer brings a new approach to providing an enhancement capability to host screen sessions by moving the program inside the emulator. With Screensurfer, the enhancement code is inside looking out because the SurferScript HTML tags are compiled and executed by the same environment which is providing the host terminal emulation. Integrated Screen recognition The developer doesn't have to perform endless tests of each displayed screen like with EHLLAPI environments, since Screensurfer has a built-in screen recognition rule base. As each screen is displayed, Screensurfer analyses it against the rule base and automatically executes the corresponding SurferScript. HTML affinity to terminal datastreams HTML as a programming medium is easier to apply to the terminal session model. Both are streaming environments, where commands are streamed-out to a device and replies are returned in a block mode.
This makes it easier for a developer to quickly create user interfaces that, while perhaps lacking the glitz and fancy features of what can be accomplished with a modern Win32 application, are still a huge improvement over the cryptic host screens they are replacing.
Incremental Enhancement Unlike screen-to-GUI environments, Screensurfer enables the project team to pick-and-choose which screens and which portions of those screens need updating. Little-used screens or screens that are "mostly" O.K. need minimal work to bring-them-up to a usable level. Contrast this to a screen-scraping environment, where even marginal screens or fairly decently designed screens still need to be completely re-coded! No more maintenance nightmare Screensurfer, with its inside looking out model, and the use of streaming HTML requires relatively little programming to provide enhanced PC-based graphical access to host sessions.
Combine the small code base with the server-side orientation of Screensurfer, and coordinating changes to host screens becomes a highly simplified task. With only one or a handfull of Screensurfer servers to update, synchronizing is simplified, and changes can be applied in a direct fashion.
|
| ||||||||||||||||
| ||||||||||||||||||||
    | ||||||||||||||||||||
