Web-Driven IBM Terminal Emulation

One of the many dilemmas that you face when you publish mainframe- orAS/400-based information on Internet or intranet Web pages is how to handle theconstruction and presentation of the data. Some (maybe most) of the data youhave stored in your databases may not be--and I'll try to be delicatehere--suitable for publication as is. Perhaps the information you want topublish needs to be calculated, or you need to use data from the fields in onedatabase to access information stored in other databases. You could, of course,implement elaborate SQL routines or stored procedures to automatically generateyour Web-based information according to your business rules. Unfortunately,implementing these routines or procedures takes time and effort.

Now let's step back from the problem and consider this scenario: Chancesare pretty good that you have existing business applications that handle yourdata, apply your business rules, and present the data just the way you want onan IBM 3270 or 5250 terminal. Therefore, if you could simply let your Webbrowser clients access some of your data via existing business applications,you'd be all set, right? So why reinvent the wheel? Just let the Web browserfire up a 3270 or 5250 emulation session and drop the user into an applicationprogram.

But how, exactly, do you turn your Web browser into a terminal emulator?After all, Web browsers don't know how to do terminal emulation--it's just notup their alley. Fortunately, Web browsers know how to trigger othernonintegrated procedures such as Common Gateway Interface (CGI) routines,external helper applications, plug-in programs, Java applets, ActiveXcomponents, and HTTP interceptors. These procedures can be sponsored by the IBMsystem hosting the terminal session or by an external gateway device thatcontrols the Web interface and feeds the terminal sessions to the IBM host asnative SNA terminal traffic. In short, you have a variety of options to help youovercome the limitations of Web browsers.

Paths to Green Screen Pastures
Although all terminal emulation methods accomplish the same goal, they arenot equal solutions. Let's take a closer look at the methods so that you can seethe pros and cons of each.

CGI routines. CGI routines are software modules that a Webbrowser invokes and a host system (i.e., the IBM mainframe or AS/400) or agateway system executes. For terminal emulation, you can use CGI to convert IBMscreen information to HTML format so the terminal emulation session is embeddedin the Web page. Screen 1 shows a CGI-based 5250 terminal emulation sessionhosted by a gateway device.

The biggest benefit of the CGI method is its platform independence--thesame CGI interface can provide terminal emulation for PCs, Macs, UNIX platforms,and virtually any other platform that can run a graphical Web browser. Anotherbenefit of this approach is the amount of control you have over the terminalemulation session. Because the CGI routine runs on your host or your gateway,you can control all the characteristics of the session (device type, screenappearance, timeout values, etc.). The biggest disadvantage of the CGI method isthat CGI routines that implement terminal emulation are relatively complex--theychew up CPU resources wherever they run (i.e., on an IBM host or in a gateway).

Helper applications. If you already use TN3270 or TN5250emulation, you can have your client Web browsers launch the client-side Telnetsoftware on demand. You can accomplish this launch two different ways. First youcan embed the telnet: HTML tag in a Web page to launch the helper TN3270or TN5250 program. Of course, you must configure each client browser to launchthe appropriate executable file (with any associated command-line parameters)when the user clicks on the telnet: tag. Alternatively, you can set up afile download to the client with the MIME file type that tells the browser youwant to launch the TN5250 or TN3270 program as a helper application. In thiscase, you must configure each client browser to recognize the relationshipbetween the file type and the TN5250 or TN3270 software. Once you completeeither setup, this solution works well and it moves the burden of terminalemulation from the IBM host or gateway to the client system. Screen 2 shows anexternal TN5250 helper launched by a Web page.

You can also achieve a low level of session control using either helperapplication approach. For example, the file you download to activate the TN5250or TN3270 session can be the configuration file for the emulator; therefore, youcan control (to a certain extent) how the emulator looks and operates on theclient. If, on the other hand, you activate TN5250 or TN3270 via the telnet:tag, you can typically include the configuration file as a command-lineparameter in the execution sequence.

