One of the many dilemmas that you face when you publish mainframe- or AS/400-based information on Internet or intranet Web pages is how to handle the construction and presentation of the data. Some (maybe most) of the data you have stored in your databases may not be--and I'll try to be delicate here--suitable for publication as is. Perhaps the information you want to publish needs to be calculated, or you need to use data from the fields in one database to access information stored in other databases. You could, of course, implement elaborate SQL routines or stored procedures to automatically generate your 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: Chances are pretty good that you have existing business applications that handle your data, apply your business rules, and present the data just the way you want on an IBM 3270 or 5250 terminal. Therefore, if you could simply let your Web browser 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 browser fire up a 3270 or 5250 emulation session and drop the user into an application program.
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 not up their alley. Fortunately, Web browsers know how to trigger other nonintegrated procedures such as Common Gateway Interface (CGI) routines, external helper applications, plug-in programs, Java applets, ActiveX components, and HTTP interceptors. These procedures can be sponsored by the IBM system hosting the terminal session or by an external gateway device that controls the Web interface and feeds the terminal sessions to the IBM host as native SNA terminal traffic. In short, you have a variety of options to help you overcome the limitations of Web browsers.
Paths to Green Screen Pastures
Although all terminal emulation methods accomplish the same goal, they are
not equal solutions. Let's take a closer look at the methods so that you can see
the pros and cons of each.
CGI routines. CGI routines are software modules that a Web browser invokes and a host system (i.e., the IBM mainframe or AS/400) or a gateway system executes. For terminal emulation, you can use CGI to convert IBM screen information to HTML format so the terminal emulation session is embedded in the Web page. Screen 1 shows a CGI-based 5250 terminal emulation session hosted by a gateway device.
The biggest benefit of the CGI method is its platform independence--the same CGI interface can provide terminal emulation for PCs, Macs, UNIX platforms, and virtually any other platform that can run a graphical Web browser. Another benefit of this approach is the amount of control you have over the terminal emulation session. Because the CGI routine runs on your host or your gateway, you can control all the characteristics of the session (device type, screen appearance, timeout values, etc.). The biggest disadvantage of the CGI method is that CGI routines that implement terminal emulation are relatively complex--they chew up CPU resources wherever they run (i.e., on an IBM host or in a gateway).
Helper applications. If you already use TN3270 or TN5250 emulation, you can have your client Web browsers launch the client-side Telnet software on demand. You can accomplish this launch two different ways. First you can embed the telnet: HTML tag in a Web page to launch the helper TN3270 or TN5250 program. Of course, you must configure each client browser to launch the appropriate executable file (with any associated command-line parameters) when the user clicks on the telnet: tag. Alternatively, you can set up a file download to the client with the MIME file type that tells the browser you want to launch the TN5250 or TN3270 program as a helper application. In this case, you must configure each client browser to recognize the relationship between the file type and the TN5250 or TN3270 software. Once you complete either setup, this solution works well and it moves the burden of terminal emulation from the IBM host or gateway to the client system. Screen 2 shows an external TN5250 helper launched by a Web page.
You can also achieve a low level of session control using either helper application approach. For example, the file you download to activate the TN5250 or TN3270 session can be the configuration file for the emulator; therefore, you can control (to a certain extent) how the emulator looks and operates on the client. If, on the other hand, you activate TN5250 or TN3270 via the telnet: tag, you can typically include the configuration file as a command-line parameter in the execution sequence.
The major problem with both helper application approaches is that they are very complicated to implement. You must load TN5250 or TN3270 software on each client. Furthermore, you need the same brand and version of software resident on each of your client systems; otherwise, you'll have a difficult time configuring the client browsers to launch the correct program with the appropriate parameters (each brand or version can potentially accept different parameters). If you have different brands or versions of TN5250 or TN3270 in place, you cannot download a configuration file from your host system to launch the emulation because different brands and versions of software use different types of configuration files. A final problem with this approach is that the TN5250 or TN3270 program runs as a separate application; therefore, the user must end the program when the session is over--you cannot automatically close the terminal emulation session window when the user moves off the Web page.
Plugins. A relatively new method for browser-based IBM terminal access is to use an IBM terminal emulation plugin. A plugin is a special kind of helper application that a Web browser can automatically launch and run inside the current Web page. Traditionally, vendors have used plugins to provide support for audio, video, virtual reality modeling, and other special purpose 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 plugin scheduled to go on the market. Screen 3 shows a plugin sponsoring a terminal emulation session.
A terminal emulation plugin might sound like the helper application just described, but some key differences exist. First, when a Web page loads, it can automatically activate the plugin; users don't need to click a file reference to start the session. Second, the session is tied to the Web page; if the user backs out of the page, the session link is automatically broken (after some period of time). Third, plugins usually cooperate with server-side scripts, so you can automate the client logon process and drop users directly into the application you want them to access. Finally, you can have a plugin automatically download if it is not installed in the client's system. In other words, you get all the benefits of a helper application, but without the configuration and administration hassles.
Of course plugins aren't perfect. The biggest limitation is that to use a terminal emulation plugin, users must run the Netscape Navigator 3.0 browser or a browser that supports Navigator plugins (such as Microsoft's Internet Explorer--IE--3.0). Another significant limitation is that plugins are not available for all types of clients and client operating systems.
Java applets. What discussion of Web browsing and IBM host access would be complete without the specter of Java? Does Java have a role here? The answer is yes because several companies--ADVANCED BusinessLink, Farabi Technology, and OpenConnect in particular--have developed Java-based IBM terminal emulators. On demand, a Java applet downloads to the Web browser and executes as a separate Java applet. Screen 4 shows a Java-based terminal emulation session. Unlike a plugin, the Java applet does not need to be preloaded or preconfigured; it downloads each time it's needed. This feature, of course, is good and bad news. The good news is no special configuration considerations exist on the browser side (other than the requirement that the browser must support Java). The bad news is the applet must download whenever it drops 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 terminal emulation 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. But unlike CGI routines, Java applets run on the client side and consume client-side resources (instead of IBM host-side resources). Java-based terminal emulation applets are an emerging area in the IBM market (i.e., no standards exist; therefore, no two Java terminal applets will work alike). Some Java applets provide dynamic terminal screen-to-HTML conversion, which produces a graphical look-and-feel similar to what the CGI routines deliver. Other Java-based terminal emulation applets implement character-mode emulation, which provides a look-and-feel similar to standard terminal emulation. Shop around and see what you can find.
As in the case of plugins, the biggest limitation of a Java-based terminal
applet is that users must run a browser that supports Java. Another interesting
characteristic of the current breed of Java-based IBM terminal emulation applets
is that they rely on a gateway device that sits between the Internet and the IBM
host. The gateway converts the Java terminal emulation data stream into a
standard IBM terminal emulation stream and feeds it into the IBM host as native
SNA terminal traffic or as TN5250/
TN3270 terminal traffic.
ActiveX components. And what of Microsoft's strategic challenge to Java, ActiveX? Can an ActiveX IBM terminal emulation component achieve the same results as a Java terminal emulation applet or a plugin? You bet. Unfortunately, vendor support for ActiveX lags behind vendor support for Java. Wall Data leads the industry in ActiveX IBM terminal emulation.
Implementing ActiveX parallels implementing plugins. You can automatically download the necessary ActiveX component to your client and run it in the context of the current Web page. The big limitations of ActiveX components are that only the Microsoft Web browser (IE) fully supports ActiveX and that ActiveX works on only Intel clients.
HTTP interceptors. An HTTP interceptor routine (a.k.a. a gateway program) receives the traffic sent to either the standard TCP/IP port for HTTP traffic (port 80) or a predefined, custom port. When the interceptor receives data from a port, it assumes the request is for terminal emulation and provides all the necessary terminal screen-to-HTML conversion.
Think of an interceptor as a very specialized kind of Web server: An interceptor receives all traffic addressed to the port it monitors, but instead of serving up standard HTML pages, it serves up terminal emulation. An HTTP interceptor 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-based
IBM terminal emulation. And, of course, there's no single "right" path
to take because you must consider so many factors. For example, if you want to
provide universal access from all types of client systems, then you're limited
to the CGI, Java, and HTTP interceptor approaches. If your goal is to incur all
the processing overhead on your IBM host or on a gateway, then you need to look
at the CGI and HTTP interceptor options. Conversely, if you want to off-load all
the processing to your clients, you can choose among helper applications, Java
applets, plugins, and ActiveX components. As you can see, you must consider many
details. But the good news is you get many options to choose from.
| Contact Info |
|
ADVANCED BusinessLink 206-455-9804 Web: http://www.businesslink.com Farabi Technology 514-332-3455 or 800-565-3455 Web: http://www.farabi.com OpenConnect 214-484-5200 or 800-551-5881 Web: http://www.oc.com Wall Data 415-812-1600 or 800-915-9255 Web: http://www.walldata.com White Pine Software 603-886-9050 Web: http://www.wpine.com |
Helper applications. If you already use TN3270 or TN5250 emulation, you can have your client Web browsers launch the client-side Telnet software on demand. You can accomplish this launch two different ways. First you can embed the telnet: HTML tag in a Web page to launch the helper TN3270 or TN5250 program. Of course, you must configure each client browser to launch the appropriate executable file (with any associated command-line parameters) when the user clicks on the telnet: tag. Alternatively, you can set up a file download to the client with the MIME file type that tells the browser you want to launch the TN5250 or TN3270 program as a helper application. In this case, you must configure each client browser to recognize the relationship between the file type and the TN5250 or TN3270 software. Once you complete either setup, this solution works well and it moves the burden of terminal emulation from the IBM host or gateway to the client system. Screen 2 shows an external TN5250 helper launched by a Web page.
You can also achieve a low level of session control using either helper application approach. For example, the file you download to activate the TN5250 or TN3270 session can be the configuration file for the emulator; therefore, you can control (to a certain extent) how the emulator looks and operates on the client. If, on the other hand, you activate TN5250 or TN3270 via the telnet: tag, you can typically include the configuration file as a command-line parameter in the execution sequence.
The major problem with both helper application approaches is that they are very complicated to implement. You must load TN5250 or TN3270 software on each client. Furthermore, you need the same brand and version of software resident on each of your client systems; otherwise, you'll have a difficult time configuring the client browsers to launch the correct program with the appropriate parameters (each brand or version can potentially accept different parameters). If you have different brands or versions of TN5250 or TN3270 in place, you cannot download a configuration file from your host system to launch the emulation because different brands and versions of software use different types of configuration files. A final problem with this approach is that the TN5250 or TN3270 program runs as a separate application; therefore, the user must end the program when the session is over--you cannot automatically close the terminal emulation session window when the user moves off the Web page.
Plugins. A relatively new method for browser-based IBM terminal access is to use an IBM terminal emulation plugin. A plugin is a special kind of helper application that a Web browser can automatically launch and run inside the current Web page. Traditionally, vendors have used plugins to provide support for audio, video, virtual reality modeling, and other special purpose 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 plugin scheduled to go on the market. Screen 3 shows a plugin sponsoring a terminal emulation session.
A terminal emulation plugin might sound like the helper application just described, but some key differences exist. First, when a Web page loads, it can automatically activate the plugin; users don't need to click a file reference to start the session. Second, the session is tied to the Web page; if the user backs out of the page, the session link is automatically broken (after some period of time). Third, plugins usually cooperate with server-side scripts, so you can automate the client logon process and drop users directly into the application you want them to access. Finally, you can have a plugin automatically download if it is not installed in the client's system. In other words, you get all the benefits of a helper application, but without the configuration and administration hassles.
Of course plugins aren't perfect. The biggest limitation is that to use a terminal emulation plugin, users must run the Netscape Navigator 3.0 browser or a browser that supports Navigator plugins (such as Microsoft's Internet Explorer--IE--3.0). Another significant limitation is that plugins are not available for all types of clients and client operating systems.
Java applets. What discussion of Web browsing and IBM host access would be complete without the specter of Java? Does Java have a role here? The answer is yes because several companies--ADVANCED BusinessLink, Farabi Technology, and OpenConnect in particular--have developed Java-based IBM terminal emulators. On demand, a Java applet downloads to the Web browser and executes as a separate Java applet. Screen 4 shows a Java-based terminal emulation session. Unlike a plugin, the Java applet does not need to be preloaded or preconfigured; it downloads each time it's needed. This feature, of course, is good and bad news. The good news is no special configuration considerations exist on the browser side (other than the requirement that the browser must support Java). The bad news is the applet must download whenever it drops 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 terminal emulation 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. But unlike CGI routines, Java applets run on the client side and consume client-side resources (instead of IBM host-side resources). Java-based terminal emulation applets are an emerging area in the IBM market (i.e., no standards exist; therefore, no two Java terminal applets will work alike). Some Java applets provide dynamic terminal screen-to-HTML conversion, which produces a graphical look-and-feel similar to what the CGI routines deliver. Other Java-based terminal emulation applets implement character-mode emulation, which provides a look-and-feel similar to standard terminal emulation. Shop around and see what you can find.
As in the case of plugins, the biggest limitation of a Java-based terminal
applet is that users must run a browser that supports Java. Another interesting
characteristic of the current breed of Java-based IBM terminal emulation applets
is that they rely on a gateway device that sits between the Internet and the IBM
host. The gateway converts the Java terminal emulation data stream into a
standard IBM terminal emulation stream and feeds it into the IBM host as native
SNA terminal traffic or as TN5250/
TN3270 terminal traffic.
ActiveX components. And what of Microsoft's strategic challenge to Java, ActiveX? Can an ActiveX IBM terminal emulation component achieve the same results as a Java terminal emulation applet or a plugin? You bet. Unfortunately, vendor support for ActiveX lags behind vendor support for Java. Wall Data leads the industry in ActiveX IBM terminal emulation.
Implementing ActiveX parallels implementing plugins. You can automatically download the necessary ActiveX component to your client and run it in the context of the current Web page. The big limitations of ActiveX components are that only the Microsoft Web browser (IE) fully supports ActiveX and that ActiveX works on only Intel clients.
HTTP interceptors. An HTTP interceptor routine (a.k.a. a gateway program) receives the traffic sent to either the standard TCP/IP port for HTTP traffic (port 80) or a predefined, custom port. When the interceptor receives data from a port, it assumes the request is for terminal emulation and provides all the necessary terminal screen-to-HTML conversion.
Think of an interceptor as a very specialized kind of Web server: An interceptor receives all traffic addressed to the port it monitors, but instead of serving up standard HTML pages, it serves up terminal emulation. An HTTP interceptor 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-based
IBM terminal emulation. And, of course, there's no single "right" path
to take because you must consider so many factors. For example, if you want to
provide universal access from all types of client systems, then you're limited
to the CGI, Java, and HTTP interceptor approaches. If your goal is to incur all
the processing overhead on your IBM host or on a gateway, then you need to look
at the CGI and HTTP interceptor options. Conversely, if you want to off-load all
the processing to your clients, you can choose among helper applications, Java
applets, plugins, and ActiveX components. As you can see, you must consider many
details. But the good news is you get many options to choose from.
| Contact Info |
|
ADVANCED BusinessLink 206-455-9804 Web: http://www.businesslink.com Farabi Technology 514-332-3455 or 800-565-3455 Web: http://www.farabi.com OpenConnect 214-484-5200 or 800-551-5881 Web: http://www.oc.com Wall Data 415-812-1600 or 800-915-9255 Web: http://www.walldata.com White Pine Software 603-886-9050 Web: http://www.wpine.com |