The major problem with both helper application approaches is that they arevery complicated to implement. You must load TN5250 or TN3270 software on eachclient. Furthermore, you need the same brand and version of software resident oneach of your client systems; otherwise, you'll have a difficult time configuringthe client browsers to launch the correct program with the appropriateparameters (each brand or version can potentially accept different parameters).If you have different brands or versions of TN5250 or TN3270 in place, youcannot download a configuration file from your host system to launch theemulation because different brands and versions of software use different typesof configuration files. A final problem with this approach is that the TN5250 orTN3270 program runs as a separate application; therefore, the user must end theprogram when the session is over--you cannot automatically close the terminalemulation session window when the user moves off the Web page.

Plugins. A relatively new method for browser-based IBMterminal access is to use an IBM terminal emulation plugin. A plugin is aspecial kind of helper application that a Web browser can automatically launchand run inside the current Web page. Traditionally, vendors have used plugins toprovide support for audio, video, virtual reality modeling, and other specialpurpose functions. Implementing terminal emulation as a plugin is a new twist.As far as I know, only one company--White Pine--has a terminal emulation pluginscheduled to go on the market. Screen 3 shows a plugin sponsoring a terminalemulation session.

A terminal emulation plugin might sound like the helper application justdescribed, but some key differences exist. First, when a Web page loads, it canautomatically activate the plugin; users don't need to click a file reference tostart the session. Second, the session is tied to the Web page; if the userbacks out of the page, the session link is automatically broken (after someperiod of time). Third, plugins usually cooperate with server-side scripts, soyou can automate the client logon process and drop users directly into theapplication you want them to access. Finally, you can have a pluginautomatically download if it is not installed in the client's system. In otherwords, you get all the benefits of a helper application, but without theconfiguration and administration hassles.

Of course plugins aren't perfect. The biggest limitation is that to use aterminal emulation plugin, users must run the Netscape Navigator 3.0 browser ora browser that supports Navigator plugins (such as Microsoft's InternetExplorer--IE--3.0). Another significant limitation is that plugins are notavailable for all types of clients and client operating systems.

Java applets. What discussion of Web browsing and IBM hostaccess would be complete without the specter of Java? Does Java have a rolehere? The answer is yes because several companies--ADVANCED BusinessLink, FarabiTechnology, and OpenConnect in particular--have developed Java-based IBMterminal emulators. On demand, a Java applet downloads to the Web browser andexecutes as a separate Java applet. Screen 4 shows a Java-based terminalemulation session. Unlike a plugin, the Java applet does not need to bepreloaded or preconfigured; it downloads each time it's needed. This feature, ofcourse, is good and bad news. The good news is no special configurationconsiderations exist on the browser side (other than the requirement that thebrowser must support Java). The bad news is the applet must download whenever itdrops out of the cache area maintained by the client browser.

Java-based terminal emulation brings a powerful advantage to the table:Like CGI routines, Java applets are platform independent. The same Java terminalemulation applet can run on a PC, Mac, and UNIX browser. Also like CGI routines,you can tailor the Java applet to control the session characteristics. Butunlike CGI routines, Java applets run on the client side and consume client-sideresources (instead of IBM host-side resources). Java-based terminal emulationapplets are an emerging area in the IBM market (i.e., no standards exist;therefore, no two Java terminal applets will work alike). Some Java appletsprovide dynamic terminal screen-to-HTML conversion, which produces a graphicallook-and-feel similar to what the CGI routines deliver. Other Java-basedterminal emulation applets implement character-mode emulation, which provides alook-and-feel similar to standard terminal emulation. Shop around and see whatyou can find.

As in the case of plugins, the biggest limitation of a Java-based terminalapplet is that users must run a browser that supports Java. Another interestingcharacteristic of the current breed of Java-based IBM terminal emulation appletsis that they rely on a gateway device that sits between the Internet and the IBMhost. The gateway converts the Java terminal emulation data stream into astandard IBM terminal emulation stream and feeds it into the IBM host as nativeSNA terminal traffic or as TN5250/
TN3270 terminal traffic.

ActiveX components. And what of Microsoft's strategicchallenge to Java, ActiveX? Can an ActiveX IBM terminal emulation componentachieve the same results as a Java terminal emulation applet or a plugin? Youbet. Unfortunately, vendor support for ActiveX lags behind vendor support forJava. Wall Data leads the industry in ActiveX IBM terminal emulation.

Implementing ActiveX parallels implementing plugins. You can automaticallydownload the necessary ActiveX component to your client and run it in thecontext of the current Web page. The big limitations of ActiveX components arethat only the Microsoft Web browser (IE) fully supports ActiveX and that ActiveXworks on only Intel clients.

HTTP interceptors. An HTTP interceptor routine (a.k.a. agateway program) receives the traffic sent to either the standard TCP/IP portfor HTTP traffic (port 80) or a predefined, custom port. When the interceptorreceives data from a port, it assumes the request is for terminal emulation andprovides all the necessary terminal screen-to-HTML conversion.

Think of an interceptor as a very specialized kind of Web server: Aninterceptor receives all traffic addressed to the port it monitors, but insteadof serving up standard HTML pages, it serves up terminal emulation. An HTTPinterceptor routine has the same advantages and disadvantages as a CGI routine.

So Many Choices, So Little Time
You can take many different paths to reach the destination of browser-basedIBM terminal emulation. And, of course, there's no single "right" pathto take because you must consider so many factors. For example, if you want toprovide universal access from all types of client systems, then you're limitedto the CGI, Java, and HTTP interceptor approaches. If your goal is to incur allthe processing overhead on your IBM host or on a gateway, then you need to lookat the CGI and HTTP interceptor options. Conversely, if you want to off-load allthe processing to your clients, you can choose among helper applications, Javaapplets, plugins, and ActiveX components. As you can see, you must consider manydetails. But the good news is you get many options to choose from.

Helper applications. If you already use TN3270 or TN5250emulation, you can have your client Web browsers launch the client-side Telnetsoftware on demand. You can accomplish this launch two different ways. First youcan embed the telnet: HTML tag in a Web page to launch the helper TN3270or TN5250 program. Of course, you must configure each client browser to launchthe appropriate executable file (with any associated command-line parameters)when the user clicks on the telnet: tag. Alternatively, you can set up afile download to the client with the MIME file type that tells the browser youwant to launch the TN5250 or TN3270 program as a helper application. In thiscase, you must configure each client browser to recognize the relationshipbetween the file type and the TN5250 or TN3270 software. Once you completeeither setup, this solution works well and it moves the burden of terminalemulation from the IBM host or gateway to the client system. Screen 2 shows anexternal TN5250 helper launched by a Web page.

You can also achieve a low level of session control using either helperapplication approach. For example, the file you download to activate the TN5250or TN3270 session can be the configuration file for the emulator; therefore, youcan control (to a certain extent) how the emulator looks and operates on theclient. If, on the other hand, you activate TN5250 or TN3270 via the telnet:tag, you can typically include the configuration file as a command-lineparameter in the execution sequence.

The major problem with both helper application approaches is that they arevery complicated to implement. You must load TN5250 or TN3270 software on eachclient. Furthermore, you need the same brand and version of software resident oneach of your client systems; otherwise, you'll have a difficult time configuringthe client browsers to launch the correct program with the appropriateparameters (each brand or version can potentially accept different parameters).If you have different brands or versions of TN5250 or TN3270 in place, youcannot download a configuration file from your host system to launch theemulation because different brands and versions of software use different typesof configuration files. A final problem with this approach is that the TN5250 orTN3270 program runs as a separate application; therefore, the user must end theprogram when the session is over--you cannot automatically close the terminalemulation session window when the user moves off the Web page.

Plugins. A relatively new method for browser-based IBMterminal access is to use an IBM terminal emulation plugin. A plugin is aspecial kind of helper application that a Web browser can automatically launchand run inside the current Web page. Traditionally, vendors have used plugins toprovide support for audio, video, virtual reality modeling, and other specialpurpose functions. Implementing terminal emulation as a plugin is a new twist.As far as I know, only one company--White Pine--has a terminal emulation pluginscheduled to go on the market. Screen 3 shows a plugin sponsoring a terminalemulation session.

A terminal emulation plugin might sound like the helper application justdescribed, but some key differences exist. First, when a Web page loads, it canautomatically activate the plugin; users don't need to click a file reference tostart the session. Second, the session is tied to the Web page; if the userbacks out of the page, the session link is automatically broken (after someperiod of time). Third, plugins usually cooperate with server-side scripts, soyou can automate the client logon process and drop users directly into theapplication you want them to access. Finally, you can have a pluginautomatically download if it is not installed in the client's system. In otherwords, you get all the benefits of a helper application, but without theconfiguration and administration hassles.

Of course plugins aren't perfect. The biggest limitation is that to use aterminal emulation plugin, users must run the Netscape Navigator 3.0 browser ora browser that supports Navigator plugins (such as Microsoft's InternetExplorer--IE--3.0). Another significant limitation is that plugins are notavailable for all types of clients and client operating systems.

Java applets. What discussion of Web browsing and IBM hostaccess would be complete without the specter of Java? Does Java have a rolehere? The answer is yes because several companies--ADVANCED BusinessLink, FarabiTechnology, and OpenConnect in particular--have developed Java-based IBMterminal emulators. On demand, a Java applet downloads to the Web browser andexecutes as a separate Java applet. Screen 4 shows a Java-based terminalemulation session. Unlike a plugin, the Java applet does not need to bepreloaded or preconfigured; it downloads each time it's needed. This feature, ofcourse, is good and bad news. The good news is no special configurationconsiderations exist on the browser side (other than the requirement that thebrowser must support Java). The bad news is the applet must download whenever itdrops out of the cache area maintained by the client browser.

Java-based terminal emulation brings a powerful advantage to the table:Like CGI routines, Java applets are platform independent. The same Java terminalemulation applet can run on a PC, Mac, and UNIX browser. Also like CGI routines,you can tailor the Java applet to control the session characteristics. Butunlike CGI routines, Java applets run on the client side and consume client-sideresources (instead of IBM host-side resources). Java-based terminal emulationapplets are an emerging area in the IBM market (i.e., no standards exist;therefore, no two Java terminal applets will work alike). Some Java appletsprovide dynamic terminal screen-to-HTML conversion, which produces a graphicallook-and-feel similar to what the CGI routines deliver. Other Java-basedterminal emulation applets implement character-mode emulation, which provides alook-and-feel similar to standard terminal emulation. Shop around and see whatyou can find.

As in the case of plugins, the biggest limitation of a Java-based terminalapplet is that users must run a browser that supports Java. Another interestingcharacteristic of the current breed of Java-based IBM terminal emulation appletsis that they rely on a gateway device that sits between the Internet and the IBMhost. The gateway converts the Java terminal emulation data stream into astandard IBM terminal emulation stream and feeds it into the IBM host as nativeSNA terminal traffic or as TN5250/
TN3270 terminal traffic.

ActiveX components. And what of Microsoft's strategicchallenge to Java, ActiveX? Can an ActiveX IBM terminal emulation componentachieve the same results as a Java terminal emulation applet or a plugin? Youbet. Unfortunately, vendor support for ActiveX lags behind vendor support forJava. Wall Data leads the industry in ActiveX IBM terminal emulation.

Implementing ActiveX parallels implementing plugins. You can automaticallydownload the necessary ActiveX component to your client and run it in thecontext of the current Web page. The big limitations of ActiveX components arethat only the Microsoft Web browser (IE) fully supports ActiveX and that ActiveXworks on only Intel clients.

HTTP interceptors. An HTTP interceptor routine (a.k.a. agateway program) receives the traffic sent to either the standard TCP/IP portfor HTTP traffic (port 80) or a predefined, custom port. When the interceptorreceives data from a port, it assumes the request is for terminal emulation andprovides all the necessary terminal screen-to-HTML conversion.

Think of an interceptor as a very specialized kind of Web server: Aninterceptor receives all traffic addressed to the port it monitors, but insteadof serving up standard HTML pages, it serves up terminal emulation. An HTTPinterceptor routine has the same advantages and disadvantages as a CGI routine.

So Many Choices, So Little Time
You can take many different paths to reach the destination of browser-basedIBM terminal emulation. And, of course, there's no single "right" pathto take because you must consider so many factors. For example, if you want toprovide universal access from all types of client systems, then you're limitedto the CGI, Java, and HTTP interceptor approaches. If your goal is to incur allthe processing overhead on your IBM host or on a gateway, then you need to lookat the CGI and HTTP interceptor options. Conversely, if you want to off-load allthe processing to your clients, you can choose among helper applications, Javaapplets, plugins, and ActiveX components. As you can see, you must consider manydetails. But the good news is you get many options to choose from.